GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4212

Network Working Group M. Blinov Request for Comments: 4212 Guardeonic Solutions Category: Informational C. Adams

                                                  University of Ottawa
                                                          October 2005
              Alternative Certificate Formats for the
           Public-Key Infrastructure Using X.509 (PKIX)
                  Certificate Management Protocols

Status of This Memo

 This memo provides information for the Internet community.  It does
 not specify an Internet standard of any kind.  Distribution of this
 memo is unlimited.

Copyright Notice

 Copyright (C) The Internet Society (2005).

IESG Note

 This document is not a candidate for any level of Internet Standard.
 The IETF disclaims any knowledge of the fitness of this document for
 any purpose, and in particular notes that it has not had IETF review
 for such things as security, congestion control, or inappropriate
 interaction with deployed protocols.  The RFC Editor has chosen to
 publish this document at its discretion.  Readers of this document
 should exercise caution in evaluating its value for implementation
 and deployment.

Abstract

 The Public-Key Infrastructure using X.509 (PKIX) Working Group of the
 Internet Engineering Task Force (IETF) has defined a number of
 certificate management protocols.  These protocols are primarily
 focused on X.509v3 public-key certificates.  However, it is sometimes
 desirable to manage certificates in alternative formats as well.
 This document specifies how such certificates may be requested using
 the Certificate Request Message Format (CRMF) syntax that is used by
 several different protocols.  It also explains how alternative
 certificate formats may be incorporated into such popular protocols
 as PKIX Certificate Management Protocol (PKIX-CMP) and Certificate
 Management Messages over CMS (CMC).

Blinov & Adams Informational [Page 1] RFC 4212 Alternative Certificate Formats October 2005

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 (Public-Key Infrastructure using X.509) Working Group
 currently has several certificate management protocols and
 certificate request syntax specifications on the standards track.
 Although these specifications are primarily focused on X.509v3
 public-key certificates, some of them can be easily extended to
 handle certificates in alternative formats as well.
 This document focuses on a popular certificate request syntax called
 CRMF (Certificate Request Message Format) [CRMF].  Although the
 original specification of CRMF is X.509-specific, extensions have
 already been proposed to allow for alternative certificate templates
 [CMP].  However, those extensions have only defined a framework; they
 did not define the exact format to be used for various certificate
 types.
 This document builds on top of the framework mentioned above and
 defines how CRMF can be used to request certificates of the following
 types:
  1. X.509 attribute certificates [ATTCERT]
  1. OpenPGP certificates [OPENPGP]
 The CRMF syntax is used by such popular protocols as PKIX-CMP (PKIX
 Certificate Management Protocol) [CMP] and CMC (Certificate
 Management Messages over CMS) [CMC].  This means that CRMF extensions
 proposed in this document enable these protocols to request
 certificates of the above types.  However, it is not enough to be
 able to request a certificate.  The protocol should be prepared to
 handle certificates of a particular type and, for example, return
 them to the user.
 This document proposes extensions to the PKIX-CMP and CMC protocols
 that are required to manage certificates in alternative formats.

Blinov & Adams Informational [Page 2] RFC 4212 Alternative Certificate Formats October 2005

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

 One of the features of the CRMF format 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).
 A similar flexibility in the request must be available for
 alternative certificate types as well.  For this purpose, an
 AltCertTemplate extension was introduced in [CMP] as follows (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 }
  1. - If certTemplate is an empty SEQUENCE (i.e., all fields
  2. - omitted), then controls MAY contain the
  3. - id-regCtrl-altCertTemplate control, specifying a template
  4. - for a certificate other than an X.509v3 public-key
  5. - certificate. Conversely, if certTemplate is not empty
  6. - (i.e., at least one field is present), then controls
  7. - MUST NOT contain id-regCtrl-altCertTemplate. The new
  8. - 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 certificate types defined in Section 1.

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

Blinov & Adams Informational [Page 3] RFC 4212 Alternative Certificate Formats October 2005

 OID:
    id-acTemplate OBJECT IDENTIFIER ::=
       {id-regCtrl-altCertTemplate 1}
 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

2.2. 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 2}
 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

Blinov & Adams Informational [Page 4] RFC 4212 Alternative Certificate Formats October 2005

2.2.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:
  1. Zero or one Public Key packet.
  1. Zero or more Direct Key Self Signature packets.
  1. Zero or more Certification Signature packets (only if no User ID

packets are present).

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

packets.

  1. Zero or more Subkey packets.
  1. 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:
  1. 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 appropriate in this document.
  1. 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.

Blinov & Adams Informational [Page 5] RFC 4212 Alternative Certificate Formats October 2005

  1. 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
 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.
  1. For fields representing time (e.g., signature creation time): the

value of zero means "any time".

  1. For fields holding key IDs: the value of 0xFFFFFFFFFFFFFFFF means

"any key id".

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

Blinov & Adams Informational [Page 6] RFC 4212 Alternative Certificate Formats October 2005

   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:
  1. If the Public Key packet is omitted from the OpenPGP CertTemplate,

then this CertTemplate does not constrain the value of the public

   key (i.e., it refers to "any" public key).
  1. The order of Signature packets following a User ID packet and the

order of User ID packets within the CertTemplate are not important.

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

2.2.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:
  1. A Signature Template that is present in the list of signatures

following a User ID packet requests that the CA 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).
  1. 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 that the CA
   insert all known User IDs of the user into the OpenPGP certificate
   and certify each of them.  The Signature Template defines the
   parameters of these certification signatures.

Blinov & Adams Informational [Page 7] RFC 4212 Alternative Certificate Formats October 2005

  1. 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 guide (e.g., key flags fields).
  1. 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 that the CA insert these User IDs into the OpenPGP
   certificate and certify each of them.  The parameters of the
   certification signatures are left to the CA.
 If several certification signatures have to be produced according to
 an OpenPGP CertTemplate, and any of them cannot 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 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.

2.2.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 that the CA/RA
 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):
  1. The "public key algorithm" field specifies the algorithm to be used

for the key generation.

  1. MPI fields with the value of 0xFF ([00 08 FF]) specify that no

constraint is placed on the corresponding part of the key.

  1. MPI fields that contain any other bit strings in which all bits are

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

Blinov & Adams Informational [Page 8] RFC 4212 Alternative Certificate Formats October 2005

  1. 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 that the CA/RA generate a subkey.
 Fields of the Key Template define parameters of the new subkey.  The
 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 that the CA generate
 keys/subkeys according to the CA's policies.

2.2.4. OpenPGPCertTemplateExtended

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

2.2.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):
  1. One Public Key packet (not a Key Template).
  1. Zero or more Direct Key Self Signature packets (without Signature

Templates).

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

packets (without Signature Templates).

Blinov & Adams Informational [Page 9] RFC 4212 Alternative Certificate Formats October 2005

  1. Zero or more Subkey packets (without Key Templates).
  1. 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.

3. Proof-of-Possession

 A CRMF request includes a Proof-of-Possession (POP) field that
 contains proof that an End Entity has possession of the private key
 corresponding to the public key for which a certificate is requested.
 The following rule applies to this field (with modifications from
 [CMP]):
  • 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).
 An OpenPGP CertTemplate is considered to satisfy the conditions of
 this note if it has a Public Key packet (not a Key Template) and at
 least one User ID packet.

4. Protocol-specific Issues

 This section explains how alternative certificate formats may be
 incorporated into such popular protocols as PKIX-CMP and CMC.

4.1. PKIX-CMP

 In PKIX-CMP, the ASN.1 [ASN1] construct, and corresponding comment
 for a certificate is given as follows.
    CMPCertificate ::= CHOICE {
       x509v3PKCert        Certificate
    }
  1. - This syntax, while bits-on-the-wire compatible with the
  2. - standard X.509 definition of "Certificate", allows the
  3. - possibility of future certificate types (such as X.509
  4. - attribute certificates, WAP WTLS certificates, or
  5. - other kinds of certificates) within this certificate

Blinov & Adams Informational [Page 10] RFC 4212 Alternative Certificate Formats October 2005

  1. - management protocol, should a need ever arise to support
  2. - such generality.
 Building on this framework, this document expands the above CHOICE
 construct as follows.
    CMPCertificate ::= CHOICE {
       x509v3PKCert        Certificate,
       x509v2AttCert   [0] AttributeCertificate,
                           -- defined in [ATTCERT]
       openPGPCert     [2] OpenPGPCert
    }
    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 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 accommodate
 other certificate types, if this is found to be necessary.

4.2. CMC

 The CMC protocol uses the CMS (Cryptographic Message Syntax) syntax
 [CMS], which defines the certificate type as
  CertificateChoices ::= CHOICE {
    certificate Certificate,
    extendedCertificate [0] IMPLICIT ExtendedCertificate,  -- Obsolete
    v1AttrCert [1] IMPLICIT AttributeCertificateV1,        -- Obsolete
    v2AttrCert [2] IMPLICIT AttributeCertificateV2 }
 Similar to PKIX-CMP, this CHOICE can be extended to include
 additional types of certificates as follows.
  CertificateChoices ::= CHOICE {
    certificate Certificate,
    extendedCertificate [0] IMPLICIT ExtendedCertificate,  -- Obsolete
    v1AttrCert [1] IMPLICIT AttributeCertificateV1,        -- Obsolete
    v2AttrCert [2] IMPLICIT AttributeCertificateV2,
    openPGPCert [3] IMPLICIT OpenPGPCert }

Blinov & Adams Informational [Page 11] RFC 4212 Alternative Certificate Formats October 2005

 This allows both X.509 attribute certificates and OpenPGP
 certificates to be used within the CMC management messages.  In the
 future, this construct may be expanded further (in subsequent
 revisions of this document) to accommodate other certificate types,
 if this is found to be necessary.
 The CMC specification defines certain constraints on the subject and
 publicKey fields of the CRMF's CertTemplate structure.  The same
 constraints should apply to the AltCertTemplate structure if
 alternative certificate types are used.  For example, the CMC
 specification mandates that
    When CRMF message bodies are used in the Full Enrollment Request
    message, each CRMF message MUST include both the subject and
    publicKey fields in the CertTemplate.
 If alternative certificate types are used, this should be extended as
    When CRMF message bodies are used in the Full Enrollment Request
    message, each CRMF message MUST include both the subject and
    publicKey fields in the CertTemplate (or in the altCertTemplate
    control).

5. Security Considerations

5.1. Protection of Alternative Certificate Templates

 This document defines extensions to the CRMF format, so security
 considerations from the CRMF specification [CRMF] apply here as well.
 In particular, the security of alternative certificate templates
 relies upon the security mechanisms of the protocol or process used
 to communicate with CAs.
 Exact security requirements depend on a particular PKI deployment,
 but integrity protection and message origin authentication are
 typically required for certification requests.  The CMP and CMC
 certificate management protocols mentioned in this document provide
 both integrity protection and message origin authentication for
 request messages (which includes certificate templates as well).
 Confidentiality may also be required where alternative certificate
 templates contain subscriber-sensitive information.  The CMC protocol
 allows the content of request messages to be encrypted.  CMP does not
 include confidentiality mechanisms for certification requests, but if
 confidentiality is needed, it can be achieved with a lower-layer
 security protocol (e.g., TLS or IPsec).

Blinov & Adams Informational [Page 12] RFC 4212 Alternative Certificate Formats October 2005

5.2. Request Authorisation

 In order to make a decision as to whether a request should be
 accepted, a CA should normally be able to compare the (authenticated)
 name of the sender of the request with the request subject name.
 For example, an End Entity may be allowed to request additional
 certificates for himself/herself.  In this case, the CA will accept a
 request if the Sender is equal to the Subject (of course, other
 conditions will have to be checked as well before the certificate is
 granted).
 If a PGP certificate is requested using the extensions proposed here,
 the Sender field of the request will be encoded as an ASN.1
 GeneralName (in both CMP and CMC), while the Subject will be
 represented as a PGP UserID.  Since the PGP UserID is effectively an
 unrestricted octet string, it is not always trivial to compare these
 two types.  It is possible that an attacker may try to submit
 requests with specially crafted UserIDs (e.g., that include obscure
 characters) in order to trick the CA comparison algorithm and obtain
 a PGP certificate with a UserID that belongs to someone else.
 In these circumstances, it is safer for the CA, when building the PGP
 certificate's UserID, to completely rebuild the UserID based on the
 content of the authenticated Sender name rather than take the UserID
 from the request.  To achieve this, additional information about the
 End Entity may be required at the CA (e.g., the EE's email address).

5.3. PGP Parser

 Software components that implement the proposed extensions (e.g., CMP
 or CMC servers) will necessarily increase in complexity.  If a
 "standard" server is expected to be able to parse ASN.1 streams, the
 "extended" server is required to be able to parse PGP streams as
 well.  A PGP parser code may introduce new security vulnerabilities
 that can be exploited by an attacker to mount a DoS attack or gain
 access to the server.
 In order to reduce the consequences of a successful attack, it is
 recommended that the CMP or CMC servers be run on a separate machine
 from the main CA server.  These protocol servers should not have
 access to the main CA key and should not have write access to the CA
 store.

Blinov & Adams Informational [Page 13] RFC 4212 Alternative Certificate Formats October 2005

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 19            === User ID packet ===
    01A7:  41 6C .. 6D 3E         "Alice <alice@example.com>"
    01C0:  89 00 49         === Signature packet (self-signature) ===
    01C3:  04 10 11 02            ver 4, gen cert, DSA, SHA1
    01C7:  00 09 05 02 3C 58 27 A2 02 1B 03
                                  created 30 Jan 2002, key usage:
                                  sign data and certify other keys
    01D2:  00 0A 09 10 43 5C .. 06 77   issuer key id
    01DE:  5A C2                  left 16 bits of signed hash value
    01E0:  00 A0 EB 00 .. 1B 75   DSA value r
    01F6:  00 A0 F4 E4 .. A8 3D   DSA value s
    020C:  B9 02 0D         === Public Subkey packet ===
    020F:  04 3C 58 27 A2 10      ver 4, created 30 Jan 2002,
                                  Elgamal (encrypt-only) algorithm
    0215:  08 00 F6 42 .. 0B 3B   Elgamal prime p
    0317:  00 02 02               Elgamal group generator g
    031A:  07 FE 37 BA .. DF 21   Elgamal public key value y
    041C:  89 00 49         === Signature packet (subkey binding) ===
    041F:  04 18 11 02            ver 4, subkey binding, DSA, SHA1
    0423:  00 09 05 02 3C 58 27 A2 02 1B 0C
                                  created 30 Jan 2002, key usage:
                                  encrypt communications and storage
    042E:  00 0A 09 10 43 5C .. 06 77   issuer key id
    043A:  C7 DE                  left 16 bits of signed hash value
    043C:  00 9E 21 33 .. 39 1B   DSA value r
    0452:  00 9F 64 D7 .. 63 08   DSA value s
    0468:

Blinov & Adams Informational [Page 14] RFC 4212 Alternative Certificate Formats October 2005

 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 19            === User ID packet ===
    01A7:    <the same as in the request>
    01C0:  89 00 49         === Signature packet (self-signature) ===
    01C3:    <the same as in the request>
    020C:  89 00 49         === Signature packet (certification) ===
    020F:  04 13 11 02            ver 4, positive cert, DSA, SHA1
    0213:  00 09 05 02 3C 58 28 1A 02 1B 03
                                  created 30 Jan 2002, key usage:
                                  sign data and certify other keys
    021E:  00 0A 09 10 F0 0D .. 1F CA   issuer key id
    022A:  06 DF                  left 16 bits of signed hash value
    022C:  00 9F 57 2D .. 26 E3   DSA value r
    0242:  00 A0 B3 02 .. CE 65   DSA value s
    0258:  B9 02 0D         === Public Subkey packet ===
    025B:    <the same as in the request>
    0468:  89 00 49         === Signature packet (subkey binding) ===
    046B:    <the same as in the request>
    04B4:

A2. Certificate Request with Central Key Generation

 Alice requests that the CA generate an RSA key pair that will be used
 for signing, an RSA key pair that will be used for encryption, and
 requests that the CA 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 19            === User ID packet ===
    0112:  41 6C .. 6D 3E         "Alice <alice@example.com>"
    012B:  89 00 23         === Signature packet (Template) ===
    012E:  04 10 11 02            ver 4, gen cert, DSA, SHA1
    0132:  00 09 05 02 FF FF FF FF 02 1B 03
                                  any creation date, key usage:
                                  sign data and certify other keys
    013D:  00 0A 09 10 FF FF .. FF FF   issuer key id - any
    0149:  05 3A                  left 16 bits of signed hash value
    014B:  00 08 FF               DSA value r - any
    014E:  00 08 FF               DSA value s - any

Blinov & Adams Informational [Page 15] RFC 4212 Alternative Certificate Formats October 2005

    0151:  99 01 0D         === Public Subkey packet (Template) ===
    0154:  04 FF FF FF FF 01      ver 4, any creation date, RSA
    015A:  08 00 FF FF .. FF FF   RSA public modulus n - given length
    025C:  00 11 01 00 01         RSA public exponent e
    0261:  89 00 20         === Signature packet (Template) ===
    0264:  04 18 01 02            ver 4, subkey binding, RSA, SHA1
    0268:  00 09 05 02 FF FF FF FF 02 1B 0C
                                  any creation date, key usage:
                                  encrypt communications and storage
    0273:  00 0A 09 10 FF FF .. FF FF   issuer key id - any
    027F:  12 E6                  left 16 bits of signed hash value
    0281:  00 08 FF               RSA signature value - any
    0284:
 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 19            === User ID packet ===
    0112:  41 6C .. 6D 3E         "Alice <alice@example.com>"
    012B:  89 01 1F         === Signature packet (self-signature) ===
    012E:  04 10 01 02            ver 4, gen cert, RSA, SHA1
    0132:  00 09 05 02 3C 5A A5 BB 02 1B 03
                                  created 01 Feb 2002, key usage:
                                  sign data and certify other keys
    014D:  00 0A 09 10 8E AF .. 1A 18   issuer key id
    0149:  3B 21                  left 16 bits of signed hash value
    014B:  07 FE 2F 1D .. C0 81   RSA signature value
    024D:  89 00 49         === Signature packet (certification) ===
    0250:  04 13 11 02            ver 4, positive cert, DSA, SHA1
    0254:  00 09 05 02 3C 5A A5 DC 02 1B 03
                                  created 01 Feb 2002, key usage:
                                  sign data and certify other keys
    025F:  00 0A 09 10 F0 0D .. 1F CA   issuer key id
    026B:  BA C2                  left 16 bits of signed hash value
    026D:  00 9F 5E 58 .. 30 B3   DSA value r
    0283:  00 A0 D1 D7 .. 5A AF   DSA value s
    0299:  99 01 0D         === Public Subkey packet ===
    029C:  04 3C 5A A5 C5 01      ver 4, created 01 Feb 2002, RSA
    02A2:  08 00 C3 03 .. 8C 53   RSA public modulus n
    03A4:  00 11 01 00 01         RSA public exponent e
    03A9:  89 01 1F         === Signature packet (subkey binding) ===
    03AC:  04 18 01 02            ver 4, subkey binding, RSA, SHA1

Blinov & Adams Informational [Page 16] RFC 4212 Alternative Certificate Formats October 2005

    03B0:  00 09 05 02 3C 5A A5 C5 05 1B 0C
                                  created 01 Feb 2002, key usage:
                                  encrypt communications and storage
    03BB:  00 0A 09 10 8E AF .. 1A 18   issuer key id
    03C7:  C8 44                  left 16 bits of signed hash value
    03C9:  07 FB 04 D7 .. 75 BE   RSA signature value
    04CB:

Normative References

 [ASN1]    CCITT Recommendation X.208: Specification of Abstract
           Syntax Notation One (ASN.1), 1988.
 [ATTCERT] Farrell, S. and R. Housley, "An Internet Attribute
           Certificate Profile for Authorization", RFC 3281, April
           2002.
 [CMC]     Myers, M., Liu, X., Schaad, J., and J. Weinstein,
           "Certificate Management Messages over CMS", RFC 2797, April
           2000.
 [CMS]     Housley, R., "Cryptographic Message Syntax (CMS)", RFC
           3852, July 2004.
 [CMP]     Adams, C., Farrell, S., Kause, T., and T. Mononen,
           "Internet X.509 Public Key Infrastructure: Certificate
           Management Protocol (CMP)", RFC 4210, September 2005.
 [CRMF]    Schaad, J., "Internet X.509 Public Key Infrastructure:
           Certificate Request Message Format (CRMF)", RFC 4211,
           September 2005.
 [OPENPGP] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer,
           "OpenPGP Message Format", RFC 2440, November 1998.
 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119, March 1997.

Blinov & Adams Informational [Page 17] RFC 4212 Alternative Certificate Formats October 2005

Authors' Addresses

 Mikhail Blinov
 Guardeonic Solutions
 Fitzwilliam Court, Leeson Close
 Dublin 2, Ireland
 EMail:  mikblinov@online.ie
 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
 EMail:  cadams@site.uottawa.ca

Blinov & Adams Informational [Page 18] RFC 4212 Alternative Certificate Formats October 2005

Full Copyright Statement

 Copyright (C) The Internet Society (2005).
 This document is subject to the rights, licenses and restrictions
 contained in BCP 78 and at www.rfc-editor.org/copyright.html, and
 except as set forth therein, the authors retain all their rights.
 This document and the information contained herein are provided on an
 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 ENGINEERING TASK FORCE DISCLAIM 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.

Intellectual Property

 The IETF takes no position regarding the validity or scope of any
 Intellectual Property Rights or other rights that might be claimed to
 pertain to the implementation or use of the technology described in
 this document or the extent to which any license under such rights
 might or might not be available; nor does it represent that it has
 made any independent effort to identify any such rights.  Information
 on the procedures with respect to rights in RFC documents can be
 found in BCP 78 and BCP 79.
 Copies of IPR disclosures made to the IETF Secretariat and any
 assurances of licenses to be made available, or the result of an
 attempt made to obtain a general license or permission for the use of
 such proprietary rights by implementers or users of this
 specification can be obtained from the IETF on-line IPR repository at
 http://www.ietf.org/ipr.
 The IETF invites any interested party to bring to its attention any
 copyrights, patents or patent applications, or other proprietary
 rights that may cover technology that may be required to implement
 this standard.  Please address the information to the IETF at ietf-
 ipr@ietf.org.

Acknowledgement

 Funding for the RFC Editor function is currently provided by the
 Internet Society.

Blinov & Adams Informational [Page 19]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4212.txt · Last modified: 2005/09/30 22:18 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki