Subject: application/pkix-pkipath

From: David Hopwood <[email-masked]>
Date: Thu, 23 May 2002 16:08:14 +0000

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

---

From: "Housley, Russ" <[email-masked]>
Date: Thu, 23 May 2002 13:46:53 -0400

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