Michael Ströder wrote:
>
> Dr Stephen Henson wrote:
> >
> > Michael Ströder wrote:
> > >
> > > http://www.microsoft.com/security/tech/certificates/structuring.asp
> >
> > I wouldn't recommend that document:
> > [..]
> > Following the advice here caused me lots of trouble.
>
> Can you give some details about the troubles you had?
>
Well believing it was one problem :-)
IE5 cures many of the issues so I'll mention some of the problems for
historical purposes only.
At the time that document was written though following that advice would
result in certificates that were either rejected outright for no
apparent reason or behaved oddly.
The critical problem caused some fun because perfectly valid
certificates were rejected that followed MS own advice! I spent a whole
day messing around with that :-(
Another issue was the CRLDistribution points behaviour. Now I knew that
some kind of revocation checking took place because authenticode did it
and I assumed that CRLDistribution points was being handled: after much
messing around I found that authenticode managed its rev checking via an
undocumented DLL with some weird stuff hard coded and CRLDistribution
points was ignored.
Certificate policies was another oddity. It recommends you include that
in all certificates. Well at the time if you did it would then display a
hard coded copy of Verisigns CPS no matter what you put in there.
Netscape has problems of its own of course...
> > Over a year after
> > its date later I duly followed the advice about critical extensions only
> > to find the version of Outlook at the time rejected them.
>
> I set my keyUsage and extendedKeyUsage attributes according to the
> document I mentioned above but did not mark any attribute critical. The
> descriptions of keyUsage and extended KeyUsage seemed to make sense to
> me. Will this cause trouble to cert users?
>
This might cause problems with future OpenSSL versions in particular the
next release.
Previously OpenSSL ignored certificate extensions and the application
writer had to take steps to avoid security holes by crippling the
certificate verify mechanism to short pathlengths or only one untrusted
certificate.
OpenSSL 0.9.5 will include some checks on extensions which will
hopefully allow certificate chains to be properly checked. However as a
result it will reject invalid extensions: or at least invalid extensions
that it hasn't got a workaround for.
I suggest you get the latest snapshot and read the documentation for
things like the 'x509' and 'verify' utilities and try verifying a few
certs.
Anyway I need some people to try this out before its official: I'd
rather not have a deluge of emails saying it rejected certificates just
after its released.
> Examples:
>
> CA certs:
> basicConstraints = CA:true
> keyUsage = cRLSign, keyCertSign
> extendedKeyUsage = 1.3.6.1.5.5.7.3.4
> (I know that basicConstraints = CA:true should be marked critical but
> according to doc/openssl.txt this might cause trouble with older
> applications...)
>
extendedKeyUsage should be set to a list of purposes the CA will be used
for in the latest version of OpenSSL or left out completely. That
value is Email. So if you use it to sign S/MIME email certs you should
be fine. Anything else it will reject.
If you want a general purpose CA then just omit extendedKeyUsage
> Certs only used for e-mail (encryption and signing):
> keyUsage = keyEncipherment, dataEncipherment,
> digitalSignature, nonRepudiation
> nsCertType = email
>
dataEncipherment isn't needed. Also you might want to set
extendedKeyUsage to emailProtection.
> Certs only used for client authentication:
> keyUsage = digitalSignature, nonRepudiation, keyAgreement
> extendedKeyUsage = 1.3.6.1.5.5.7.3.2
> nsCertType = client
>
keyAgreement isn't needed: its only used for DH certs which OpenSSL
doesn't (currently) support.
> Server certs:
> keyUsage = digitalSignature, nonRepudiation, keyEncipherment
> extendedKeyUsage = 1.3.6.1.5.5.7.3.1, msSGC,nsSGC
> nsCertType = server
> (msSGC,nsSGC only makes sense if the corresponding CA certs are tagged
> in a special way for enabling Server Gated Cryptography / Global Server
> ID)
>
OK.
> Object signing certs:
> keyUsage = keyEncipherment, dataEncipherment, digitalSignature,
> nonRepudiation, keyAgreement
> extendedKeyUsage = 1.3.6.1.5.5.7.3.3
> nsCertType = objsign
>
keyUsage: digitalSignature, nonRepudiation only are needed.
> Will I have problems with these X.509v3 attributes? Any suggestions for
> improving it? Maybe it's worth discussing a good example configuration
> here.
That stuff is largely OK but a few general comments.
If the certificate is not a CA certificate its best to include
basicConstraints=CA:FALSE. This goes against the advice of RFC2459 but
its still legal and some MS software needs to be forcably told it isn't
a CA certificate.
Also some of the extendedKeyUsage's OIDs have meaningful short names
which can be used in preference to the numerical form (see latest
doc/openssl.txt). If you get the short name wrong it will probably
produce an error message, if you get the numerical form wrong it just
wont work properly and problems may not be apparent until lots of
certificates have been issued.
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]
