Re: RE: Callback suggestion for unsupported cert extensions
On Thu, Jun 04, 2009, Brad Mitchell wrote: > If that's the case then I don't see why openssl shouldn't know about these > extensions. Especially if they have been in certificates since Windows 2003 > at the very least > "Knowing about" an extension is one thing, deciding what to do with it is another thing entirely. That's why RFC5280 et al have the strict language they do. If an extension is critical the CA is saying "you MUST understand what this bit means and do the right thing". They have decided that the extension provides critical information about the certificate and just ignoring it is not appropriate. The "do the right thing" bit needs documentation about how the extension is encoded and how it should be processed. Doing that properly needs additional code. BTW there *is* a callback of sorts for this: the standard verification callback is usable. It's a little more awkward because it doesn't tell you what extension it is objecting to. You could however examine the errant certificate for critical extensions and return "OK" if it contained internally supported extensions and any extra critical ones you want the application to process. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: RE: Callback suggestion for unsupported cert extensions
If that's the case then I don't see why openssl shouldn't know about these extensions. Especially if they have been in certificates since Windows 2003 at the very least Brad -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Victor B. Wagner Sent: Thursday, 4 June 2009 9:02 PM To: openssl-users@openssl.org Subject: Re: RE: Callback suggestion for unsupported cert extensions On 2009.06.04 at 16:00:38 +1000, Brad Mitchell wrote: > The thing is, RFC3280 states... > > Implementors are warned that the X.500 standards community has >developed a series of extensibility rules. These rules determine >when an ASN.1 definition can be changed without assigning a new >object identifier (OID). For example, at least two extension >definitions included in RFC 2459 [RFC 2459], the predecessor to this >profile document, have different ASN.1 definitions in this >specification, but the same OID is used. If unknown elements appear >within an extension, and the extension is not marked critical, those >unknown elements ought to be ignored, as follows: [skip] >If an extension containing unexpected values is marked critical, the >implementation MUST reject the certificate or CRL containing the >unrecognized extension. > > > ^^ This pretty much means if there is an unexpected value and it is critical > then it has to be rejected. > This is about unexpected values in KNOWN extension. Not about totally new extension with new OID. I was unable to find in the section 6 of RFC3280 any mention of totally unknown extension. > I'm not sure how Microsoft would like their "private" extensions being > listed in openssl. You would think from a standards compliance POV they > would welcome it but who knows. These private extensions are declared in some .h files of published Microsoft API, and, may be, even documented somewhere in MSDN. At least for Windows version of openssl this information is available from Microsoft at build time. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.339 / Virus Database: 270.12.51/2151 - Release Date: 06/03/09 18:00:00 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Callback suggestion for unsupported cert extensions
"Victor B. Wagner" writes: [...] > This is about unexpected values in KNOWN extension. Not about totally > new extension with new OID. I think you're misreading it---I think it's talking about unexpected extensions. In any case I think the language in RFC 5280 makes it clearer (and we should assume that this was the intent of 3280): A certificate-using system MUST reject the certificate if it encounters a critical extension it does not recognize or a critical extension that contains information that it cannot process. A non-critical extension MAY be ignored if it is not recognized, but MUST be processed if it is recognized. [...] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: RE: Callback suggestion for unsupported cert extensions
On 2009.06.04 at 16:00:38 +1000, Brad Mitchell wrote: > The thing is, RFC3280 states... > > Implementors are warned that the X.500 standards community has >developed a series of extensibility rules. These rules determine >when an ASN.1 definition can be changed without assigning a new >object identifier (OID). For example, at least two extension >definitions included in RFC 2459 [RFC 2459], the predecessor to this >profile document, have different ASN.1 definitions in this >specification, but the same OID is used. If unknown elements appear >within an extension, and the extension is not marked critical, those >unknown elements ought to be ignored, as follows: [skip] >If an extension containing unexpected values is marked critical, the >implementation MUST reject the certificate or CRL containing the >unrecognized extension. > > > ^^ This pretty much means if there is an unexpected value and it is critical > then it has to be rejected. > This is about unexpected values in KNOWN extension. Not about totally new extension with new OID. I was unable to find in the section 6 of RFC3280 any mention of totally unknown extension. > I'm not sure how Microsoft would like their "private" extensions being > listed in openssl. You would think from a standards compliance POV they > would welcome it but who knows. These private extensions are declared in some .h files of published Microsoft API, and, may be, even documented somewhere in MSDN. At least for Windows version of openssl this information is available from Microsoft at build time. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Callback suggestion for unsupported cert extensions
There are also strict rules regarding the certificate validation process, which openssl will let you entirely "pre-empt" and completely take over the validation process. All we would be asking for would be a callback that lets us "extend" the functionality of openssl regarding cert extensions. In your case, because you need to stick with "unmodified" openssl code, using a command-line operation, this may not help you as much. Randy On Jun 3, 2009, at 11:00 PM, Brad Mitchell wrote: The thing is, RFC3280 states... Implementors are warned that the X.500 standards community has developed a series of extensibility rules. These rules determine when an ASN.1 definition can be changed without assigning a new object identifier (OID). For example, at least two extension definitions included in RFC 2459 [RFC 2459], the predecessor to this profile document, have different ASN.1 definitions in this specification, but the same OID is used. If unknown elements appear within an extension, and the extension is not marked critical, those unknown elements ought to be ignored, as follows: (a) ignore all unknown bit name assignments within a bit string; (b) ignore all unknown named numbers in an ENUMERATED type or INTEGER type that is being used in the enumerated style, provided the number occurs as an optional element of a SET or SEQUENCE; and (c) ignore all unknown elements in SETs, at the end of SEQUENCEs, or in CHOICEs where the CHOICE is itself an optional element of a SET or SEQUENCE. If an extension containing unexpected values is marked critical, the implementation MUST reject the certificate or CRL containing the unrecognized extension. ^^ This pretty much means if there is an unexpected value and it is critical then it has to be rejected. I'm not sure how Microsoft would like their "private" extensions being listed in openssl. You would think from a standards compliance POV they would welcome it but who knows. Brad -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Randy Turner Sent: Thursday, 4 June 2009 3:48 PM To: openssl-users@openssl.org Subject: Re: Callback suggestion for unsupported cert extensions I agree that there should probably be a callback for extensions not recognized and supported by OpenSSL...the callback could return a failure code that openssl would look at, and if it is set to an "error" then openssl would run it's normal failure return path (up the call stack). If the callback returns SUCCESS, then keep going... If a plugin is not registered for handling unknown extensions, then maybe the code should follow a configuration flag that says ["fail" on unknown extension] or [ignore unknown extensions] Randy On Jun 3, 2009, at 10:41 PM, Victor B. Wagner wrote: On 2009.06.04 at 09:04:11 +1000, Brad Mitchell wrote: The reason we use command-line utilities to verify is for transparency. Data could be used in the courts for example and having that "hey.. go download openssl and verify it yourself" is a lot better than.. here is a util we wrote to verify the token. WHAT? Your util? sure. So the issue with ignoring those extensions within your own app will probably work for you depending on your situation. In my case, it is not really an option. I'm not really sure why this particular extension is marked as critical. It does seem a bit weird. Microsoft aren't exactly the most compliant company out there when it comes to some industry standards... Hm, description of the X509_F_FLAG_INGORE_CRITICAL reads "Ignore UNKNOWN critical extensions". May be it is better to make these Microsoft-specific extension KNOWN to OpenSSL, even it wouldn't do anything with their values. Just "a thing which MS-CA can put into certificate, and mark critical, which doesn't affect verification process". It is quite easy to do: just add OID of this extension into objects.txt with suitable shortname and longname, and add it into array in the X509_supported_extension function. Really I think it might be worth effort to make list of supported-extensions user-configurable. Applications can handle extensions, which are not supported by OpenSSL itself using verify callback function. __ OpenSSL Project http:// www.openssl.org User Support Mailing Listopenssl- us...@openssl.org Automated List Manager majord...@openssl.org No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.339 / Virus Database: 270.12.51/2151 - Release Date: 06/03/09 18:00:00 __ OpenSSL Project
RE: Callback suggestion for unsupported cert extensions
The thing is, RFC3280 states... Implementors are warned that the X.500 standards community has developed a series of extensibility rules. These rules determine when an ASN.1 definition can be changed without assigning a new object identifier (OID). For example, at least two extension definitions included in RFC 2459 [RFC 2459], the predecessor to this profile document, have different ASN.1 definitions in this specification, but the same OID is used. If unknown elements appear within an extension, and the extension is not marked critical, those unknown elements ought to be ignored, as follows: (a) ignore all unknown bit name assignments within a bit string; (b) ignore all unknown named numbers in an ENUMERATED type or INTEGER type that is being used in the enumerated style, provided the number occurs as an optional element of a SET or SEQUENCE; and (c) ignore all unknown elements in SETs, at the end of SEQUENCEs, or in CHOICEs where the CHOICE is itself an optional element of a SET or SEQUENCE. If an extension containing unexpected values is marked critical, the implementation MUST reject the certificate or CRL containing the unrecognized extension. ^^ This pretty much means if there is an unexpected value and it is critical then it has to be rejected. I'm not sure how Microsoft would like their "private" extensions being listed in openssl. You would think from a standards compliance POV they would welcome it but who knows. Brad -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Randy Turner Sent: Thursday, 4 June 2009 3:48 PM To: openssl-users@openssl.org Subject: Re: Callback suggestion for unsupported cert extensions I agree that there should probably be a callback for extensions not recognized and supported by OpenSSL...the callback could return a failure code that openssl would look at, and if it is set to an "error" then openssl would run it's normal failure return path (up the call stack). If the callback returns SUCCESS, then keep going... If a plugin is not registered for handling unknown extensions, then maybe the code should follow a configuration flag that says ["fail" on unknown extension] or [ignore unknown extensions] Randy On Jun 3, 2009, at 10:41 PM, Victor B. Wagner wrote: > On 2009.06.04 at 09:04:11 +1000, Brad Mitchell wrote: > >> >> The reason we use command-line utilities to verify is for >> transparency. >> Data could be used in the courts for example and having that "hey.. >> go >> download openssl and verify it yourself" is a lot better than.. >> here is a >> util we wrote to verify the token. WHAT? Your util? sure. >> >> So the issue with ignoring those extensions within your own app will >> probably work for you depending on your situation. In my case, it >> is not >> really an option. >> >> I'm not really sure why this particular extension is marked as >> critical. It >> does seem a bit weird. Microsoft aren't exactly the most compliant >> company >> out there when it comes to some industry standards... > > Hm, description of the X509_F_FLAG_INGORE_CRITICAL reads "Ignore > UNKNOWN > critical extensions". May be it is better to make these > Microsoft-specific extension KNOWN to OpenSSL, even it wouldn't do > anything with their values. > > Just "a thing which MS-CA can put into certificate, and mark critical, > which doesn't affect verification process". > > It is quite easy to do: > > just add OID of this extension into objects.txt with suitable > shortname > and longname, and add it into array in the X509_supported_extension > function. > > Really I think it might be worth effort to make list of > supported-extensions user-configurable. Applications can handle > extensions, which are not supported by OpenSSL itself using verify > callback function. > > > __ > OpenSSL Project http://www.openssl.org > User Support Mailing Listopenssl-users@openssl.org > Automated List Manager majord...@openssl.org > No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.339 / Virus Database: 270.12.51/2151 - Release Date: 06/03/09 18:00:00 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Callback suggestion for unsupported cert extensions
I agree that there should probably be a callback for extensions not recognized and supported by OpenSSL...the callback could return a failure code that openssl would look at, and if it is set to an "error" then openssl would run it's normal failure return path (up the call stack). If the callback returns SUCCESS, then keep going... If a plugin is not registered for handling unknown extensions, then maybe the code should follow a configuration flag that says ["fail" on unknown extension] or [ignore unknown extensions] Randy On Jun 3, 2009, at 10:41 PM, Victor B. Wagner wrote: On 2009.06.04 at 09:04:11 +1000, Brad Mitchell wrote: The reason we use command-line utilities to verify is for transparency. Data could be used in the courts for example and having that "hey.. go download openssl and verify it yourself" is a lot better than.. here is a util we wrote to verify the token. WHAT? Your util? sure. So the issue with ignoring those extensions within your own app will probably work for you depending on your situation. In my case, it is not really an option. I'm not really sure why this particular extension is marked as critical. It does seem a bit weird. Microsoft aren't exactly the most compliant company out there when it comes to some industry standards... Hm, description of the X509_F_FLAG_INGORE_CRITICAL reads "Ignore UNKNOWN critical extensions". May be it is better to make these Microsoft-specific extension KNOWN to OpenSSL, even it wouldn't do anything with their values. Just "a thing which MS-CA can put into certificate, and mark critical, which doesn't affect verification process". It is quite easy to do: just add OID of this extension into objects.txt with suitable shortname and longname, and add it into array in the X509_supported_extension function. Really I think it might be worth effort to make list of supported-extensions user-configurable. Applications can handle extensions, which are not supported by OpenSSL itself using verify callback function. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org smime.p7s Description: S/MIME cryptographic signature
