[cabfpub] Ballot 92 - Subject Alternative Names

Steve Roylance steve.roylance at globalsign.com
Fri Nov 16 16:38:21 UTC 2012


Please remember that it's not only how the browser vendors display these
certificates in real time that's at stake here, but what audit trail is
left (including captured logs/packets/ocsp responses or CRLs that help
identify the cert in question) so that an enterprise is able to to find
out who actually did break in and steal something (or who is trying).

If you are suggesting that having a single FQDN included is strong enough
to identify the culprit then this is not correct, no more than me creating
a gerv at gmx.com would lead to you.

This stance seems to be counter to the threat of allowing non public
credentials in the first place.   If there's no need to positively
identify the owner of the credential used in an attack then the threat is
not that serious and we can carry on offering to all who ask without

Therefore if we (the CA's) do wish to strengthen this type of certificate
please support us, regardless of how you wish to show it in your GUI, i.e.
Please don't object when we want to do things better.

I'm not an forensics expert but as the Tesco strapline here in the UK says
"Every little helps" and I'm sure that's true.


On 16/11/2012 10:15, "Gervase Markham" <gerv at mozilla.org> wrote:

>On 15/11/12 17:27, Steve Roylance wrote:
>> Contents: This extension MUST contain at least one entry that is either
>> a Fully-Qualified Domain Name or Public IP Address. Each subjectAltName
>> entry MUST either be a Domain Name or an IP Address. The CA MUST confirm
>> the Applicant¹s control of each dNSName or Public IP Address entry in
>> accordance with Section 11.1.
>This bit, I agree with.
>The rest - that certs with internal domain names must be OV - I do not,
>because I don't think it measurably adds to security. People on LANs who
>are using "https://mail/" are not going to check the O field in the
>certificate viewer every time to make sure it's their company's
>https://mail/ cert rather than someone else's. And Mozilla is not going
>to start putting that field in primary UI for non-EV certs, for
>long-rehearsed reasons.
>The above rule at least allows browsers to programmatically display an
>ownership-validated FQDN as an "identifier" even when accessing an
>internal site. I filed a bug on us doing that, although we have no plans
>or resources to implement it, and my position has been that we shouldn't
>force CAs to do the work to include the info until we have actually
>implemented it. But if you are keen to force yourselves, I'm not going
>to object :-)
>However, given that the ballot stands or falls as a whole, we will be
>voting against. (This should not come as a surprise to its proponents; I
>think we have exhausted the discussion on the topic and must agree to
>disagree, and see what everyone else thinks when the vote comes :-)

More information about the Public mailing list