Proposal: Advocate to get Section 9.3.1 (Reserved Certificate Policy Identifiers) made mandatory.

[nick...@lugatech.com]

It would be great to see Mozilla propose and advocate to have section 9.3.1 of the BRs, Reserved Certificate Policy Identifiers, to be made mandatory with the CA/Browser forum. Presently this section of the BRs is only optional.

The text as of revision 1.1.8 reads:

"9.3.1 Reserved Certificate Policy Identifiers

The following Certificate Policy identifiers are reserved for use by CAs as an optional means of asserting compliance with these Requirements as follows:

{joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-policies(1) baseline- requirements(2) domain-validated(1)} (2.23.140.1.2.1), if the Certificate complies with these Requirements but lacks Subject Identity Information that is verified in accordance with Section 11.2.

If the Certificate asserts the policy identifier of 2.23.140.1.2.1, then it MUST NOT include organizationName, streetAddress, localityName, stateOrProvinceName, or postalCode in the Subject field.

{joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-policies(1) baseline- requirements(2) subject-identity-validated(2)} (2.23.140.1.2.2), if the Certificate complies with these Requirements and includes Subject Identity Information that is verified in accordance with Section 11.2.

If the Certificate asserts the policy identifier of 2.23.140.1.2.2, then it MUST also include organizationName, localityName, stateOrProvinceName (if applicable), and countryName in the Subject field."

The status quo today means that it is not possible to discriminate programatically between a DV and OV certificate in a standardized, reliable way.

This is unreasonable as the validation and assurance on such certificates are very different. This should, therefore, be reflected in the certificates that are issued by CAs but this is typically not the case today.

Changing the BRs to make this mandatory going forward would address this over time as existing certificates expire and are renewed.

Thanks,

Nick

[Gervase Markham]

On 23/07/14 10:06, nick...@lugatech.com wrote:
> The status quo today means that it is not possible to discriminate
> programatically between a DV and OV certificate in a standardized,
> reliable way.

This is because Mozilla's position is that, in security terms, there is
no relevant difference.

> This is unreasonable as the validation and assurance on such
> certificates are very different.

They are different, but not in a way that is reasonably measurable and
auditable.

The very reason EV (which does have identifying OIDs, and can be
distinguished programmatically) exists is because when it did not, there
were a wide variety of practices concerning what was an appropriate
level of validation for the O field in certificates. (And, I would say,
_all_ of them were inadequate, some more so than others.) EV sets the
minimum levels of validation, in a way which is agreed, auditable and
audited. That meant that we were confident in displaying the O field to
the user as a trusted piece of data - which we do in the URL bar.

If a cert does not meet the EV standards for information validation, we
feel you cannot sufficiently trust the O field, and therefore from a
security perspective there is no difference between that certificate and
one where the O field is absent. Hence we make no UI distinction between
OV and DV.

Gerv

[nick...@lugatech.com]

On Wednesday, July 23, 2014 8:50:38 PM UTC+8, Gervase Markham wrote:
> On 23/07/14 10:06, nick...@lugatech.com wrote:
>
> > The status quo today means that it is not possible to discriminate
>
> > programatically between a DV and OV certificate in a standardized,
>
> > reliable way.
>
>
>
> This is because Mozilla's position is that, in security terms, there is
>
> no relevant difference.
>

Clearly EV is very much the gold standard, but I there is a relevant general difference between EV and DV even if not a security one. It would be nice if Firefox could state that the certificate was DV or EV in a neutral way without making / implying any security difference.

>
> > This is unreasonable as the validation and assurance on such
>
> > certificates are very different.
>
>
>
> They are different, but not in a way that is reasonably measurable and
>
> auditable.
>
>
>
> The very reason EV (which does have identifying OIDs, and can be
>
> distinguished programmatically) exists is because when it did not, there
>
> were a wide variety of practices concerning what was an appropriate
>
> level of validation for the O field in certificates. (And, I would say,
>
> _all_ of them were inadequate, some more so than others.) EV sets the
>
> minimum levels of validation, in a way which is agreed, auditable and
>
> audited. That meant that we were confident in displaying the O field to
>
> the user as a trusted piece of data - which we do in the URL bar.
>
>
>
> If a cert does not meet the EV standards for information validation, we
>
> feel you cannot sufficiently trust the O field, and therefore from a
>
> security perspective there is no difference between that certificate and
>
> one where the O field is absent. Hence we make no UI distinction between
>
> OV and DV.
>

There is a conceptual separation of concerns though from a certificate specifying that it is DV or OV and what, if any, UI would be appropriate to separate the two in a Web browser. No difference is a valid option.

An extension to Firefox, for example, may want to show EV style UI in blue for those who understand the difference between the three types of certificate to draw inference from.

Presently one could not do so based on standardized information contained within a certificate.

Were it mandated that this information be included, Firefox would still be completely free to ignore the information from a UI perspective. Appropriate UI is a completely separate question to a certificate containing this information.

>
> Gerv

[nick...@lugatech.com]

Sorry, I meant to write:

It would be nice if Firefox could state that the certificate was DV or -OV- in a neutral way without making / implying any security difference.

[Jeremy Rowley]

Right - all adding the OIDs does is specify in the certificate which BR section was used to perform the validation. There isn't a security indicator attached.

Jeremy

-----Original Message-----
From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla.org] On Behalf Of nick...@lugatech.com
Sent: Wednesday, July 23, 2014 7:20 AM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: Proposal: Advocate to get Section 9.3.1 (Reserved Certificate Policy Identifiers) made mandatory.

Sorry, I meant to write:

It would be nice if Firefox could state that the certificate was DV or -OV- in a neutral way without making / implying any security difference.
_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

[Jeremy Rowley]

Ryan Hurst wrote a blog post on this very topic not too long ago. His conclusion was that determining, programmatically, the difference was difficult. See http://unmitigatedrisk.com/?p=203.

This is mostly because there are some certs that still include a domain in the org field. Requiring a BR OID serves two purposes - 1) the OID is a positive assertion to the browser by the CA that the cert was issued under the BRs and intended for SSL and 2) the OID identifies the sections relied on for validation. The OID assists in auditing whether a CA is aware of its practices and how it is choosing to comply with the BRs.

Jeremy

-----Original Message-----
From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla.org] On Behalf Of Robin Alden
Sent: Wednesday, July 23, 2014 8:02 AM
To: 'Gervase Markham'; nick...@lugatech.com; mozilla-dev-s...@lists.mozilla.org
Subject: RE: [SPAM] Re: Proposal: Advocate to get Section 9.3.1 (Reserved Certificate Policy Identifiers) made mandatory.

> On 23/07/14 10:06, nick...@lugatech.com wrote:
> > The status quo today means that it is not possible to discriminate
> > programatically between a DV and OV certificate in a standardized,
> > reliable way.
>

Gerv said..

> This is because Mozilla's position is that, in security terms, there
is no
> relevant difference.
>

That is not the reason.
That may be a contributory reason to Mozilla not proposing or supporting the proposition of language to change the BR's 9.3.1 which result in it not being compulsory to include a mandated policy OID in a certificate which would identify it unequivocally as being a DV or an OV certificate, but it is not the definitive reason why the BRs do not mandate it.

If the BRs already mandated it I would not expect your opinion or your UI to change, but the OP's question would not have arisen as he would have easily programmatically been able to tell whether a certificate was OV or DV.

> > This is unreasonable as the validation and assurance on such
> > certificates are very different.
>
> They are different, but not in a way that is reasonably measurable and
> auditable.
>

<snip>

>
> If a cert does not meet the EV standards for information validation,
we
> feel you cannot sufficiently trust the O field, and therefore from a
> security perspective there is no difference between that certificate
and
> one where the O field is absent. Hence we make no UI distinction
> between OV and DV.
>

Whilst I disagree with your sentiment, in your UI (browser, certificate viewer, mail client, etc.) it's your game, so it's your rules.
The compulsory inclusion of a Policy Identifier OID in the certificate definitively stating DV or OV need not offend you, since you will probably continue to ignore it.

As to the issue which presumably ignited the thread in the first place, I think that for a non-EV BR compliant certificate you probably can distinguish programmatically between OV and DV.
According to section 9.2.4 of the BRs,
if the certificate subject contains an organizationName field and also contains one or both of (stateOrProvinceName and localityName) then it is an OV certificate.
If the certificate subject does not contain an organizationName field then it is an OV certificate.
This begs the question of whether the certificate is claiming to be an EV certificate or claiming to be BR compliant.

Regards
Robin Alden
Comodo

[Gervase Markham]

On 23/07/14 14:18, nick...@lugatech.com wrote:
> Clearly EV is very much the gold standard, but I there is a relevant
> general difference between EV and DV even if not a security one. It
> would be nice if Firefox could state that the certificate was DV or
> EV in a neutral way without making / implying any security
> difference.

If it makes no difference to the security, why would the average user
want to know (how would they even understand the difference?), and why
would a web browser want to complicate its UI by showing them?

Gerv

[Jeremy Rowley]

I agree he was in favor of requiring the BR OIDs, as I think most CAs are.

Jeremy

-----Original Message-----
From: Moudrick M. Dadashov [mailto:m...@ssc.lt]
Sent: Wednesday, July 23, 2014 9:02 AM
To: Jeremy Rowley; 'Robin Alden'; 'Gervase Markham'; nick...@lugatech.com; mozilla-dev-s...@lists.mozilla.org
Subject: Re: Proposal: Advocate to get Section 9.3.1 (Reserved Certificate Policy Identifiers) made mandatory.

"Having these identifiers takes us a long way towards our goal of
deterministic evaluation of certificate issuance policy - that said not
all CAs have adopted them which is technically alright since the
Baseline Requirements do allow them to use their own Policy
Identifiers". This is what Ryan said about Policy OID based
(Deterministic) approach, I read this as in favor of Policy OIDs.

Any other criticism why CAs should not support the Deterministic approach?

Thanks,
M.D.

[Chris Palmer]

On Wed, Jul 23, 2014 at 7:50 AM, Gervase Markham <ge...@mozilla.org> wrote:

> If it makes no difference to the security, why would the average user
> want to know (how would they even understand the difference?), and why
> would a web browser want to complicate its UI by showing them?

Anyone making the UX of a UA that performs X.509 validation can
certainly try to distinguish OV from DV programatically (potentially
hard, as Hurst notes), but I am pretty sure they'll find that their
users don't appreciate the distinction.

In the case of browsers specifically, the same-origin policy is the
law of the land, and complicating it further (to distinguish levels of
subject validation) would not fly in any case — with users or with web
developers.

[Jeremy Rowley]

It makes a difference because you can tell whether the CA is operating effective polices in accordance with the BRs. Too many DV certs hold themselves out as OV certs without actually providing the verification under the BRs. Requiring the BR OIDs is an assertion by the CA of compliance that is independent of any display in the UI.

Jeremy

-----Original Message-----
From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla.org] On Behalf Of Gervase Markham
Sent: Wednesday, July 23, 2014 8:51 AM
To: nick...@lugatech.com; mozilla-dev-s...@lists.mozilla.org
Subject: Re: Proposal: Advocate to get Section 9.3.1 (Reserved Certificate Policy Identifiers) made mandatory.

On 23/07/14 14:18, nick...@lugatech.com wrote:

> Clearly EV is very much the gold standard, but I there is a relevant
> general difference between EV and DV even if not a security one. It
> would be nice if Firefox could state that the certificate was DV or EV
> in a neutral way without making / implying any security difference.

If it makes no difference to the security, why would the average user want to know (how would they even understand the difference?), and why would a web browser want to complicate its UI by showing them?

Gerv

[nick...@lugatech.com]

So, based off of the comments that have been made, please can Mozilla support such a change?

If not, what would Mozilla's objections be that are in scope to the question/issue? Presently, none appear to have been articulated.

The immediate benefit to Mozilla would be consistency and conformity among the OV certificates that get issued. This is because, as Jeremy mentions, they will be bound by the requirements that inclusion of the OID brings as it is an assertion of compliance.

As has been said but probably needs to be reiterated, we all need to be careful not to conflate, confuse and overload the issue with the entirely separate and distinct questions that surround handling of the certificate in code and what appropriate UX is. These are clearly far more contentious, perhaps political in nature, and should be considered and discussed independently to this.

Thanks!

Nick

[Ryan Sleevi]

On Thu, July 24, 2014 8:59 pm, nick...@lugatech.com wrote:
> So, based off of the comments that have been made, please can Mozilla
> support such a change?
>
> If not, what would Mozilla's objections be that are in scope to the
> question/issue? Presently, none appear to have been articulated.
>
> The immediate benefit to Mozilla would be consistency and conformity among
> the OV certificates that get issued. This is because, as Jeremy mentions,
> they will be bound by the requirements that inclusion of the OID brings as
> it is an assertion of compliance.

This is a tautology. There is no benefit except consistency, and there is
no benefit to consistency.

There is no need for an assertion of compliance - CA's make those
assertions themselves.

Further, the idea that a single OID is suitable for this is laughable, in
as much because there's no "single" version of the BRs that's fixed and
immutable.

As you can see from https://cabforum.org/baseline-requirements-documents/
, there are many versions. What you, minimally, want if you wish to
programatically express some value (and if it's not programatically
expressible, then there's no way there's value in manual inspection, since
there's no algorithm that people can use), is that the exact version of
conformance to the BRs is expressed in the cert.

>
> As has been said but probably needs to be reiterated, we all need to be
> careful not to conflate, confuse and overload the issue with the entirely
> separate and distinct questions that surround handling of the certificate
> in code and what appropriate UX is. These are clearly far more
> contentious, perhaps political in nature, and should be considered and
> discussed independently to this.

I think we need to be careful in suggesting arbitrary and capricious
requirements that fail to move the security needle further in a particular
direction.

Do I wish everyone would include the u in favourite and colour? Sure. Do I
think it should be mandatory to get a secure UI? No.

What's still missing is an articulation of value beyond the mere value of
consistency (which itself is not met).

And, of course, let's not forget that it would require CAs to re-do their
entire cert hierarchy - policy OIDs flow down from the root; this is, for
example, how EV is validated. Requiring this would require redoing the
cert hierarchy semi-regularly, and would still fail to accomplish the
goals the next time a new version of the BRs that tangibly altered the
requirements came out and a new OID had to be assigned.

[Brian Smith]

On Fri, Jul 25, 2014 at 8:59 AM, Ryan Sleevi
<ryan-mozde...@sleevi.com> wrote:
> I think we need to be careful in suggesting arbitrary and capricious
> requirements that fail to move the security needle further in a particular
> direction.

I agree with everything that Ryan said in his email...

> Do I wish everyone would include the u in favourite and colour?

... except this, which is 100% wrong. :)

Requiring these policies to be asserted in the certificates would make
certificates slightly worse (bigger), would create more work for
everybody involved, and would have no practical end-user benefit.

Cheeurs,
Brian

[Chris Palmer]

On Fri, Jul 25, 2014 at 9:29 AM, Brian Smith <br...@briansmith.org> wrote:

>> Do I wish everyone would include the u in favourite and colour?
>
> ... except this, which is 100% wrong. :)
>
> Requiring these policies to be asserted in the certificates would make
> certificates slightly worse (bigger), would create more work for
> everybody involved, and would have no practical end-user benefit.

...much like requiring 2 spaces after a period.

[Ryan Sleevi]

On Fri, July 25, 2014 10:25 am, Robin Alden wrote:
> That sounds like rot to me.
>
> You've portrayed the suggestion that Mozilla support a change so that a
> CA would be required to more distinctly express it's policy (in the
> matter of whether it considered the certificate DV, OV, EV) as an act of
> the devil himself.
>
> It's a bit over the top.
>
> Robin

Because it's not DV, OV, EV

It's
DV 1.0, OV 1.0, EV 1.0
DV 1.1, OV 1.1, EV 1.1
DV 1.2, OV 1.2, EV 1.2
...

And then there's further permutations, if we get down to brass-tacks. It's
now

DV 1.2+Mozilla 2.1, OV 1.2+Mozilla 2.1, EV 1.2+Mozilla 2.1

But that's not quite sufficient now either, it's

DV 1.2+Mozilla 2.1+Microsoft 9/2012

Of course, this staggering number of assertions isn't quite scalable in
roots, so we fall back to anyPolicy.

And for intermediates, it may have been *issued* under DV 1.2, but may
have been *audited* under DV 1.4 (or DV 1.0). So which OID should it
assert? Over time, the number of OIDs it's "valid" under scales as well.
Unless this intermediate asserts the anyPolicy OID as well, it can't
express the OIDs it's leafs expect.

Don't get me wrong, I'd love to be able to programatically distinguish
exactly what policies a given certificate claims to have been issued
under, precisely because so many CAs have such liberal interpretations
about things, it'd be nice to programatically detect violations of the
BRs.

That is, if BR 1.1.7 says the profile of a compliant certificate looks
like X, and we see a certificate that doesn't look like X, is it a
violation of the BRs? Right now, the data I have to go on is issuance date
in relation to the CA's audit (and the type of audit used - e.g. which
version of ETSI TS 102 042 did they use? Which version of WebTrust?), and
that's a lot of painful work.

But, at the end of the day, it's still more meaningful than a policy OID,
since there are so many nuances that a single value "DV, OV, EV" doesn't
express.

To the point at hand, though, is if UAs can't and don't make any
distinguishing marks between DV and OV - which, programatically, they
don't, and from the security UX, such distinctions don't really matter -
then it doesn't make sense to require CAs to disambiguate the two.

Any security scheme that relies on the user manually inspecting something
and confirming out of band that it's what they expect (and, among these, I
count EV as a failed such experiment, because of the Same Origin Policy
not treating it as distinct) is a bad security scheme. There's no need to
pour that requirement on CAs if it's not actionable.

Instead, I'd rather get them stop backdating certs and making reasonable
progress on moving off SHA-1 :)

[Jeremy Rowley]

Except when CAs don't make the assertion themselves. We've already been over the fact that "intended for use in SSL" is so ambiguous that the BRs don't provide assurances over what the CA does. The OIDs are an assertion that the cert is intended for use in SSL. You can tell which BR version the cert complies with by looking at the issuance date, similar to how Google plans to whitelist certs for CT and how we are phased-in BR compliance.

-----Original Message-----
From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla.org] On Behalf Of Ryan Sleevi
Sent: Friday, July 25, 2014 9:59 AM
To: nick...@lugatech.com
Cc: mozilla-dev-s...@lists.mozilla.org
Subject: Re: Proposal: Advocate to get Section 9.3.1 (Reserved Certificate Policy Identifiers) made mandatory.

I think we need to be careful in suggesting arbitrary and capricious requirements that fail to move the security needle further in a particular direction.

Do I wish everyone would include the u in favourite and colour? Sure. Do I think it should be mandatory to get a secure UI? No.

What's still missing is an articulation of value beyond the mere value of consistency (which itself is not met).

And, of course, let's not forget that it would require CAs to re-do their entire cert hierarchy - policy OIDs flow down from the root; this is, for example, how EV is validated. Requiring this would require redoing the cert hierarchy semi-regularly, and would still fail to accomplish the goals the next time a new version of the BRs that tangibly altered the requirements came out and a new OID had to be assigned.

[Ryan Sleevi]

On Sun, July 27, 2014 7:41 pm, Jeremy Rowley wrote:
> You can tell which BR version
> the cert complies with by looking at the issuance date,

No. You can't.

Surely you don't mean to tell me that if I go find a cert DigiCert issued
last week that I can safely assume it's going to conform to BR 1.1.8, do
you?

The most recent WebTrust Seal linked from your page, Seal ID 1527,
documents that DigiCert was audited to WebTrust 2.0 by KPMG, dated 12 July
2013, and covering through 31 March 2013.

Your CP (v4.06) and CPS (v4.06) are both dated May 14, 2014. But BR 1.1.8
is dated 5 June 2014 (Replacing 1.1.7, dated 3 April 2014). Can I tell,
from looking at the issuance date, which BR version a cert issued on July
20 2014 was issued?

Would I be safe in assuming 1.1.8, even though it's newer than your
CP/CPS? Should I assume your CP/CPS were updated to reflect through 1.1.7?

What about the fact that WebTrust for BR, v1.1 (Amended), the most recent
version published by AICPA, is set with an effective Jan 31, 2013 date,
which corresponds to the time between BR 1.1.1 and BR 1.1.2 (1.1.2
introducing the language regarding wildcard certs and gTLDs)?

There's no reasonable, programatic way to determine which, out of all
these criteria, DigiCert is claiming conformance to. Short of manually
inspecting CP/CPSes.

This is where the OID nightmare comes from. There are 15 versions of the
BRs. There are three versions of WebTrust for BRs. I haven't bothered to
count how many ETSI versions. From the DigiCert repository (
http://www.digicert.com/ssl-cps-repository.htm ) I see there have been
four versions of your CP/CPS since the BRs went into effect.

And this, of course, ignores the practice that some CAs (but presumably
not Digicert) practice, of 'backdating' the issuance date of certs for
compatibility reasons (or, allegedly, accounting, although that's a bit
specious).

[nick...@lugatech.com]

Ryan does, in my opinion, make valid criticism here.

It would seem necessary, for this exercise to be truly worthwhile, to be in the position where the mandated inclusion of these OIDs determined which revision of the BRs a certificate was actually issued under.

So, why not modify the BRs so that section 9.3.1 also encodes the revision of the BRs in the OID? This is not a proliferation of OIDs and is easily handled programmatically.

For example, to specify issuance under a hypothetical 1.1.9:

2.23.140.1.2.1.1.1.9

2.23.140.1.2.2.1.1.9

Such a change would also by nature signify that it was issued at the point where such inclusion was mandated and not optional.

Some of the private OIDs that CAs already include that become unnecessary because of the change could be deprecated and removed over time.

Nick

[Ryan Sleevi]

On Sun, July 27, 2014 10:03 pm, nick...@lugatech.com wrote:
> So, why not modify the BRs so that section 9.3.1 also encodes the revision
> of the BRs in the OID? This is not a proliferation of OIDs and is easily
> handled programmatically.

Because that's now how certificate policies work. See RFC 5280.

http://www.ietf.org/rfc/rfc5280.txt

[Jeremy Rowley]

Per our CPS and the BR/EV requirements, we always abide by the latest version of the BRs

>From Section 8.3:
" [Name of CA] conforms to the current version of the CA/Browser Forum Guidelines for Issuance and Management of Extended Validation Certificates published at http://www.cabforum.org. In the event of any inconsistency between this document and those Guidelines, those Guidelines take precedence over this document."

Therefore, any CA compliant would have to abide by the latest version, regardless of when their CPS is published. Asserting the appropriate OID in the certificate is an assertion of compliance with the latest version of the guidelines, meaning versioning is largely irrelevant.

Jeremy