[cabfpub] Ballot 92 - Subject Alternative Names
jeremy.rowley at digicert.com
Fri Nov 16 16:56:50 UTC 2012
In that case, isn't the most appropriate action for Mozilla to raise its
concern about the level of vetting required for inclusion of the O field in
the form of an amendment to the baseline requirements? If Mozilla doesn't
believe the baseline requirements are sufficient, I'd appreciate a proposed
amendment about what is sufficient to show the O field.
Plus, has Mozilla considered the fact that the baseline requirement's rules
for validating organization are at least as strong (or stronger) than those
required to validate the domain of a certificate? After all, the minimum
requirement to validate the domain field is that the WHOIS match the
applicant submitted information. I'm not sure how you can say that is
trustworthy yet the third party checked organization information is not.
From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
Behalf Of Gervase Markham
Sent: Friday, November 16, 2012 9:49 AM
To: Steve Roylance
Cc: CABForum Management; public at cabforum.org
Subject: Re: [cabfpub] Ballot 92 - Subject Alternative Names
On 16/11/12 16:38, Steve Roylance wrote:
> 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
Mozilla's position is that it is not sufficiently difficult to get an OV
cert with a misleading O field that it would prove a difficulty for
criminals. That's why we have EV. I know some people disagree with us on
this, but there it is. So, your logic would lead us to the idea that certs
with non-FQDNs in them must be EV.
> 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.
I think it is at least a way of differentiating two otherwise identical
certs for "mail".
> 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 question.
As you know, our stance on such certs is that we are making a trade-off.
Like you, I'd like to see them gone tomorrow. But I don't want to fall into
the politician's fallacy: "We must do something. This is something.
Therefore we must do this."
> 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.
What you want to do is not side-effect-free. Say a CA is not in the OV
business. If they want to continue to issue such certs, they either have to
validate them all as EV (not a winning proposition), stop issuing, or spin
up new business process.
Public mailing list
Public at cabforum.org
More information about the Public