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.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
