[cabfpub] Additional OIDs in end-entity certificates

[Kirk Hall]

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.

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.

Do Microsoft, Apple, and Mozilla agree?

From: Ryan Sleevi [mailto:sleevi at google.com]
Sent: Sunday, August 21, 2016 2:49 PM
To: Kirk Hall <Kirk.Hall at entrust.com>
Cc: CABFPub <public at cabforum.org>
Subject: Re: [cabfpub] Additional OIDs in end-entity certificates


On Sun, Aug 21, 2016 at 2:14 PM, Kirk Hall <Kirk.Hall at entrust.com<mailto:Kirk.Hall at entrust.com>> wrote:
On our recent teleconference, the Forum discussed what happens when there is a conflict between the naming requirements of the Baseline Requirements (generally at BR 7.1.4) and a conflicting local or national requirement.  The current issue will be discussed in the Minutes for the August 18 teleconference once approved, but it did occur to some of us that this kind of issue will arise again in the future.

One place where if could arise is with the EU’s eIDAS requirements.  See https://en.wikipedia.org/wiki/EIDAS

This email is not about eIDAS, but is intended to pose a simple question (mainly to the browsers):  if a CA wants to include a new OID of its choosing in a certificate (such as a specified eIDAS OID that means “This certificate complies with eIDAS regulations”), is there any reason not to allow that?  I understand that the browsers may choose to ignore such a new OID (for example, the browsers may decide “we will not give this eIDAS OID cert any special UI in the browser), but is there any technical reason for prohibiting CAs from including such extra OIDs in their certificates if they want to?  Do we need to limit what OIDs can be included in an end-entity certificate – and if so, why?

I'm not sure I understand your motivations for phrasing the question as you did, as it does seem somewhat separate from issued discussed in the (to be published) minutes. In particular, the concern was related to conflicting requirements, rather than additive requirements.

There is nothing in the BRs that prohibits multiple OIDs from being asserted in the certificatePolicies extension; merely, that AT LEAST one of the OIDs maps back to the CA's CP/CPS to a policy that indicates compliance with the BRs.

I think Jody gave me an explanation of why extra OIDs could be problematic for Windows, but I can’t remember what it was.

What about Apple, Mozilla, Google?  Any problems with CAs including an extra OID in a certificate?

Define problems? It would appear you're using the term to indicate technical problems, Baseline Requirements prohibitions, and general opinions/opposition. It's unclear if you're actually interested in the superset, or if you're trying to find out a specific one of those.

It's also unclear if you're trying to relate this to what was discussed (which I don't believe these questions do), based on your introduction of the topic, or if you're looking for clarification for an issue you recognize as orthogonal.


If there are no problems, I think we should perhaps amend the BRs to make it clear extra OIDs are permitted.

Could you please explain why you do not believe it's clear already? That is, what other interpretations from the language, as written, do you see, which would lead you to seeking clarification or rewording? Any attempt to make it clear first has to understand why it isn't clear already, and whether that lack of clarity is due to the wording itself or a lack of familiarity with the technical standards.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160821/41708251/attachment-0003.html>