On Mon, Apr 13, 2015 at 02:33:00PM -1000, 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).
> Many members of the CABForum consider the scope of the CABForum to
> include all TLS certificates that can be *could* be used by a web
> browser.
They might presume to think so, but they don't really represent
the non-browser constituencies.
> 1. Root CA inclusion programs for Thunderbird and other MUAs need to
> be updated to consider SRV-IDs, particularly what otherName name
> constraints a "technically constrained externally-operated sub-CA"
> must have.
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, ...
> 2. Certificate verification logic needs to be extended to provide a
> proper API and a proper implementation of that API for dealing with
> SRV-IDs, because SRV-IDs need to be treated differently from DNS-IDs
> (and CN-IDs), and current APIs are mostly/totally designed for
> DNS-IDs.
Yes, toolkits would need to add support for SRV-IDs.
> 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.
> 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.
> 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.
> 5. If the owner of example.com switches his hosting from
> mail.gmail.com to mail.outlook.com, how does the owner of example.com
> go about disabling the certificate containing srvName
> _imap.example.com that mail.gmail.com is using?
Revoke it (we'll pretend revocation works), and/or deprovision it
through the admin interface (before discontinuing the business
relationship) and expect that as a matter of contractual obligation
Gmail will not misuse the certificate for its remaining lifetime.
> 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>
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
