Viktor Dukhovni <[email protected]> wrote: > Brian Smith wrote: > >> When the MUA connects to imap.gmail.com, how would the server know >> which certificate to give the MUA? Would the MUA put >> "_imap.example.com" in the SNI extension of the TLS ClientHello when >> connecting to the GMail server? > > No, it would send the base domain "example.com". The IMAP server would > need to know that an "_imap.exmaple.com" certificate is the right one > to return if that's what it has (absent an "example.com" certificate > on hand).
Thanks. That's not what I expected. Do you know which part of which RFC documents that? > Name constraints mostly don't work. For example, name constraints > on the DNS subjectAltName are often not applied to the CN-ID, plus > the whole "critical" mess, ... For the purposes of Mozilla's root inclusion program, at least, the name constraints work just fine, including covering CN-IDs, and regardless of the critical flag. I agree that some implementations have trouble with name constraints. However, name constraints are an important part of some root CA inclusion policies, so we can't ignore them with respect to srvName. > Yes, toolkits would need to add support for SRV-IDs. I think it is very likely that many toolkits won't add SRV-ID support any time soon, if the way that implementers have ignored RFC 6120 is any indication. >> 3. It seems unreasonable to require that the mail hosting provider >> have certificates with srvName subjectAltName entries for all >> customers' DNS names. Even for moderately-sized hosts, this would seem >> to require the management of a too-large number of certificates. > > That's what SNI is for. And better yet DANE, which obviates the > need for per-client certificates. How to select which certificate to send based on SNI is a small issue relative to the general operational problem of managing thousands of different certificates in order to support SRV-IDs. >> 4. It isn't clear how a CA would go about securely verifying that a >> mail hosting provider like GMail is authorized by a domain name owner >> (e.g. example.com) to request and use a certificate with a srvName for >> the domain name (e.g. GMail asking for an _imap.example.com >> certificate). > > The the CA's job, the certificate would be obtained by the customer > and provisioned by the customer via a customer admin portal. Requesting a certificate usually requires proof of possession of the private key. So, GMail would have to generate the CSR (or equivalent) to give to the CA, not the customer. >> In practice, traditionally standardizing such practices >> is done in the CABForum. If CABForum is inappropriate here, then how >> will such issuing practices be standardized? > > CAs should never issue certificates for a domain to a third party. > So there's nothing to standardize. Sounds good, but I think it's fair to say that it is unclear how it would actually work. >> It seems to me like it is worth considering an alternative mechanism >> where it is possible for example.com to say that imap.gmail.com is >> hosting its email for a certain duration of time, such that >> imap.gmail.com doesn't need to get any certificate that specifically >> mentions example.com, siimlar to the Alt-Svc mechanism for HTTP/2. > > That's what DANE accomplishes. DNSSEC-validated SRV records have > a signature TTL: > > _imap._tcp.example.com. IN SRV 0 0 143 imap.gmail.com. > _imap._tcp.example.com. IN RRSIG SRV ... <expiration> <inception> ... > > a DANE-enabled client finds imap.gmail.com's TLSA RRs and Gmail has no > need for any kind of example.com certificate. > > _143._tcp.imap.gmail.com. IN TLSA 3 1 1 <spki-sha256-digest> It one is going to use DNS to do auto-configuration of email clients, then I think this seems better than the SRV-ID-based approach. At least it's clearer as to how it is supposed to work. Thanks for answering my questions. I still think that the X.509 certificate with SRV-ID approach seems too impractical to expect widespread enough adoption to make it worthwhile to implement the infrastructure for it. Consequently, I think saying that clients MUST or even SHOULD implement the SRV-ID-based approach is too much. Thanks again, Brian _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
