Rich is right. A recursive trial-and-error is the way to go. It should be
combined with extension checking.
It�s sad that Openssl discards keyusage restrictions and other extensions, as
they are definitely not there for being discarded.
If KeyUsage would be obeyed during certificate verification in OpenSSL the
certificate lookup would include not only to look for a match for the issuer but
also to look for a match for the intended use of the public key in the
certificate asked for. That means basically that a lookup for a certificate for
a key to verify another would discard certificates having not the subjectname
(or issuer/serialnumber or subjectkeyidentifier) asked for, or, if present, a
KeyUsage field with CertSign not set, or, if present, a basicConstraints with CA
not set. Both extensions should be checked if they are critical at least. If you
hunt through the list of extensions currently specified more search criteria pop
up, like matching certification-policies. Of course, if the CA certificate is V1
(shouldn't) you are back to subject-only lookup.
[For the curious: The whole thing is about giving a properly setup CA a chance
to restrict the use of keys they have issued certificates for. This can both
protect the CA and the user. A user may not want to be confronted with a
document signed by his or her encryption key (as that may be in escrow, the
signing key may not). A CA may not want to be confronted with a certificate
signed by one of its users.]
Finally, a certificate verification procedure should always be able to handle
the situation where more then one certificate is present which match the search
criteria. E.g. you may be presented with a database that contains both several
root and cross-certificates between each other. Eventually you end up with
recursive trial-and-error, if nothing else works.
So the basic rules goes: collect all certificates which seem applicable, and try
them out in turn, until you resolve to a key that the user or configurator has
explicitely marked as "trusted" for the desired purpose (mostly for being a CA).
-----Urspr�ngliche Nachricht-----
Von: MIME:[EMAIL PROTECTED]
Gesendet am: Donnerstag, 2. September 1999 19:36
An: -:[EMAIL PROTECTED]; Olaf Schlueter
Betreff: RE: Cert verification problems.
>OpenSSL can't do this automatically at present because it ignores
>certificate extensions and its X509_LOOKUP mechanism can only return
>single matching certificates for a given subject name.
Perhaps the easiest fix would be, if signature verification fails, see if
there are any other certs with the same DN. Won't this be necessary when
a CA rekeys, anyway?
{\rtf1\ansi \deff0\deflang1024{\fonttbl{\f0\froman Tms Rmn;}{\f1\froman Symbol;}{\f2\fswiss Helv;}}
{\colortbl;\red0\green0\blue127;\red0\green127\blue0;\red0\green127\blue127;\red127\green0\blue0;
\red127\green0\blue127;\red127\green127\blue0;\red127\green127\blue127;;\red0\green0\blue255;
\red0\green255\blue0;\red0\green255\blue255;\red255\green0\blue0;\red255\green0\blue255;
\red255\green255\blue0;\red255\green255\blue255;}\paperw12240\paperh15840\margl1800\margr1800\margt1440\margb1440
\gutter0 \defformat\sectd \pard\plain {\plain \f0 \cb7 \cf0 ically that a lookup for a certificate for\
a key to verify another would discard certificates having not the subjectname\
(or issuer/serialnumber or subjectkeyidentifier) asked for, or, if present, a\
KeyUsage field with CertSign not set, or, if present, a basicConstraints with CA\
not set. Both extensions should be checked if they are critical at least. If you\
hunt through the list of extensions currently specified more search criteria pop\
up, like matching certification-policies. Of course, if the CA cverification procedure should always be able to handle\
the situation where more then one certificate is present which match the search\
criteria. E.g. you may be presented with a database that contains both several\
root and cross-certificates between each other. Eventually you end up with\
recursive trial-and-error, if nothing else works. \
\
So the basic rules goes: collect all certificates which seem applicable, and try\
them out in turn, until you resolve to a key that the user or configurator has\
expd be, if signature verification fails, see if\
there are any other certs with the same DN. Won't this be necessary when\
a CA rekeys, anyway?\
\
esendet am: Donnerstag, 2. September 1999 19:36\
An: -:[EMAIL PROTECTED]; Olaf Schlueter\
Betreff: RE: Cert verification problems.\
\
>OpenSSL can't do this automatically at present because it ignores\
>certificate extensions and its X509_LOOKUP mechanism can only return\
>single matching certificates for a given subject name.\
\
Perhaps the easiest fix would be, if signature verification fails, see if\
there are any other certs with the same DN. Won't this be necessary when\
a CA rekeys, anyway?\
\
esendet am: Donnerstag, 2. September 1999 19:36\
An: -:[EMAIL PROTECTED]; Olaf Schlueter\
Betreff: RE: Cert verification problems.\
\
>OpenSSL can't do this automatically at present because it ignores\
>certificate extensions and its X509_LOOKUP mechanism can only return\
>single matching certificates for a given subject name.\
\
Perhaps the easiest fix would be, if signature verification fails, see if\
there are any other certs with the same DN. Won't this be necessary when\
a CA rekeys, anyway?\
\
esendet am: Donnerstag, 2. September 1999 19:36\
An: -:[EMAIL PROTECTED]; Olaf Schlueter\
Betreff: RE: Cert verification problems.\
\
>OpenSSL can't do this automatically at present because it ignores\
>certificate extensions and its X509_LOOKUP mechanism can only return\
>single matching certificates for a given subject name.\
\
Perhaps the easiest fix would be, if signature verification fails, see if\
there are any other certs with the same DN. Won't this be necessary when\
a CA rekeys, anyway?\
\
\par }}
