[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 RFC 4212

Network Working Group                                         M. Blinov
Internet Draft                                     Guardeonic Solutions
Expires: 15 March 2004                                         C. Adams
                                                   University of Ottawa
                                                      15 September 2003




              Alternative Certificate Formats for PKIX-CMP
                    <draft-adams-cmpaltcert-01.txt>


Status of This Memo

   Distribution of this memo is unlimited.

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Abstract

   The PKIX Certificate Management Protocols (PKIX-CMP) specification,
   while primarily focused on X.509v3 public-key certificates, allows
   the messages it defines to be used for the management of  alternative
   certificate formats as well.  This document specifies precisely how
   such formats may be incorporated into PKIX-CMP and provides the
   relevant syntax for some important certificate types.









Blinov, et al.            Expires 15 March 2004                 [Page 1]

Internet Draft      Alternative Cert Formats for CMP   15 September 2003


1.  Introduction

   Full certificate life-cycle management in a Public-Key Infrastructure
   (PKI) requires protocol support in order to achieve automated
   processing and end user transparency.  Such protocols require
   standardization in order to allow more than one vendor to supply
   various pieces -- End Entity (EE), Certification Authority (CA),
   Registration Authority (RA) -- in the PKI deployment of a single
   organization, or to allow multiple, independently-deployed PKIs to be
   interconnected usefully.

   The IETF PKIX Working Group currently has certificate management
   protocol specifications on the standards track.  The specification
   PKIX-CMP [CMP], looking beyond PKIX-specific environments to the
   more-general certificate management requirements of other domains,
   defines a syntactic structure for the "Certificate" data element that
   allows certificate formats other than X.509 to be included easily
   into the management messages.  In particular, other types of
   certificates may be requested from a CA, retrieved from a public
   repository, recovered from a backup facility, updated/replaced when
   nearing the end of their validity period, and revoked when required.
   This specification takes the flexible syntax defined in PKIX-CMP and
   fills in the details regarding how to incorporate alternative
   certificate formats when this is desired.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

2.  Including Alternative Certificate Formats

   In PKIX-CMP, the ASN.1 construct, and corresponding comment, for a
   certificate is given as follows.

      CMPCertificate ::= CHOICE {
         x509v3PKCert        Certificate
      }

      -- This syntax, while bits-on-the-wire compatible with the standard
      -- X.509 definition of "Certificate", allows the possibility of future
      -- certificate types (such as X.509 attribute certificates, WAP WTLS
      -- certificates, or other kinds of certificates) within this
      -- certificate management protocol, should a need ever arise to support
      -- such generality.


   Building on this framework, then, this document expands the above
   CHOICE construct as follows.



Blinov, et al.            Expires 15 March 2004                 [Page 2]

Internet Draft      Alternative Cert Formats for CMP   15 September 2003


      CMPCertificate ::= CHOICE {
         x509v3PKCert        Certificate
         x509v2AttCert   [0] AttributeCertificate,
                             -- defined in [ATTCERT]
         wtlsCert        [1] WTLSCert,
         openPGPCert     [2] OpenPGPCert
      }

      WTLSCert ::= OCTET STRING
         -- contains the structure WTLSCertificate from the WAP WTLS
         -- specification [WTLS], encoded as an ASN.1 OCTET STRING

      OpenPGPCert ::= OCTET STRING
         -- contains the OpenPGP certificate (OpenPGP Transferable
         -- Public Key) data structure from the OpenPGP specification
         -- [OPENPGP] (binary format without Radix-64 conversions),
         -- encoded as an ASN.1 OCTET STRING

   Expanding the CHOICE construct as above allows X.509 attribute
   certificates, WAP (Wireless Application Protocol) WTLS (Wireless
   Transport Layer Security) certificates, and OpenPGP certificates to
   be used within the PKIX-CMP management messages.  In the future, this
   construct may be expanded further (in subsequent revisions of this
   document) to accomodate other certificate types if this is found to
   be necessary.

3.  Initialization Request

   One of the features of PKIX-CMP is its use of the CertTemplate
   construct, which allows a requester (EE, or RA acting on behalf of an
   EE) to specify as much or as little as they wish regarding the
   content of the requested certificate.  It is explicitly noted that
   the CA has final authority over the actual certificate content; that
   is, the CA may alter certificate fields or may add, delete, or alter
   extensions according to its operating policy (if the resulting
   certificate is unacceptable to the EE or RA, then that certificate
   may be rejected and/or revoked prior to any publication/use).

   For the new certificate types included in this document, a similar
   flexibility in the request message must be available.  PKIX-CMP
   accomodates this in the following way
   (where id-regCtrl = {1 3 6 1 5 5 7 5 1} as defined in [CRMF]).

      CertRequest ::= SEQUENCE {
          certReqId     INTEGER,
          certTemplate  CertTemplate,
          controls      Controls OPTIONAL }
      -- If certTemplate is an empty SEQUENCE (i.e., all fields



Blinov, et al.            Expires 15 March 2004                 [Page 3]

Internet Draft      Alternative Cert Formats for CMP   15 September 2003


      -- omitted), then controls MAY contain the
      -- id-regCtrl-altCertTemplate control, specifying a template
      -- for a certificate other than an X.509v3 public-key
      -- certificate.  Conversely, if certTemplate is not empty
      -- (i.e., at least one field is present), then controls
      -- MUST NOT contain id-regCtrl-altCertTemplate.  The new
      -- control is defined as follows:
      id-regCtrl-altCertTemplate OBJECT IDENTIFIER ::= {id-regCtrl 7}
      AltCertTemplate ::= AttributeTypeAndValue

   In this section, an AltCertTemplate is specified for each of the
   alternative certificates defined in Section 2.

3.1.  X.509 Attribute Certificate CertTemplate

   A CertTemplate for an X.509 attribute certificate can be used by
   simply defining an object identifier (OID) and corresponding value
   for use in the id-regCtrl-altCertTemplate control.  These are
   specified as follows.

   OID:

      id-acTemplate OBJECT IDENTIFIER ::=
         {id-regCtrl-altCertTemplate xx}

   Value:

      AttCertTemplate ::= SEQUENCE {
         version                 AttCertVersion            OPTIONAL,
         holder                  Holder                    OPTIONAL,
         issuer                  AttCertIssuer             OPTIONAL,
         signature               AlgorithmIdentifier       OPTIONAL,
         serialNumber            CertificateSerialNumber   OPTIONAL,
         attrCertValidityPeriod  OptionalAttCertValidity   OPTIONAL,
         attributes              SEQUENCE OF Attribute     OPTIONAL,
         issuerUniqueID          UniqueIdentifier          OPTIONAL,
         extensions              Extensions                OPTIONAL
      }
      OptionalAttCertValidity  ::= SEQUENCE {
         notBeforeTime  GeneralizedTime  OPTIONAL,
         notAfterTime   GeneralizedTime  OPTIONAL
      } -- at least one must be present


3.2.  WTLS Certificate CertTemplate

   A CertTemplate for a Wireless Transport Layer Security certificate
   can be used by simply defining an object identifier (OID) and



Blinov, et al.            Expires 15 March 2004                 [Page 4]

Internet Draft      Alternative Cert Formats for CMP   15 September 2003


   corresponding value for use in the id-regCtrl-altCertTemplate
   control.  These are specified as follows.

   OID:

      id-wtlsTemplate OBJECT IDENTIFIER ::=
         {id-regCtrl-altCertTemplate yy}

   Value:

      WTLSCertTemplate ::= OCTET STRING
      -- actual content to be defined in the WAP Security Group and
      -- then encoded as an ASN.1 OCTET STRING


3.3.  OpenPGP Certificate CertTemplate

   Similar to certificate templates defined above, a CertTemplate for an
   OpenPGP certificate can be used by defining an object identifier
   (OID) and corresponding value for use in the
   id-regCtrl-altCertTemplate control.  These are specified as follows:

   OID:

      id-openPGPCertTemplateExt OBJECT IDENTIFIER ::=
         {id-regCtrl-altCertTemplate zz}

   Value:

      OpenPGPCertTemplateExtended ::= SEQUENCE {
         nativeTemplate   OpenPGPCertTemplate,
         controls         Controls  OPTIONAL }

      OpenPGPCertTemplate ::= OCTET STRING
      -- contains the OpenPGP CertTemplate data structure defined
      -- below (binary format without Radix-64 conversions)
      -- encoded as an ASN.1 OCTET STRING


3.3.1.  OpenPGP CertTemplate Data Structure

   Similar to the X.509 CertTemplate, the OpenPGP CertTemplate is an
   OpenPGP certificate (OpenPGP Transferable Public Key) [OPENPGP] with
   all fields optional.  The essential elements of an OpenPGP
   CertTemplate are:

    - Zero or one Public Key packet.




Blinov, et al.            Expires 15 March 2004                 [Page 5]

Internet Draft      Alternative Cert Formats for CMP   15 September 2003


    - Zero or more Direct Key Self Signature packets.

    - Zero or more Certification Signature packets [only if no User ID
      packets are present].

    - Zero or more User ID packets.

    - After each User ID packet, zero or more Certification Signature
      packets.

    - Zero or more Subkey packets.

    - After each Subkey packet, zero or one Subkey Binding Signature
      packet.

   Each packet in the OpenPGP CertTemplate MUST be a syntactically
   correct OpenPGP packet.  This will enable conformant implementations
   to use existing PGP libraries for building and parsing OpenPGP
   CertTemplates.

   The following implications of this rule should be explicitly noted:

    - Fields for which the OpenPGP specification defines a set of
      permitted values (e.g. the signature type or the public key
      algorithm fields of the Signature packet) MUST have a value from
      the defined set.  Even if the requester does not have any
      particular preferences for, for example, the signature algorithm,
      it MUST choose one value that is the most desirable.

      Rationale: An alternative solution could be to define extra "any"
      values, but this would be a modification of the OpenPGP syntax
      which is not considered to be appropriate in this document.

    - All subpackets of the Signature packet defined by the OpenPGP
      specification as mandatory (e.g. the creation time and the
      issuer's key id subpackets) MUST be present even though they do
      not make much sense in the context of a certificate request.

    - The number of MPIs at the end of the Key Material and the
      Signature packets MUST match the number defined by the OpenPGP
      specification for the given algorithm (the algorithm is controlled
      by the value of the "algorithm" field).  For example, there should
      be 2 MPIs for DSA signatures.  Note that the OpenPGP specification
      does not define validation rules for the content of those MPIs.

   Though it is not considered appropriate here to define extra "any"
   values for fields of enumerated types, such values can still be
   defined for some other fields where the OpenPGP specification is not



Blinov, et al.            Expires 15 March 2004                 [Page 6]

Internet Draft      Alternative Cert Formats for CMP   15 September 2003


   that strict.

   The following extra values are defined in the context of the OpenPGP
   CertTemplate.  Note that these definitions do not modify the syntax
   of OpenPGP packets and existing PGP libraries can still be used to
   generate and parse them.

    - For fields representing time (e.g. signature creation time): the
      value of zero means "any time".

    - For fields holding key IDs: the value of 0xFFFFFFFFFFFFFFFF means
      "any key id".

    - For signature fields: the "any signature" value is encoded as a
      sequence of MPIs such that:

       * the number of MPIs matches the number of MPIs defined by the
         OpenPGP specification for the given algorithm, and

       * the value of each MPI is 0xFF.

      A Signature packet with the "any" value in the signature fields is
      called a Signature Template.

         Example: The "any signature" value for a DSA signature would
         look like [00 08 FF 00 08 FF]

    - For key material fields: the "any key" value is encoded as a
      sequence of MPIs such that:

       * the number of MPIs matches the number of MPIs defined by the
         OpenPGP specification for the given algorithm, and

       * the value of at least one of the MPIs is a bit string with all
         its bits set to 1.

      A Key Material packet with the "any" value in the key material
      fields is called a Key Template.  (See Key Template section for
      further details.)

         Example: The "any key" value for a DSA public key may look like
         [00 08 FF 00 10 FF FF 00 10 85 34 00 08 FF]

   The following rules apply to the sequence of packets within the
   OpenPGP CertTemplate:

    - If the Public Key packet is omitted from the OpenPGP CertTemplate
      then this CertTemplate does not constrain the value of the public



Blinov, et al.            Expires 15 March 2004                 [Page 7]

Internet Draft      Alternative Cert Formats for CMP   15 September 2003


      key, i.e. it refers to "any" public key.

    - The order of Signature packets following a User ID packet and the
      order of User ID packets within the CertTemplate are not
      important.

    - If an OpenPGP CertTemplate does not contain any User ID packets
      then it refers to "any" user ids that are relevant to a given
      request.

3.3.2.  OpenPGP CertTemplate in Certificate Requests

   Since an OpenPGP certificate can have several certification
   signatures, the OpenPGP CertTemplate uses Signature Templates to
   define where certification signatures should occur.  The values of
   the fields of the Signature Templates define the parameters of the
   new certification signatures.  The following rules apply:

    - A Signature Template that is present in the list of signatures
      following a User ID packet requests the CA to certify this User ID
      and the public key and replace the Signature Template with the new
      certification signature.  The Signature Template does not mandate
      the exact place of the certification signature within the list.
      The certification signature may be inserted at any position within
      the list of signatures (following the certified User ID packet).

    - A Signature Template may be present in the OpenPGP CertTemplate
      without any preceding User ID packet.  In this case it is assumed
      that the CA knows the ID(s) of the user by some other means.  A
      Signature Template without a preceding User ID requests the CA to
      insert all known User IDs of the user to the OpenPGP certificate
      and certify each of them.  The Signature Template defines the
      parameters of these certification signatures.

    - If an OpenPGP CertTemplate contains no Signature Templates then
      the CA is requested to certify all User IDs that are present in
      the OpenPGP CertTemplate.  Such a CertTemplate does not define
      parameters of the certification signatures explicitly, but the CA
      SHOULD use parameters of the certification self-signatures (if
      present in the CertTemplate) as a guidance (e.g. key flags
      fields).

    - If neither Signature Templates nor User IDs are present in the
      OpenPGP CertTemplate then the CA is expected to know the ID(s) of
      the user by some other means.  In this case the CertTemplate
      requests the CA to insert these User IDs into the OpenPGP
      certificate and certify each of them.  The parameters of the
      certification signatures are left to the CA.



Blinov, et al.            Expires 15 March 2004                 [Page 8]

Internet Draft      Alternative Cert Formats for CMP   15 September 2003


   If several certification signatures have to be produced according to
   an OpenPGP CertTemplate and any of them can not be granted (even with
   modifications) for whatever reason then the whole request with this
   OpenPGP CertTemplate MUST be rejected.

   The client SHOULD provide enough information in its request so that
   the CA could produce a complete OpenPGP certificate.  For example,
   the client SHOULD include in the template all relevant subkeys with
   their binding signatures so that the CA can include them in the
   resultant OpenPGP certificate as well.  Rationale: In some
   environments the CA/RA is responsible for publishing certificates.

3.3.3.  Key Templates and Central Key Generation

   The OpenPGP CertTemplate can also be used to request certification of
   centrally-generated keys.  This is accomplished by using Key
   Templates.

   If the Public Key packet of an OpenPGP CertTemplate is a Key Template
   then this OpenPGP CertTemplate requests the CA/RA to generate the key
   pair prior to certifying it.  Fields of the Key Template define
   parameters of the new key pair as follows (see examples in the
   Appendix):

    - The "public key algorithm" field specifies the algorithm to be
      used for the key generation.

    - MPI fields with the value of 0xFF ([00 08 FF]) specify that no
      constraint is placed on the corresponding part of the key.

    - MPI fields that contain any other bit strings with all bits set to
      1 specify that the corresponding part of the key should be of the
      same length as the length of the MPI (e.g. the length of the
      public modulus n of the RSA key).

    - MPI fields that contain any other values specify that the
      corresponding part of the key should be of the given value (key
      generation parameters).

   In order to return a complete OpenPGP certificate, in addition to
   certifying the new key and the User ID, the CA (or RA) SHOULD also
   create a self-signature (i.e. sign the new public key and the User ID
   with the new private key) and include it after the User ID packet.
   This SHOULD be done for all User IDs certified by the CA.

   If a Subkey packet of an OpenPGP CertTemplate is a Key Template then
   this OpenPGP CertTemplate requests the CA/RA to generate a subkey.
   Fields of the Key Template define parameters of the new subkey.  The



Blinov, et al.            Expires 15 March 2004                 [Page 9]

Internet Draft      Alternative Cert Formats for CMP   15 September 2003


   new subkey obviously does not have to be certified.  However, the
   CA/RA SHOULD produce the binding signature and include it after the
   subkey, if the CA/RA knows the user's primary private key (e.g. it
   was centrally generated as well).  Note that if the CA/RA does not
   know the user's primary private key then the resultant OpenPGP
   certificate returned from the CA/RA to the client will be incomplete
   (i.e. there will be no binding signature for the subkey).  It will be
   the responsibility of the client to produce and add the binding
   signature and to publish the final OpenPGP certificate.

   If an OpenPGP CertTemplate contains neither PublicKey/Subkey packets
   nor Key Template packets then it requests the CA to generate
   keys/subkeys according to the CA's policies.

3.3.4.  OpenPGPCertTemplateExtended

   The OpenPGPCertTemplateExtended structure enables additional
   extensions and controls to be added to the basic OpenPGP
   CertTemplate.

3.3.5.  OpenPGP CertTemplate Required Profile

   A conformant implementation is REQUIRED to support OpenPGP
   CertTemplates that are valid OpenPGP certificates, i.e. that have the
   following structure (see examples in the Appendix):

    - One Public Key packet (not a Key Template).

    - Zero or more Direct Key Self Signature packets (without Signature
      Templates).

    - One or more User ID packets.

    - After each User ID packet, zero or more Certification Signature
      packets (without Signature Templates).

    - Zero or more Subkey packets (without Key Templates).

    - After each Subkey packet, one Subkey Binding Signature packet (not
      a Signature Template).

   A conformant implementation is REQUIRED to recognise Key Templates
   and Signature Templates and is REQUIRED to either support them or
   reject requests containing them if it does not.







Blinov, et al.            Expires 15 March 2004                [Page 10]

Internet Draft      Alternative Cert Formats for CMP   15 September 2003


3.3.6.  CMP-related Issues

3.3.6.1.  POP

   The CMP specification has the following note:

      * NOTE: If CertReqMsg certReq certTemplate
      * (or the altCertTemplate control) contains the subject and publicKey
      * values, then poposkInput MUST be omitted and the signature MUST be
      * computed on the DER-encoded value of CertReqMsg certReq (or the DER-
      * encoded value of AltCertTemplate).

   It is considered that an OpenPGP CertTemplate satisfies the
   conditions of this note if it has a Public Key packet (not a Key
   Template) and at least one User ID packet.

4.  Security Considerations

   This entire memo is about security.  It describes a mechanism that
   may be used to incorporate multiple certificate formats into the
   PKIX-CMP certificate management protocol.


Appendix A.  Examples of OpenPGP CertTemplates

   This Appendix presents examples of OpenPGP CertTemplates that are
   used for requesting OpenPGP certificates from a CA.

A1.  Simple Certificate Request

   Alice requests an OpenPGP certificate for her public key accompanied
   by a subkey.

   The content of the OpenPGP CertTemplate in the request is as follows.
   This CertTemplate conforms to the OpenPGP CertTemplate Required
   Profile.

      0000:  99 01 A2         === Pub Key packet ===
      0003:  04 3C 58 27 A2 11      ver 4, created 30 Jan 2002, DSA
      0009:  00 E3 FB 9D .. 2B EF   DSA prime p
      008B:  00 A0 FF 7E .. BA 71   DSA group order q
      00A1:  03 FF 68 BC .. 56 71   DSA group generator g
      0123:  03 FE 38 1F .. F2 63   DSA public key value y
      01A5:  B4 16            === User ID packet ===
      01A7:  41 6C .. 6D 3E         "Alice <alice@some.com>"
      01BD:  89 00 49         === Signature packet (self-signature) ===
      01C0:  04 10 11 02            ver 4, gen cert, DSA, SHA1
      01C4:  00 09 05 02 3C 58 27 A2 02 1B 03



Blinov, et al.            Expires 15 March 2004                [Page 11]

Internet Draft      Alternative Cert Formats for CMP   15 September 2003


                                    created 30 Jan 2002, key usage:
                                    sign data and certify other keys
      01CF:  00 0A 09 10 43 5C .. 06 77   issuer key id
      01DB:  5A C2                  left 16 bits of signed hash value
      01DD:  00 A0 EB 00 .. 1B 75   DSA value r
      01F3:  00 A0 F4 E4 .. A8 3D   DSA value s
      0209:  B9 02 0D         === Public Subkey packet ===
      020C:  04 3C 58 27 A2 10      ver 4, created 30 Jan 2002,
                                    Elgamal (encrypt-only) algorithm
      0212:  08 00 F6 42 .. 0B 3B   Elgamal prime p
      0314:  00 02 02               Elgamal group generator g
      0317:  07 FE 37 BA .. DF 21   Elgamal public key value y
      0419:  89 00 49         === Signature packet (subkey binding) ===
      041C:  04 18 11 02            ver 4, subkey binding, DSA, SHA1
      0420:  00 09 05 02 3C 58 27 A2 02 1B 0C
                                    created 30 Jan 2002, key usage:
                                    encrypt communications and storage
      042B:  00 0A 09 10 43 5C .. 06 77   issuer key id
      0437:  C7 DE                  left 16 bits of signed hash value
      0439:  00 9E 21 33 .. 39 1B   DSA value r
      044F:  00 9F 64 D7 .. 63 08   DSA value s
      0465:

   CA certifies Alice's User ID and the public key and creates the
   following OpenPGP certificate:

      0000:  99 01 A2             === Pub Key packet ===
      0003:    <the same as in the request>
      01A5:  B4 16            === User ID packet ===
      01A7:    <the same as in the request>
      01BD:  89 00 49         === Signature packet (self-signature) ===
      01C0:    <the same as in the request>
      0209:  89 00 49         === Signature packet (certification) ===
      020C:  04 13 11 02            ver 4, positive cert, DSA, SHA1
      0210:  00 09 05 02 3C 58 28 1A 02 1B 03
                                    created 30 Jan 2002, key usage:
                                    sign data and certify other keys
      021B:  00 0A 09 10 F0 0D .. 1F CA   issuer key id
      0227:  06 DF                  left 16 bits of signed hash value
      0229:  00 9F 57 2D .. 26 E3   DSA value r
      023F:  00 A0 B3 02 .. CE 65   DSA value s
      0255:  B9 02 0D         === Public Subkey packet ===
      0258:    <the same as in the request>
      0465:  89 00 49         === Signature packet (subkey binding) ===
      0468:    <the same as in the request>
      04B1:





Blinov, et al.            Expires 15 March 2004                [Page 12]

Internet Draft      Alternative Cert Formats for CMP   15 September 2003


A2.  Certificate Request with Central Key Generation

   Alice requests the CA to generate an RSA key pair that will be used
   for signing and another RSA key pair that will be used for encryption
   and to certify these keys.  The RSA keys are requested to be 2048
   bits long with the public exponent 65537.

   The content of the OpenPGP CertTemplate in the request is as follows:

      0000:  99 01 0D         === Pub Key packet (Template) ===
      0003:  04 FF FF FF FF 01      ver 4, any creation date, RSA
      0009:  08 00 FF FF .. FF FF   RSA public modulus n - given length
      010B:  00 11 01 00 01         RSA public exponent e
      0110:  B4 16            === User ID packet ===
      0112:  41 6C .. 6D 3E         "Alice <alice@some.com>"
      0128:  89 00 23         === Signature packet (Template) ===
      012B:  04 10 11 02            ver 4, gen cert, DSA, SHA1
      012F:  00 09 05 02 FF FF FF FF 02 1B 03
                                    any creation date, key usage:
                                    sign data and certify other keys
      013A:  00 0A 09 10 FF FF .. FF FF   issuer key id - any
      0146:  05 3A                  left 16 bits of signed hash value
      0148:  00 08 FF               DSA value r - any
      014B:  00 08 FF               DSA value s - any
      014E:  99 01 0D         === Public Subkey packet (Template) ===
      0151:  04 FF FF FF FF 01      ver 4, any creation date, RSA
      0157:  08 00 FF FF .. FF FF   RSA public modulus n - given length
      0259:  00 11 01 00 01         RSA public exponent e
      025E:  89 00 20         === Signature packet (Template) ===
      0261:  04 18 01 02            ver 4, subkey binding, RSA, SHA1
      0265:  00 09 05 02 FF FF FF FF 02 1B 0C
                                    any creation date, key usage:
                                    encrypt communications and storage
      0270:  00 0A 09 10 FF FF .. FF FF   issuer key id - any
      027C:  12 E6                  left 16 bits of signed hash value
      027E:  00 08 FF               RSA signature value - any
      0281:

   CA generates keys, certifies Alice's User ID and the public key and
   creates the following OpenPGP certificate:

      0000:  99 01 0D         === Pub Key packet  ===
      0003:  04 3C 5A A5 BB 01      ver 4, created 01 Feb 2002, RSA
      0009:  08 00 C7 21 .. 5B EB   RSA public modulus n
      010B:  00 11 01 00 01         RSA public exponent e
      0110:  B4 16            === User ID packet ===
      0112:  41 6C .. 6D 3E         "Alice <alice@some.com>"
      0128:  89 01 1F         === Signature packet (self-signature) ===



Blinov, et al.            Expires 15 March 2004                [Page 13]

Internet Draft      Alternative Cert Formats for CMP   15 September 2003


      012B:  04 10 01 02            ver 4, gen cert, RSA, SHA1
      012F:  00 09 05 02 3C 5A A5 BB 02 1B 03
                                    created 01 Feb 2002, key usage:
                                    sign data and certify other keys
      013A:  00 0A 09 10 8E AF .. 1A 18   issuer key id
      0146:  3B 21                  left 16 bits of signed hash value
      0148:  07 FE 2F 1D .. C0 81   RSA signature value
      024A:  89 00 49         === Signature packet (certification) ===
      024D:  04 13 11 02            ver 4, positive cert, DSA, SHA1
      0251:  00 09 05 02 3C 5A A5 DC 02 1B 03
                                    created 01 Feb 2002, key usage:
                                    sign data and certify other keys
      025C:  00 0A 09 10 F0 0D .. 1F CA   issuer key id
      0268:  BA C2                  left 16 bits of signed hash value
      026A:  00 9F 5E 58 .. 30 B3   DSA value r
      0280:  00 A0 D1 D7 .. 5A AF   DSA value s
      0296:  99 01 0D         === Public Subkey packet ===
      0299:  04 3C 5A A5 C5 01      ver 4, created 01 Feb 2002, RSA
      029F:  08 00 C3 03 .. 8C 53   RSA public modulus n
      03A1:  00 11 01 00 01         RSA public exponent e
      03A6:  89 01 1F         === Signature packet (subkey binding) ===
      03A9:  04 18 01 02            ver 4, subkey binding, RSA, SHA1
      03AD:  00 09 05 02 3C 5A A5 C5 05 1B 0C
                                    created 01 Feb 2002, key usage:
                                    encrypt communications and storage
      03B8:  00 0A 09 10 8E AF .. 1A 18   issuer key id
      03C4:  C8 44                  left 16 bits of signed hash value
      03C6:  07 FB 04 D7 .. 75 BE   RSA signature value
      04C8:


Normative references

   [ATTCERT]   Farrell, S. and R. Housley, "An Internet Attribute
               Certificate: Profile for Authorization", RFC 3281, April
               2002.

   [CMP]       Adams, C. and S. Farrell, "Internet X.509 Public Key
               Infrastructure: Certificate Management Protocols",
               Internet Draft draft-ietf-pkix-rfc2510bis-08.txt, Work in
               progress.

   [CRMF]      Myers, M., Adams, C., Solo, D. and D. Kemp, "Internet
               X.509 Certificate Request Message Format", RFC 2511,
               March 1999.

   [OPENPGP]   Callas, J., Donnerhacke, L., Finney, H. and R. Thayer,
               "OpenPGP Message Format", RFC 2440, November 1998.



Blinov, et al.            Expires 15 March 2004                [Page 14]

Internet Draft      Alternative Cert Formats for CMP   15 September 2003


   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", RFC 2119, March 1997.

   [WTLS]      WAP Forum, "Wireless Transport Layer Security",
               Specification WAP-261-WTLS-20010406-a, April 2001.

Author's Address

   Questions about this memo can be directed to:

   Mikhail Blinov
   Guardeonic Solutions
   Fitzwilliam Court, Leeson Close
   Dublin 2, Ireland
   e-mail:  mikhail.blinov@guardeonic.com


   Carlisle Adams
   School of Information Technology and Engineering (SITE)
   University of Ottawa
   800 King Edward Avenue
   P.O. Box 450, Stn A
   Ottawa, Ontario, Canada K1N 6N5
   e-mail:  cadams@site.uottawa.ca


Full Copyright Statement

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an



Blinov, et al.            Expires 15 March 2004                [Page 15]

Internet Draft      Alternative Cert Formats for CMP   15 September 2003


   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."














































Blinov, et al.            Expires 15 March 2004                [Page 16]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/