ITU-T recommendations for X.509v3 certificates

[Florian Weimer]

* Peter Gutmann:

>>Or is it unreasonable to expect that the specs match what is actually needed
>>for interoperability with existing implementations (mostly in the TLS, S/MIME
>>area)?
>
> There is very little correspondence between PKI specs and reality.

I should have written that my main goal was to extract the public key
material, and perhaps the validity period.  I want to use the
certificates as interoperable public key containers, mainly in order to
be able to rely on proven TLS implementations for encryption and
authentication.

> The brokenness in X.509 implementations creates a self-sustaining cycle in
> which applications that accept certs are more or less oblivious to anything
> that's in the cert (beyond basic stuff like correct formatting and encoding,
> and so on), so you can get away with almost anything (and then in turn because
> apps will accept anything, cert creators can create arbitrarily broken certs
> without being caught out by it, so the cycle is self-sustaining).

I guess parsing X.509 certs to derive further semantic content is
comparable to mail header parsing.  That is a futile exercise, too, but
sometimes unavoidable (for finding spam injection points, for instance).

But to be honest, I really don't see the point of extracting further
data from the certificates.  I can't reach OCSP servers and CRL
distribution points anyway because they are firewalled off.  I still
need to map a DN to some application-specific entity, and I need to
grant specific capabilities to it because I don't want to grant blanket
permission to the CAs involved--but this means I can directly bind this
metadata to the certificate, using the DN instead does not really
simplify set-up.  The lack of indirection makes key rollover more
difficult, granted, but you don't have to deal with broken random number
generators every other day, so I'm not sure if this is such a bad
trade-off.

> If you want to be really lazy, use an X.509v1 cert where you don't even need
> to bother with extensions.  A downside (?) of this is that some applications
> will treat it as a CA root cert.

I've got a couple of X.509v1 certs with extensions in production use,
which are a bit difficult to phase out. 8-( Turns out that this is not
so interoperable after all.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com