Le 29/11/2013 16:25, Dr. Stephen Henson a écrit :
On Thu, Nov 28, 2013, Erwann Abalea wrote:
How nice, they're asking for a self-signed certificate to include a
specific EKU to indicate it's a Trust Anchor, and the OID used for
this has never been allocated. Crazy.
I just looked at OpenSSL's objects.txt database, and found some OIDs
that need some change:
id-pkix-OCSP 8 : extendedStatus : Extended OCSP Status
should be "id-pkix-ocsp-pref-sig-algs" (RFC6960).
id-pkix-OCSP 9 : valid
should be id-pkix-ocsp-extended-revoke (RFC6960).
id-pkix-OCSP 10 : path
id-pkix-OCSP 11 : trustRoot : Trust Root
have never been defined by PKIX.
Weird.. I checked the OpenSSL OID history and those have been about since the
dawn of time... well July 2000 at any rate. They were added by Richard when
he created the scripts that handle objects.txt, no idea where they actually
came from.
Some of them seem to have been mentioned in old drafts.
"draft-ietf-pkix-ocsp-valid-00" mentions 2 new OIDs:
id-pkix-ocsp-valid-req and id-pkix-ocsp-valid-rsp.
"draft-ietf-pkix-ocsp-path-00" similarly mentions id-pkix-ocsp-path-req
and id-pkix-ocsp-path-rsp.
I have no idea where this trustRoot comes from; PHB then at Verisign
published "draft-ietf-pkix-ocspx-00" with more extensions, but all those
OIDs were on a branch below id-pkix-ocspx (which was a descendant of
id-pkix-ocsp); he also describe a structure named TrustRoot and a
corresponding id-pkix-ocspx-root OID for it, and similarly with
ExtendedStatus and OID id-pkix-ocspx-support.
But all those drafts were abandoned (after their version 00) and the
OIDs were never reserved.
Changing OIDs in the table is problematical. If anything uses them it could
break them in all sorts of ways. The NID_* entries would change and text based
lookup would no longer work.
The reference ntp server uses that trustRoot one, in fact. And as Rob
pointed, it compares the text representation of this OID with "Trust
Root" (the long form) to check if the certificate is trusted or not.
Similarly, if it finds a certificate with 1.3.6.1.4 OID (IANA private)
as a EKU, the long form will be "Private", and ntp will declare this
certificate as private+trusted.
I'm not sure OpenSSL should be bound to keep OIDs that were never
formally allocated and are incorrectly used. If anything relying on
those breaks, it's either experimental, or badly written, or improperly
specified. Not OpenSSL's fault.
Anyway, 8 and 9 should really be changed.
