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, providedthe 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 criticalthen it has to be rejected. I'm not sure how Microsoft would like their "private" extensions beinglisted in openssl. You would think from a standards compliance POV theywould 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 List openssl- us...@openssl.org Automated List Manager majord...@openssl.orgNo virus found in this incoming message. Checked by AVG - www.avg.comVersion: 8.5.339 / Virus Database: 270.12.51/2151 - Release Date: 06/03/0918:00:00 ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
smime.p7s
Description: S/MIME cryptographic signature
