[cabfpub] Additional OIDs in end-entity certificates

[Ryan Sleevi]

On Sun, Aug 21, 2016 at 3:07 PM, Kirk Hall <Kirk.Hall at entrust.com> wrote:

> That’s good news, Ryan – some have said that no OIDs are permitted in
> certificates except for those specified in the BRs and/or RFC 5280, etc.  I
> couldn’t see where that was specified so I thought I’d check with the
> browsers.  Sounds like Google has no objections to additional OIDs.
>

So long as those additional OIDs do not introduce conflicting requirements,
either within the validation of the fields or in the encoding of them
(which was the main topic of concern during the call).

This is no different than the notion that the validation procedures for
OV/IV/EV should be additive (build upon) the BRs, rather than
replace/supplant. If, for example, the profile of an EV certificate is
fully compliant with that of a DV certificate, then one can (but not
necessarily should) assert both the DV and EV policy OIDs.

Functionally, this indicates that the certificate has been validated to the
DV level, and the encoded profile is compliant with the requirements set
forth in the BRs, and then *above and beyond that*, information has been
validated to the EV level and the encoded profile is compliant with those
set forth in the EVG.

Assuming the other browsers take the same position, then in the future when
> a CA or a political jurisdiction wants extra markers in certificates for
> their own purposes, the Forum and the browsers won’t have to get involved.
>

I'm not sure my response, or your interpretation, supports the last part of
that statement.

1) I answered only in the context of the technical profile supported by the
BRs and RFC 5280, for which they allow multiple expressions of policy OIDs.
I did not, however, make any statements or claims to how client libraries
handle such certificates, for which there may be a concern within the Forum
to ensure maximum interoperability of certificates.
2) The additional markers are only suitable to the extent that they are
additive upon the existing requirements, and do not materially change or
conflict with the requirements for the Forum-policies being asserted. If
they are in conflict, that is a matter for the Forum and browsers to be
involved in.
3) Further, if they are in conflict, the notion of jurisdictional reforms
within the BRs are extremely relevant, to ensure that CAs properly
understand the distinction between MUST and MAY.

So no, I don't believe "the Forum and the browsers won't have to get
involved" is a correct summary of the issue, but to the question of "Can
multiple policy OIDs be included in a certificate" - RFC 5280 permits this,
and the BRs permit this provided that no conflicts exist. In the existence
of conflicts, it intrinsically requires some degree of Forum and Browser
involvement.

To perhaps alternatively state this, since the nuance appears to not have
been clear:
Imagine a CA's CPS states we use policy ID "Foo" to indicate a cert issued
following the BRs' DV policy. This CA may assert the following policies:
a) 2 policies: "Foo" + 2.23.140.1.2.1
b) 1 policy: 2.23.140.1.2.1
c) 1 policy: "Foo"

For most CAs (such as your past and present employer), they opt for Option
C - indicating the CA's specific policy, which may be the same as the BRs
DV policy or may be additive upon it (e.g. "We only issue these certs to
citizens of Country X, Y, Z").

Jody's proposed Microsoft policy changes (which may CAs objected to) would
have required Option B, to some extent. Understandably, it was pointed out
the technical concern with this (the reissued of intermediates), so under
Microsoft's present program requirements, CAs MUST use either Option A or
Option B - which it appears not many CAs have started doing (yet).

The requirement to use Option A, FWIW, comes from http://aka.ms/rootcert ,
Section 4, Sub-section A, Item 15, which requires that the CA MUST include
the DV OID - but, like the BRs, makes no statement regarding other OIDs.

However, this only applies to the extent that "Foo" is fully compatible
with 2.23.140.1.2.1. If it was not, we're back to what we were discussing
on the call - how to resolve that conflict.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160821/2056407e/attachment-0003.html>