Re: Bad OIDs (was: Re: Verification of a x509 certificate signature)
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. 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. 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
Bad OIDs (was: Re: Verification of a x509 certificate signature)
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. RFC5906 uses a trustRoot EKU, without any OID being proposed or referenced. Your certificate includes the later one in the EKU extension. -- Erwann ABALEA Le 28/11/2013 14:26, Dereck Hurtubise a écrit : It is NTP indicating that this certificate is held by a supposed trusted root (authority). This is NTP's way of figuring out if the certificate of the subject/issuer should be trusted or not. So they misuse X509 extensions for their own purposes. This alone is not enough. So they also implement a challenge/response scheme that they do after the certificates are verified. Read RFC 5906 (autokey) on the CERT message/exchange for more information and why they do this. The Trust Root is used in the identity exchange scheme after the CERT exchange. Also in the RFC. On Thu, Nov 28, 2013 at 2:07 PM, Walter H. walte...@mathemainzel.info mailto:walte...@mathemainzel.info wrote: Hi, On Wed, November 27, 2013 16:02, Dereck Hurtubise wrote: X509v3 Extended Key Usage: Trust Root what is this strange? 'Trust Root' as Extended Key Usage? __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org mailto:openssl-users@openssl.org Automated List Manager majord...@openssl.org mailto:majord...@openssl.org
Re: Bad OIDs (was: Re: Verification of a x509 certificate signature)
Welcome to the wonderful world of NTP Autokey. Where they misuse X509v3 extensions for their own purposes. Nothing I can do about it. It's in the specification of that RFC (5906) On Thu, Nov 28, 2013 at 4:14 PM, Erwann Abalea erwann.aba...@keynectis.comwrote: 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. RFC5906 uses a trustRoot EKU, without any OID being proposed or referenced. Your certificate includes the later one in the EKU extension. -- Erwann ABALEA Le 28/11/2013 14:26, Dereck Hurtubise a écrit : It is NTP indicating that this certificate is held by a supposed trusted root (authority). This is NTP's way of figuring out if the certificate of the subject/issuer should be trusted or not. So they misuse X509 extensions for their own purposes. This alone is not enough. So they also implement a challenge/response scheme that they do after the certificates are verified. Read RFC 5906 (autokey) on the CERT message/exchange for more information and why they do this. The Trust Root is used in the identity exchange scheme after the CERT exchange. Also in the RFC. On Thu, Nov 28, 2013 at 2:07 PM, Walter H. walte...@mathemainzel.infowrote: Hi, On Wed, November 27, 2013 16:02, Dereck Hurtubise wrote: X509v3 Extended Key Usage: Trust Root what is this strange? 'Trust Root' as Extended Key Usage? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
