Subject: Proposed MIME type application/pkix-pkipath

From: David Hopwood <[email-masked]>
Date: Sat, 13 Apr 2002 04:16:42 +0000

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

(Please keep replies posted to both <[email-masked]> and
<[email-masked]>.)

The Transport Layer Security WG has developed a draft for a set of
extensions to TLS. One of the extensions, "client_certificate_url",
is designed to allow TLS clients to specify client certificate chains
that should be retrieved from an URL, instead of the chain being sent
in the TLS protocol (so that memory-constrained clients do not have
to store the whole chain). Therefore a MIME type needs to be registered
for transferring the cert chain by HTTP, etc.

The ASN.1 type proposed to be used is PkiPath, as defined in X.509 (2000)
Technical Corrigendum 1, which is equivalent to "SEQUENCE OF Certificate".
(Other possible ASN.1 types such as CertificationPath and
ForwardCertificationPath were considered to be unnecessarily
complicated for this application, and CertificateSet from PKCS#7 is
not used because it defines a SET rather than a SEQUENCE, making
validation more difficult.)

A copy of X.509 (2000) TC 1 is at:
<ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/TechnicalCorrigenda/ApprovedTechnicalCorrigendaToX.509/8|X.509-TC1(4th).pdf>.

The current version of the TLS extensions draft is
<http://www.rfc-editor.org/internet-drafts/draft-ietf-tls-extensions-03.txt>.
It will be modified to include an IANA Considerations section with the
MIME template given below, and to specify use of "application/pkix-pkipath"
instead of "application/pkcs7-mime". <draft-ietf-tls-extensions-04.txt>
will then be taken to Last Call, since all issues other than this one have
already been resolved.

Here is the draft registration template, following RFC 2048. It is
intended to be consistent with application/pkix-{cert,crl} as defined
in RFC 2585.

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 is the DER-encoded ASN.1 type PkiPath, which is defined in
   [X509-TC1] 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.

   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-2000] and [PKIX] (or any
   update to it) 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>,
   [X509-TC1], 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]>

References:
   [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-2000] ITU-T RECOMMENDATION X.509 (2000) | ISO/IEC 9594-8:2001.

   [X509-TC1]  Technical Corrigendum 1 (DTC 2) to
               ITU-T RECOMMENDATION X.509 (2000) | 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

---

From: Steve Hanna <[email-masked]>
Date: Mon, 22 Apr 2002 17:07:11 -0400

The off-line discussion about how to reference X.509 (2000) and
X.509 (2000) TC 1 has been completed. The recommendation is to
go with David Hopwood's earlier text, but change the references
to the ISO/ITU documents to this:

  [X509-4th] ITU-T Recommendation X.509(2000) | ISO/IEC 9594-8:2001, 
             Information Technology - 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.

I have included a full copy of the revised version of David's text
at the end of this message. The only changes here are to include
the full titles of the documents and change the reference markers
from [X509-2000] to [X509-4th] and from [X509-TC1] to
[X509-4th-TC1]. Basically, David had everything right in his
original text. These are just minor changes to the form of the
references.

Why make these changes? First, it's best to include the full titles
of these documents so that people can be sure they have the right
document if they want to download it from ITU or ISO. Second, it's
better to refer to the 4th edition of X.509 than to call it X.509
(2000), since the ISO version appeared in 2001 and this can cause
confusion. The content of the ITU and ISO versions is exactly the
same. Third, it's important to be clear that we mean X.509 (2000)
TC 1, not X.509 (1997) TC 1.

I apologize for any confusion. I guess that ISO and ITU sometimes
have the same sort of last-minute corrections to specs and resulting
confusion that the IETF sometimes has.

Thanks for your patience,

Steve Hanna

----------------

To: [email-masked]

Encoding considerations:
   This is the DER-encoded ASN.1 type PkiPath, which is defined in
   [X509-4th-TC1] as follows:

Security considerations:
   The security considerations of [X509-4th] and [PKIX] (or any
   update to it) apply, as well as those of any protocol that uses
   this type (e.g. TLS).

Published specification: <draft-ietf-tls-extensions-04.txt>,
   [X509-4th-TC1], and [PKIX].

Additional information:

Intended usage: COMMON

References:

  [X509-4th]     ITU-T Recommendation X.509(2000) | ISO/IEC 9594-8:2001, 
                 Information Technology - 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.