Re: [openssl-users] Re: Bad OIDs
Le 28/11/2013 22:18, Rob Stradling a écrit : On 28/11/13 15:14, 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. It's crazier than that. RFC5906 seems to think it can put a string into the EKU extension rather than OID(s)! Appendix J says... Extended Key Usage. This field...contains the string Private if the certificate is designated private or the string trustRoot if it is designated trusted... And the reference code uses the strings Trust Root and Private. I subscribed and sent a series of questions on this yesterday, it's still pending for moderation. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Re: Bad OIDs
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.
Re: [openssl-users] Re: Bad OIDs
Le 29/11/2013 17:53, Erwann Abalea a écrit : Le 29/11/2013 16:25, Dr. Stephen Henson a écrit : 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. Technically, the NID_* version of those OIDs are not used by ntpd. For each extension found, an X509V3_EXT_print() is done on the extension, the result is strcmp() with Trust Root and/or Private, and internal flags are set. I'm not sure this code works anyway.
Re: [openssl-users] Re: Bad OIDs
On Fri, Nov 29, 2013, Erwann Abalea wrote: Le 29/11/2013 17:53, Erwann Abalea a écrit : Le 29/11/2013 16:25, Dr. Stephen Henson a écrit : 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. Technically, the NID_* version of those OIDs are not used by ntpd. For each extension found, an X509V3_EXT_print() is done on the extension, the result is strcmp() with Trust Root and/or Private, and internal flags are set. I'm not sure this code works anyway. I wonder if little Bobby Tables every got a certificate. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
