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
