application/pkix-pkipath

Fri May 24 05:31:19 CEST 2002

-----BEGIN PGP SIGNED MESSAGE-----

Peter Williams wrote:
> All certs must comply with PKIX, it says. There are very real
> communities of TLS users who use a non-PKIX profile of certs.

- From RFC 2246, section 7.4.2:

# All certificate profiles, key and cryptographic formats are defined
# by the IETF PKIX working group [ref. to RFC 2459].

(In context, this applies only to X.509 formats. If other formats were
added they obviously wouldn't be defined by PKIX. This should be made
clearer in RFC2246-bis.)

Which communities of TLS users are (deliberately, rather than just as
a result of bugs) using non-PKIX-conformant X.509 certs, and why?

> They should not be excluded from the use of the TLS proposed extensions.
> There is nothing inherent in the nature of TLS or the extended handling
> that requires that PKIX-designated controls be enforced.

That's true, but specifying PKIX improves interoperability. It's not a
new requirement; it is just clarifying how a requirement that is already
in RFC 2246 applies for this type.

> TLS should continue to be able to maintain current
> interoperability AND exploit some of the newer extensions
> even when certificates are not the means of distributing
> public keys for the asymmetric cipher suites, as per
> traditional SSL design.

We (the extensions spec authors) were very careful not to do anything that
would preclude or create problems for other public key authentication
methods than X.509 certs. I don't see any good argument for using
non-PKIX X.509 certs, though.

- -- 
David Hopwood <david.hopwood at zetnet.co.uk>

Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip