Subject: RE: application/pkix-pkipath

From: Peter Williams <[email-masked]>
Date: Thu, 23 May 2002 11:36:52 -0700

All certs must comply with PKIX, it says. There
are very real communities of TLS users who use a non-PKIX
profile of certs. 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. 

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.

>>>>-----Original Message-----
>>>>From: Housley, Russ [mailto:[email-masked]]
>>>>Sent: Thursday, May 23, 2002 10:47 AM
>>>>To: [email-masked]
>>>>Cc: [email-masked]; [email-masked]
>>>>Subject: Re: application/pkix-pkipath
>>>>
>>>>
>>>>
>>>>David:
>>>>
>>>>The registration says: "... an update to [PKIX] ..."
>>>>
>>>>That update is (finally) finished.  See RFC 3280.
>>>>Please reference RFC 3280 (not RFC 2459).
>>>>
>>>>Russ
>>>>
>>>>
>>>>
>>>>At 04:08 PM 5/23/2002 +0000, David Hopwood wrote:
>>>>
>>>>>-----BEGIN PGP SIGNED MESSAGE-----
>>>>>
>>>>>The following template is from the Standards Track I-D
>>>>><draft-ietf-tls-extensions-04.txt>, which has just been submitted
>>>>>for Last Call in the TLS WG. It's intended to be 
>>>>consistent with the
>>>>>types application/pkix-{cert,crl} from RFC 2585.
>>>>>
>>>>>(Note: Reply-To is set to the ietf-types list only.)
>>>>>
>>>>>
>>>>>    To: [email-masked]
>>>>>    Subject: Registration of MIME media type 
>>>>application/pkix-pkipath
>>>>>
>>>>>    MIME media type name: application
>>>>>
>>>>>    MIME subtype name: pkix-pkipath
>>>>>
>>>>>    Required parameters: none
>>>>>
>>>>>    Optional parameters: version (default value is "1")
>>>>>
>>>>>    Encoding considerations:
>>>>>       This MIME type is a DER encoding of the ASN.1 type PkiPath,
>>>>>       defined as follows:
>>>>>
>>>>>          PkiPath ::= SEQUENCE OF Certificate
>>>>>
>>>>>          PkiPath is used to represent a certification 
>>>>path. Within the
>>>>>          sequence, the order of certificates is such that 
>>>>the subject of
>>>>>          the first certificate is the issuer of the 
>>>>second certificate,
>>>>>          etc.
>>>>>
>>>>>       This is identical to the definition that will be 
>>>>published in
>>>>>       [X509-4th-TC1]; note that it is different from that 
>>>>in [X509-4th].
>>>>>
>>>>>       All Certificates MUST conform to [PKIX] (an update 
>>>>to [PKIX] is
>>>>>       in preparation, and should be followed when it is 
>>>>published).
>>>>>       DER (as opposed to BER) encoding MUST be used. If 
>>>>this type is
>>>>>       sent over a 7-bit transport, base64 encoding SHOULD be used.
>>>>>
>>>>>    Security considerations:
>>>>>       The security considerations of [X509-4th] and [PKIX] (or any
>>>>>       updates to them) apply, as well as those of any 
>>>>protocol that uses
>>>>>       this type (e.g. TLS).
>>>>>
>>>>>       Note that this type only specifies a certificate chain that
>>>>>       can be assessed for validity according to the 
>>>>relying party's
>>>>>       existing configuration of trusted CAs; it is not 
>>>>intended to be
>>>>>       used to specify any change to that configuration.
>>>>>
>>>>>    Interoperability considerations:
>>>>>       No specific interoperability problems are known 
>>>>with this type,
>>>>>       but for recommendations relating to X.509 
>>>>certificates in general,
>>>>>       see [PKIX].
>>>>>
>>>>>    Published specification: <draft-ietf-tls-extensions-04.txt> and
>>>>>       [PKIX].
>>>>>
>>>>>    Applications which use this media type: TLS. It may 
>>>>also be used by
>>>>>       other protocols, or for general interchange of PKIX 
>>>>certificate
>>>>>       chains.
>>>>>
>>>>>    Additional information:
>>>>>       Magic number(s): DER-encoded ASN.1 can be easily recognised.
>>>>>          Further parsing is required to distinguish from 
>>>>other ASN.1
>>>>>          types.
>>>>>       File extension(s): .pkipath
>>>>>       Macintosh File Type Code(s): not specified
>>>>>
>>>>>    Person & email address to contact for further information:
>>>>>       Magnus Nystrom <[email-masked]>
>>>>>
>>>>>    Intended usage: COMMON
>>>>>
>>>>>    Author/Change controller:
>>>>>       Magnus Nystrom <[email-masked]>
>>>>>
>>>>>
>>>>>Normative References
>>>>>
>>>>>    [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate
>>>>>    Requirement Levels," IETF RFC 2119, March 1997.
>>>>>
>>>>>    [PKIX] R. Housley, W. Ford, W. Polk, and D. Solo, 
>>>>"Internet Public
>>>>>    Key Infrastructure: Part I: X.509 Certificate and CRL 
>>>>Profile", IETF
>>>>>    RFC 2459, January 1999.
>>>>>
>>>>>    [X509-4th] ITU-T Recommendation X.509 (2000) | ISO/IEC 
>>>>9594-8:2001,
>>>>>    "Information Systems - Open Systems Interconnection - 
>>>>The Directory:
>>>>>    Public key and attribute certificate frameworks."
>>>>>
>>>>>    [X509-4th-TC1] ITU-T Recommendation X.509(2000) 
>>>>Corrigendum 1(2001) |
>>>>>    ISO/IEC 9594-8:2001/Cor.1:2002, Technical Corrigendum 
>>>>1 to ISO/IEC
>>>>>    9594:8:2001.
>>>>>
>>>>>- --
>>>>>David Hopwood <[email-masked]>
>>>>>
>>>>>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
>>>>>
>>>>>
>>>>>-----BEGIN PGP SIGNATURE-----
>>>>>Version: 2.6.3i
>>>>>Charset: noconv
>>>>>
>>>>>iQEVAwUBPOrjTTkCAxeYt5gVAQHddQf5ATsJ4D4flPu6Y5JgtazAO/Fc0MxG9Iy6
>>>>>XJsov+JNMmEwP66eESuSkgk44RWlk+TkHadGnsybRth9aRUumhni8GjnIO4UAn4I
>>>>>QghOXua2BZ8QoePEcm2i1BqlcTg7jgOHIcVXiRk3l/N3IvZviDy1a/h9B4pmYafV
>>>>>ZUgKhzwr7qFg63LWQyuSkOzisWpNeC778A6u95G+P0HhGdL77IEqiVz0GfWPuq2A
>>>>>jTmGP7kOl+WhS1pbjliGqxUNjYyw4fX/rcd5ltzhijY5LRa3jsUq+ixK8uSx4kle
>>>>>XXI1Aig8NLaX5Vfu2AkojMrcH2/wMFQK/JHwZY2cfs2mhdi7JBPUng==
>>>>>=6X2a
>>>>>-----END PGP SIGNATURE-----
>>>>

---

From: David Hopwood <[email-masked]>
Date: Fri, 24 May 2002 03:31:19 +0000

-----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.

> public keys for the asymmetric cipher suites, as per

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.

- -- 

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