Dr S N Henson wrote:
>
> "Douglas E. Engert" wrote:
> >
> > It does not appear there is any code in OpenSSL to make sure all critical
> > extensions are checked during a verify. This could be considered a bug.
> > The default behavior should be to reject any critical extensions which are
> > not understood.
> >
>
> There are also lots of things OpenSSL verify "should" do but it doesn't
> to work around various buggy certificates in common usage.
>
> I think if it followed the letter of RFC2459 it would create
> certificates which would crash a lot of software and reject at least
> half of the certificates in common usage.
>
> A flag could be added to the verify code to reject certificates with
> unsupported critical extensions or make that the default behaviour and a
> flag to tolerate certificates with unsupported critical extensions.
Good idea, make the default to reject. This would then follow the spirit
of RFC2459.
>
> >
> > I would like to propose that the extensions be checked by a combination of
> > the OpenSSL code and the verify callback. As each extension is processed,
> > and is accepted, a flag be set saying such. This would be done both by the
> > OPenSSL code and the verify callback. After all verify processing is done,
> > if there are any critical extensions still unchecked, the verify would fail.
> > This would then not allow any new critical extensions to slip by as is the case
> > today.
> >
> > A possible way to do this would be to add an stack of extensions check flags
> > to the X509_CERT_AUX. It would be initialized with the list of extensions as
> > all being unchecked. As the verify and verify callback proceed, they would each
> > update this indicating the extension had been checked and acceptable.
> > Then as the last step in a verify, the stack would be checked to make sure there
> > where no missed extensions.
> >
>
> Hmmm how about a new verify error code meaning "unhandled crtical
> extension" and the callback could then override it if it handled the
> extension?
Yes that would help alot. Yes force the callback to accept the extension, with the
default being if there is no callback the verify fails.
>
> It would also be possible to provide a list of NIDs of supported
> extensions so an application could query those which OpenSSL handles
> internally.
Yes, we where going to look at the code and in effect come up with such a list
manually for our verify_callback.
>
> Steve.
> --
> Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/
> Personal Email: [EMAIL PROTECTED]
> Senior crypto engineer, Celo Communications: http://www.celocom.com/
> Core developer of the OpenSSL project: http://www.openssl.org/
> Business Email: [EMAIL PROTECTED] PGP key: via homepage.
>
> ______________________________________________________________________
> OpenSSL Project http://www.openssl.org
> Development Mailing List [EMAIL PROTECTED]
> Automated List Manager [EMAIL PROTECTED]
--
Douglas E. Engert <[EMAIL PROTECTED]>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
