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