My conclusion from this discussion is that we should not add an explicit requirement for EKUs in end-entity certificates. I've closed the issue.
- Wayne On Tue, Apr 16, 2019 at 9:56 AM Ryan Sleevi via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Tue, Apr 16, 2019 at 12:41 PM Jakob Bohm via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > On 16/04/2019 08:56, Tadahiko Ito wrote: > > > On Tuesday, April 2, 2019 at 9:36:06 AM UTC+9, Brian Smith wrote: > > > > > >> I agree the requirements are already clear. The problem is not the > > clarity > > >> of the requirements. Anybody can define a new EKU because EKUs are > > listed > > >> in the certificate by OIDs, and anybody can make up an EKU. A standard > > >> isn't required for a new OID. Further, not agreeing on a specific EKU > > OID > > >> for a particular kind of usage is poor practice, and we should > > discourage > > >> that poor practice. > > >> > > > > > > It is good that anyone can make OID, so we do not need to violate > policy. > > > > > > However, I have following concerns with increasing private OIDs in the > > world. > > > -I think that OID should be CA’s private OID or public OID. because, in > > the case of a CA is going to out of business, and that business was cared > > by another CA, we would not want those two CA using same OID for > different > > usage. > > > -In the other hand, CA’s private OIDs will reduce interoperability, > > which seems to be problematic, > > > -web browser might just ignore private OIDs, but I am not sure other > > certificate verification applications, > > > which is used for certificate of that private EKU OID. > > > > > > over all, I think we should have some kind of public OIDs, at least for > > widely use purpose. > > > > > > I believe if it were used for internet, we can write Internet-Draft, > and > > ask OIDs on RFC3280 EKU repo. > > > #I am planing to try that. > > > > > > > The common way to create an OID is to get an OID assigned to your (CA) > > business, either through a national standards organization or by getting > > an "enterprise ID" from IANA. > > > > Then append self-chosen suffixes to subdivide your new (near infinite) > > OID name space. For example, if your national standards organization > > assigned your CA the OID "9.99.999.9999" (not actually a valid OID btw), > > you could subdivide like this (fun example). > > > > 9.99.999.9999.1 - Certificate policies > > 9.99.999.9999.1.1 - Your test certificates policy > > 9.99.999.9999.1.1.2019.3.12 - March 12, 2019 version of that policy > > 9.99.999.9999.1.2 - Your EV policy > > 9.99.999.9999.2 - EKUs > > 9.99.999.9999.2.1 - CA internal Database backup signatures > > 9.99.999.9999.2.2 - login certificates for the secure room door lock > > 9.99.999.9999.2.3 - Gateway certificates for custom protocol X > > 9.99.999.9999.3 - Custom DN elements > > 9.99.999.9999.3.1 - Paygrade > > 9.99.999.9999.4 - Certificate/CMS/CRL/OCSP extensions > > 9.99.999.9999.4.1 - Date and location of photo ID validation > > 9.99.999.9999.5 - Algorithms > > 9.99.999.9999.5.1 - Caesar encryption. > > 9.99.999.9999.5.2 - CRC8 hash > > 9.99.999.9999.99999 - East company division > > 9.99.999.9999.99999.999999.9999999 - This is getting silly. > > > > Etc. > > > > A different CA would have (by the hierarchical nature of the OID system) > > a different assigned OID such as 9.88.999.9999 thus not overlapping. > > > > Thus no risk of conflicting uses unless someone breaks the basic OID > > rules. The actual risk (as illustrated by EV) is getting too many > > different OIDs for the same thing. > > > > I don't believe there was any confusion about that. Indeed, the message > you're replying to already acknowledges that CAs can do exactly that. > > The only concern, it seems, which this message does not address at all, was > about the desire to have a common OID used across multiple CAs for > particular use cases, so that relying party software can trust certificates > from multiple (different) CAs and validate the end-entity certificates as > appropriate for that OID. > > I think the substance of the message being replied to was missed, and > hopefully that clarification helps. > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
