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
[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
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
Victor B. Wagner vi...@cryptocom.ru 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
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
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
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
