Re: UTA: Server certificate management (Re: Last Call: <draft-ietf-uta-email-tls-certs-05.txt>)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Den 02. des. 2015 15:28, skrev John Levine:
>> As I read that spec, it says mandatory to implement, not mandatory to
>> use (it's up to the application whether it claims to be capable of using
>> it or not) - but it permits servers to mandate its use. *Almost* there -
>> but if this draft wishes to mandate its use, it will have to say so (and
>> say which identifier it's going to send - AFAIK, it only gets to send one.)
> 
> Even with SNI, we still have the problem that there's no way for the
> CA to tell what SRV-IDs it should sign other than using RFC 6186
> lookups.  But the MUA can do the same 6186 lookup, and that scales a
> lot better for the many mail systems that handle large and changing
> sets of client domains.

I don't think having the certificate changed and signed every time you
turn up a new customer scales anyway. With an in-house CA, it's possible
to generate a new certificate for every new customer - but signing your
customer list and publishing it? That seems like a Bad Idea, as well as
unscaleable.




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]