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 List openssl-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 List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
