Internet Engineering Task Force (IETF) P. Hoffman Request for Comments: 5912 VPN Consortium Category: Informational J. Schaad ISSN: 2070-1721 Soaring Hawk Consulting June 2010
New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)
Abstract
The Public Key Infrastructure using X.509 (PKIX) certificate format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates those ASN.1 modules to conform to the 2002 version of ASN.1. There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax.
Status of This Memo
This document is not an Internet Standards Track specification; it is published for informational purposes.
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5912.
Hoffman & Schaad Informational [Page 1]
RFC 5912 New ASN.1 for PKIX June 2010
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
Some developers would like the IETF to use the latest version of ASN.1 in its standards. Most of the RFCs that relate to security protocols still use ASN.1 from the 1988 standard, which has been deprecated. This is particularly true for the standards that relate to PKIX, Cryptographic Message Syntax (CMS), and S/MIME.
This document updates the following RFCs to use ASN.1 modules that conform to the 2002 version of ASN.1 [ASN1-2002]. Note that not all the modules are updated; some are included to simply make the set complete.
o RFC 2560, PKIX Online Certificate Status Protocol (OCSP) [RFC2560]
o RFC 5280, PKIX certificate and Certificate Revocation List (CRL) profile [RFC5280] (both the implicit and explicit modules)
o RFC 5755, PKIX attribute certificates, version 2 [RFC5755]
Note that some of the modules in this document get some of their definitions from places different than the modules in the original RFCs. The idea is that these modules, when combined with the modules in [RFC5911] can stand on their own and do not need to import definitions from anywhere else. Also note that the ASN.1 modules in this document have references in their text comments that need to be looked up in original RFCs, and that some of those references may have already been superseded by later RFCs.
Hoffman & Schaad Informational [Page 3]
RFC 5912 New ASN.1 for PKIX June 2010
The document also includes a module of common definitions called "PKIX-CommonTypes". These definitions are used here and in [RFC5911].
The document also includes a module of common definitions called "AlgorithmInformation". These definitions are used here and in [RFC5911].
The modules in this document use the object model available in the 2002 ASN.1 documents to a great extent. Objects for each of the different algorithm types are defined. Also, all of the places where the 1988 ASN.1 syntax had ANY holes to allow for variable syntax now use objects.
Much like the way that the PKIX and S/MIME working groups use the prefix of id- for object identifiers, this document has also adopted a set of two-, three-, and four-letter prefixes to allow for quick identification of the type of an object based on its name. This allows, for example, the same back half of the name to be used for the different objects. Thus, "id-sha1" is the object identifier, while "mda-sha1" is the message digest object for "sha1".
One or more object sets for the different types of algorithms are defined. A single consistent name for each different algorithm type is used. For example, an object set named PublicKeys contains the public keys defined in that module. If no public keys are defined, then the object set is not created. When importing these object sets into an ASN.1 module, one needs to be able to distinguish between the different object sets with the same name. This is done by using both the module name (as specified in the IMPORT statement) and the object set name. For example, in the module for RFC 5280:
This section contains a module that is imported by many other modules in this document and in [RFC5911]. This module does not come from any existing RFC.
-- ATTRIBUTE -- -- Describe the set of data associated with an attribute of some type -- -- &id is an OID identifying the attribute -- &Type is the ASN.1 type structure for the attribute; not all -- attributes have a data structure, so this field is optional -- &minCount contains the minimum number of times the attribute can -- occur in an AttributeSet -- &maxCount contains the maximum number of times the attribute can -- appear in an AttributeSet -- Note: this cannot be automatically enforced as the field -- cannot be defaulted to MAX. -- &equality-match contains information about how matching should be -- done -- -- Currently we are using two different prefixes for attributes. -- -- at- for certificate attributes -- aa- for CMS attributes --
-- Specification of MATCHING-RULE information object class --
MATCHING-RULE ::= CLASS { &ParentMatchingRules MATCHING-RULE OPTIONAL, &AssertionType OPTIONAL, &uniqueMatchIndicator ATTRIBUTE OPTIONAL, &id OBJECT IDENTIFIER UNIQUE } WITH SYNTAX { [PARENT &ParentMatchingRules] [SYNTAX &AssertionType] [UNIQUE-MATCH-INDICATOR &uniqueMatchIndicator] ID &id }
-- AttributeSet -- -- Used when a set of attributes is to occur. -- -- type contains the identifier of the attribute -- values contains a set of values where the structure of the ASN.1 -- is defined by the attribute -- -- The parameter contains the set of objects describing -- those attributes that can occur in this location. --
AttributeSet{ATTRIBUTE:AttrSet} ::= SEQUENCE { type ATTRIBUTE.&id({AttrSet}), values SET SIZE (1..MAX) OF ATTRIBUTE. &Type({AttrSet}{@type}) }
-- SingleAttribute -- -- Used for a single valued attribute -- -- The parameter contains the set of objects describing the -- attributes that can occur in this location --
SingleAttribute{ATTRIBUTE:AttrSet} ::= SEQUENCE { type ATTRIBUTE.&id({AttrSet}), value ATTRIBUTE.&Type({AttrSet}{@type}) }
-- EXTENSION
Hoffman & Schaad Informational [Page 6]
RFC 5912 New ASN.1 for PKIX June 2010
-- -- This class definition is used to describe the association of -- object identifier and ASN.1 type structure for extensions -- -- All extensions are prefixed with ext- -- -- &id contains the object identifier for the extension -- &ExtnType specifies the ASN.1 type structure for the extension -- &Critical contains the set of legal values for the critical field. -- This is normally {TRUE|FALSE} but in some instances may be -- restricted to just one of these values. --
EXTENSION ::= CLASS { &id OBJECT IDENTIFIER UNIQUE, &ExtnType, &Critical BOOLEAN DEFAULT {TRUE | FALSE } } WITH SYNTAX { SYNTAX &ExtnType IDENTIFIED BY &id [CRITICALITY &Critical] }
-- Extensions -- -- Used for a sequence of extensions. -- -- The parameter contains the set of legal extensions that can -- occur in this sequence. --
Extensions{EXTENSION:ExtensionSet} ::= SEQUENCE SIZE (1..MAX) OF Extension{{ExtensionSet}}
-- Extension -- -- Used for a single extension -- -- The parameter contains the set of legal extensions that can -- occur in this extension. -- -- The restriction on the critical field has been commented out -- the authors are not completely sure it is correct. -- The restriction could be done using custom code rather than -- compiler-generated code, however. --
critical BOOLEAN -- (EXTENSION.&Critical({ExtensionSet}{@extnID})) DEFAULT FALSE, extnValue OCTET STRING (CONTAINING EXTENSION.&ExtnType({ExtensionSet}{@extnID})) -- contains the DER encoding of the ASN.1 value -- corresponding to the extension type identified -- by extnID }
-- Security Category -- -- Security categories are used both for specifying clearances and -- for labeling objects. We move this here from RFC 3281 so that -- they will use a common single object class to express this -- information. --
SECURITY-CATEGORY ::= TYPE-IDENTIFIER
SecurityCategory{SECURITY-CATEGORY:Supported} ::= SEQUENCE { type [0] IMPLICIT SECURITY-CATEGORY. &id({Supported}), value [1] EXPLICIT SECURITY-CATEGORY. &Type({Supported}{@type}) }
This section contains a module that is imported by many other modules in this document. Note that this module is also given in [RFC5911]. This module does not come from any existing RFC.
ParamOptions ::= ENUMERATED { required, -- Parameters MUST be encoded in structure preferredPresent, -- Parameters SHOULD be encoded in structure preferredAbsent, -- Parameters SHOULD NOT be encoded in structure absent, -- Parameters MUST NOT be encoded in structure inheritable, -- Parameters are inherited if not present optional, -- Parameters MAY be encoded in the structure ... }
-- DIGEST-ALGORITHM -- -- Describes the basic information for ASN.1 and a digest -- algorithm. -- -- &id - contains the OID identifying the digest algorithm -- &Params - if present, contains the type for the algorithm -- parameters; if absent, implies no parameters -- ¶mPresence - parameter presence requirement -- -- Additional information such as the length of the hash could have -- been encoded. Without a clear understanding of what information -- is needed by applications, such extraneous information was not -- considered to be of sufficent importance. -- -- Example: -- mda-sha1 DIGEST-ALGORITHM ::= { -- IDENTIFIER id-sha1 -- PARAMS TYPE NULL ARE preferredAbsent -- }
-- SIGNATURE-ALGORITHM -- -- Describes the basic properties of a signature algorithm -- -- &id - contains the OID identifying the signature algorithm -- &Value - contains a type definition for the value structure of -- the signature; if absent, implies that no ASN.1 -- encoding is performed on the value -- &Params - if present, contains the type for the algorithm -- parameters; if absent, implies no parameters -- ¶mPresence - parameter presence requirement -- &HashSet - The set of hash algorithms used with this -- signature algorithm -- &PublicKeySet - the set of public key algorithms for this -- signature algorithm -- &smimeCaps - contains the object describing how the S/MIME -- capabilities are presented. -- -- Example: -- sig-RSA-PSS SIGNATURE-ALGORITHM ::= { -- IDENTIFIER id-RSASSA-PSS -- PARAMS TYPE RSASSA-PSS-params ARE required -- HASHES { mda-sha1 | mda-md5, ... } -- PUBLIC-KEYS { pk-rsa | pk-rsa-pss } -- }
-- PUBLIC-KEY -- -- Describes the basic properties of a public key -- -- &id - contains the OID identifying the public key -- &KeyValue - contains the type for the key value -- &Params - if present, contains the type for the algorithm -- parameters; if absent, implies no parameters -- ¶mPresence - parameter presence requirement -- &keyUsage - contains the set of bits that are legal for this -- key type. Note that is does not make any statement -- about how bits may be paired. -- &PrivateKey - contains a type structure for encoding the private -- key information. -- -- Example: -- pk-rsa-pss PUBLIC-KEY ::= { -- IDENTIFIER id-RSASSA-PSS -- KEY RSAPublicKey -- PARAMS TYPE RSASSA-PSS-params ARE optional -- CERT-KEY-USAGE { .... } -- }
-- KEY-TRANSPORT -- -- Describes the basic properties of a key transport algorithm -- -- &id - contains the OID identifying the key transport algorithm -- &Params - if present, contains the type for the algorithm -- parameters; if absent, implies no parameters
Hoffman & Schaad Informational [Page 11]
RFC 5912 New ASN.1 for PKIX June 2010
-- ¶mPresence - parameter presence requirement -- &PublicKeySet - specifies which public keys are used with -- this algorithm -- &smimeCaps - contains the object describing how the S/MIME -- capabilities are presented. -- -- Example: -- kta-rsaTransport KEY-TRANSPORT ::= { -- IDENTIFIER &id -- PARAMS TYPE NULL ARE required -- PUBLIC-KEYS { pk-rsa | pk-rsa-pss } -- }
-- KEY-AGREE -- -- Describes the basic properties of a key agreement algorithm -- -- &id - contains the OID identifying the key agreement algorithm -- &Params - if present, contains the type for the algorithm -- parameters; if absent, implies no parameters -- ¶mPresence - parameter presence requirement -- &PublicKeySet - specifies which public keys are used with -- this algorithm -- &Ukm - type of user keying material used -- &ukmPresence - specifies the requirements to define the UKM field -- &smimeCaps - contains the object describing how the S/MIME -- capabilities are presented. -- -- Example: -- kaa-dh-static-ephemeral KEY-AGREE ::= { -- IDENTIFIER id-alg-ESDH -- PARAMS TYPE KeyWrapAlgorithm ARE required -- PUBLIC-KEYS { -- {IDENTIFIER dh-public-number KEY DHPublicKey -- PARAMS TYPE DHDomainParameters ARE inheritable }
Hoffman & Schaad Informational [Page 12]
RFC 5912 New ASN.1 for PKIX June 2010
-- } -- - - UKM should be present but is not separately ASN.1-encoded -- UKM ARE preferredPresent -- }
-- KEY-WRAP -- -- Describes the basic properties of a key wrap algorithm -- -- &id - contains the OID identifying the key wrap algorithm -- &Params - if present, contains the type for the algorithm -- parameters; if absent, implies no parameters -- ¶mPresence - parameter presence requirement -- &smimeCaps - contains the object describing how the S/MIME -- capabilities are presented. -- -- Example: -- kwa-cms3DESwrap KEY-WRAP ::= { -- IDENTIFIER id-alg-CMS3DESwrap -- PARAMS TYPE NULL ARE required -- }
-- KEY-DERIVATION -- -- Describes the basic properties of a key derivation algorithm -- -- &id - contains the OID identifying the key derivation algorithm -- &Params - if present, contains the type for the algorithm -- parameters; if absent, implies no parameters -- ¶mPresence - parameter presence requirement -- &smimeCaps - contains the object describing how the S/MIME -- capabilities are presented. -- -- Example: -- kda-pbkdf2 KEY-DERIVATION ::= { -- IDENTIFIER id-PBKDF2 -- PARAMS TYPE PBKDF2-params ARE required -- }
-- MAC-ALGORITHM -- -- Describes the basic properties of a message -- authentication code (MAC) algorithm -- -- &id - contains the OID identifying the MAC algorithm -- &Params - if present, contains the type for the algorithm -- parameters; if absent, implies no parameters -- ¶mPresence - parameter presence requirement -- &keyed - MAC algorithm is a keyed MAC algorithm -- &smimeCaps - contains the object describing how the S/MIME -- capabilities are presented. -- -- Some parameters that perhaps should have been added would be -- fields with the minimum and maximum MAC lengths for -- those MAC algorithms that allow truncations. -- -- Example: -- maca-hmac-sha1 MAC-ALGORITHM ::= { -- IDENTIFIER hMAC-SHA1
Hoffman & Schaad Informational [Page 14]
RFC 5912 New ASN.1 for PKIX June 2010
-- PARAMS TYPE NULL ARE preferredAbsent -- IS KEYED MAC TRUE -- SMIME-CAPS {IDENTIFIED BY hMAC-SHA1} -- }
-- CONTENT-ENCRYPTION -- -- Describes the basic properties of a content encryption -- algorithm -- -- &id - contains the OID identifying the content -- encryption algorithm -- &Params - if present, contains the type for the algorithm -- parameters; if absent, implies no parameters -- ¶mPresence - parameter presence requirement -- &smimeCaps - contains the object describing how the S/MIME -- capabilities are presented. -- -- Example: -- cea-3DES-cbc CONTENT-ENCRYPTION ::= { -- IDENTIFIER des-ede3-cbc -- PARAMS TYPE IV ARE required -- SMIME-CAPS { IDENTIFIED BY des-ede3-cbc } -- }
-- ALGORITHM -- -- Describes a generic algorithm identifier -- -- &id - contains the OID identifying the algorithm -- &Params - if present, contains the type for the algorithm -- parameters; if absent, implies no parameters -- ¶mPresence - parameter presence requirement -- &smimeCaps - contains the object describing how the S/MIME -- capabilities are presented. -- -- This would be used for cases where an algorithm of an unknown -- type is used. In general however, one should either define -- a more complete algorithm structure (such as the one above) -- or use the TYPE-IDENTIFIER class.
-- AlgorithmIdentifier -- -- Provides the generic structure that is used to encode algorithm -- identification and the parameters associated with the -- algorithm. -- -- The first parameter represents the type of the algorithm being -- used. -- The second parameter represents an object set containing the -- algorithms that may occur in this situation. -- The initial list of required algorithms should occur to the -- left of an extension marker; all other algorithms should -- occur to the right of an extension marker. -- -- The object class ALGORITHM can be used for generic unspecified -- items. -- If new ALGORITHM classes are defined, the fields &id and &Params -- need to be present as fields in the object in order to use -- this parameterized type. -- -- Example:
-- S/MIME Capabilities -- -- We have moved the SMIME-CAPS from the module for RFC 3851 to here -- because it is used in RFC 4262 (X.509 Certificate Extension for -- S/MIME Capabilities) -- -- -- This class is used to represent an S/MIME capability. S/MIME -- capabilities are used to represent what algorithm capabilities -- an individual has. The classic example was the content encryption -- algorithm RC2 where the algorithm id and the RC2 key lengths -- supported needed to be advertised, but the IV used is not fixed. -- Thus, for RC2 we used -- -- cap-RC2CBC SMIME-CAPS ::= { -- TYPE INTEGER ( 40 | 128 ) IDENTIFIED BY rc2-cbc } -- -- where 40 and 128 represent the RC2 key length in number of bits. -- -- Another example where information needs to be shown is for -- RSA-OAEP where only specific hash functions or mask generation -- functions are supported, but the saltLength is specified by the -- sender and not the recipient. In this case, one can either -- generate a number of capability items, -- or a new S/MIME capability type could be generated where -- multiple hash functions could be specified. -- -- -- SMIME-CAP -- -- This class is used to associate the type that describes the -- capabilities with the object identifier. --
internalError (2), --Internal error in issuer tryLater (3), --Try again later -- (4) is not used sigRequired (5), --Must sign the request unauthorized (6) --Request unauthorized }
-- -- S/MIME CAPS for algorithms in this document -- -- For all of the algorithms laid out in this document, the -- parameters field for the S/MIME capabilities is defined as -- ABSENT as there are no specific values that need to be known -- by the receiver for negotiation.
pk-rsa PUBLIC-KEY ::= { IDENTIFIER rsaEncryption KEY RSAPublicKey PARAMS TYPE NULL ARE absent -- Private key format not in this module -- CERT-KEY-USAGE {digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment, keyCertSign, cRLSign} }
RSAPublicKey ::= SEQUENCE { modulus INTEGER, -- n publicExponent INTEGER -- e }
-- DSA PK Algorithm, Parameters, and Keys
pk-dsa PUBLIC-KEY ::= { IDENTIFIER id-dsa KEY DSAPublicKey PARAMS TYPE DSA-Params ARE inheritable -- Private key format not in this module -- CERT-KEY-USAGE { digitalSignature, nonRepudiation, keyCertSign, cRLSign } }
-- Diffie-Hellman PK Algorithm, Parameters, and Keys
pk-dh PUBLIC-KEY ::= { IDENTIFIER dhpublicnumber KEY DHPublicKey PARAMS TYPE DomainParameters ARE inheritable -- Private key format not in this module -- CERT-KEY-USAGE {keyAgreement, encipherOnly, decipherOnly } }
DomainParameters ::= SEQUENCE { p INTEGER, -- odd prime, p=jq +1 g INTEGER, -- generator, g q INTEGER, -- factor of p-1 j INTEGER OPTIONAL, -- subgroup factor, j>= 2 validationParams ValidationParams OPTIONAL }
ValidationParams ::= SEQUENCE { seed BIT STRING, pgenCounter INTEGER }
DHPublicKey ::= INTEGER -- public key, y = g^x mod p
-- KEA PK Algorithm and Parameters
pk-kea PUBLIC-KEY ::= { IDENTIFIER id-keyExchangeAlgorithm -- key is not encoded -- PARAMS TYPE KEA-Params-Id ARE required -- Private key format not in this module -- CERT-KEY-USAGE {keyAgreement, encipherOnly, decipherOnly } } id-keyExchangeAlgorithm OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) dod(2) infosec(1) algorithms(1) 22 }
Hoffman & Schaad Informational [Page 26]
RFC 5912 New ASN.1 for PKIX June 2010
KEA-Params-Id ::= OCTET STRING
-- Elliptic Curve (EC) Signatures: Unrestricted Algorithms -- (Section 2.1.1 of RFC 5480) -- -- EC Unrestricted Algorithm ID -- -- this is used for ECDSA
pk-ec PUBLIC-KEY ::= { IDENTIFIER id-ecPublicKey KEY ECPoint PARAMS TYPE ECParameters ARE required -- Private key format not in this module -- CERT-KEY-USAGE { digitalSignature, nonRepudiation, keyAgreement, keyCertSign, cRLSign } }
ECPoint ::= OCTET STRING -- see RFC 5480 for syntax and restrictions
-- Elliptic Curve (EC) Signatures: Restricted Algorithms -- (Section 2.1.2 of RFC 5480) -- -- EC Diffie-Hellman Algorithm ID
pk-ecDH PUBLIC-KEY ::= { IDENTIFIER id-ecDH KEY ECPoint PARAMS TYPE ECParameters ARE required -- Private key format not in this module -- CERT-KEY-USAGE { keyAgreement, encipherOnly, decipherOnly } }
pk-ecMQV PUBLIC-KEY ::= { IDENTIFIER id-ecMQV KEY ECPoint PARAMS TYPE ECParameters ARE required -- Private key format not in this module -- CERT-KEY-USAGE { keyAgreement, encipherOnly, decipherOnly } }
-- Parameters and Keys for both Restricted and Unrestricted EC
ECParameters ::= CHOICE { namedCurve CURVE.&id({NamedCurve}) -- implicitCurve NULL -- implicitCurve MUST NOT be used in PKIX -- specifiedCurve SpecifiedCurve -- specifiedCurve MUST NOT be used in PKIX -- Details for specifiedCurve can be found in [X9.62] -- Any future additions to this CHOICE should be coordinated -- with ANSI X.9. } -- If you need to be able to decode ANSI X.9 parameter structures, -- uncomment the implicitCurve and specifiedCurve above, and also -- uncomment the following: --(WITH COMPONENTS {namedCurve PRESENT})
-- Sec 2.1.1.1 Named Curve
CURVE ::= CLASS { &id OBJECT IDENTIFIER UNIQUE } WITH SYNTAX { ID &id }
NamedCurve CURVE ::= { { ID secp192r1 } | { ID sect163k1 } | { ID sect163r2 } | { ID secp224r1 } | { ID sect233k1 } | { ID sect233r1 } | { ID secp256r1 } | { ID sect283k1 } | { ID sect283r1 } | { ID secp384r1 } | { ID sect409k1 } | { ID sect409r1 } | { ID secp521r1 } | { ID sect571k1 } | { ID sect571r1 }, ... -- Extensible }
-- Note in [X9.62] the curves are referred to as 'ansiX9' as -- opposed to 'sec'. For example, secp192r1 is the same curve as -- ansix9p192r1.
-- Note that in [PKI-ALG] the secp192r1 curve was referred to as -- prime192v1 and the secp256r1 curve was referred to as -- prime256v1.
-- Note that [FIPS186-3] refers to secp192r1 as P-192, -- secp224r1 as P-224, secp256r1 as P-256, secp384r1 as P-384, -- and secp521r1 as P-521.
-- ============================ -- Object Set exports -- ============================ -- -- Define top-level symbols with all of the objects defined for -- export to other modules. These objects would be included as part -- of an Object Set to restrict the set of legal values. --
pk-rsaSSA-PSS PUBLIC-KEY ::= { IDENTIFIER id-RSASSA-PSS KEY RSAPublicKey PARAMS TYPE RSASSA-PSS-params ARE optional -- Private key format not in this module -- CERT-KEY-USAGE { nonRepudiation, digitalSignature, keyCertSign, cRLSign } }
-- -- Signature algorithm definition for PSS signatures --
-- -- Public key definition for OAEP encryption --
pk-rsaES-OAEP PUBLIC-KEY ::= { IDENTIFIER id-RSAES-OAEP KEY RSAPublicKey PARAMS TYPE RSAES-OAEP-params ARE optional -- Private key format not in this module -- CERT-KEY-USAGE {keyEncipherment, dataEncipherment} }
-- -- Key transport key lock definition for OAEP encryption --
kta-rsaES-OAEP KEY-TRANSPORT ::= { IDENTIFIER id-RSAES-OAEP PARAMS TYPE RSAES-OAEP-params ARE required PUBLIC-KEYS { pk-rsa | pk-rsaES-OAEP } SMIME-CAPS { TYPE RSAES-OAEP-params IDENTIFIED BY id-RSAES-OAEP} } -- ============================ -- Basic object identifiers -- ============================
-- When id-RSAES-OAEP is used in an AlgorithmIdentifier, -- and the parameters field is present, it MUST be -- RSAES-OAEP-params.
id-RSAES-OAEP OBJECT IDENTIFIER ::= { pkcs-1 7 }
-- When id-mgf1 is used in an AlgorithmIdentifier, the parameters -- MUST be present and MUST be a HashAlgorithm.
id-mgf1 OBJECT IDENTIFIER ::= { pkcs-1 8 }
-- When id-pSpecified is used in an AlgorithmIdentifier, the -- parameters MUST be an OCTET STRING.
id-pSpecified OBJECT IDENTIFIER ::= { pkcs-1 9 }
-- When id-RSASSA-PSS is used in an AlgorithmIdentifier, and the -- parameters field is present, it MUST be RSASSA-PSS-params.
id-RSASSA-PSS OBJECT IDENTIFIER ::= { pkcs-1 10 }
-- When the following OIDs are used in an AlgorithmIdentifier, the -- parameters SHOULD be absent, but if the parameters are present, -- they MUST be NULL.
-- -- id-sha1 is imported from RFC 3279. Additionally, the v1.5 -- signature algorithms (i.e., rsaWithSHA256) are now solely placed -- in that module. --
-- =================== -- Main structures -- ===================
-- AlgorithmIdentifier parameters for id-RSASSA-PSS. -- Note that the tags in this Sequence are explicit. -- Note: The hash algorithm in hashAlgorithm and in
-- AlgorithmIdentifier parameters for id-RSAES-OAEP. -- Note that the tags in this Sequence are explicit. -- Note: The hash algorithm in hashFunc and in -- maskGenFunc should be the same.
CertTemplate, PKIPublicationInfo, EncryptedValue, CertId, CertReqMessages FROM PKIXCRMF-2009 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-crmf2005-02(55) } -- see also the behavioral clarifications to CRMF codified in -- Appendix C of this specification
CertificationRequest FROM PKCS-10 {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-pkcs10-2009(69)} -- (specified in RFC 2986 with 1993 ASN.1 syntax and IMPLICIT -- tags). Alternatively, implementers may directly include -- the [PKCS10] syntax in this module ;
-- the rest of the module contains locally defined OIDs and -- constructs
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. Those -- implementations that do not foresee a need to ever support -- other certificate types MAY, if they wish, comment out the -- above structure and "uncomment" the following one prior to -- compiling this ASN.1 module. (Note that interoperability -- with implementations that don't do this will be unaffected by -- this change.)
PKIMessages ::= SEQUENCE SIZE (1..MAX) OF PKIMessage
PKIHeader ::= SEQUENCE { pvno INTEGER { cmp1999(1), cmp2000(2) }, sender GeneralName, -- identifies the sender recipient GeneralName, -- identifies the intended recipient messageTime [0] GeneralizedTime OPTIONAL, -- time of production of this message (used when sender -- believes that the transport will be "suitable"; i.e., -- that the time will still be meaningful upon receipt) protectionAlg [1] AlgorithmIdentifier{ALGORITHM, {...}} OPTIONAL, -- algorithm used for calculation of protection bits senderKID [2] KeyIdentifier OPTIONAL, recipKID [3] KeyIdentifier OPTIONAL, -- to identify specific keys used for protection transactionID [4] OCTET STRING OPTIONAL, -- identifies the transaction; i.e., this will be the same in -- corresponding request, response, certConf, and PKIConf -- messages senderNonce [5] OCTET STRING OPTIONAL, recipNonce [6] OCTET STRING OPTIONAL, -- nonces used to provide replay protection, senderNonce -- is inserted by the creator of this message; recipNonce -- is a nonce previously inserted in a related message by -- the intended recipient of this message freeText [7] PKIFreeText OPTIONAL, -- this may be used to indicate context-specific instructions -- (this field is intended for human consumption) generalInfo [8] SEQUENCE SIZE (1..MAX) OF InfoTypeAndValue OPTIONAL -- this may be used to convey context-specific information -- (this field not primarily intended for human consumption) }
PKIFreeText ::= SEQUENCE SIZE (1..MAX) OF UTF8String -- text encoded as UTF-8 String [RFC3629] (note: each -- UTF8String MAY include an [RFC3066] language tag -- to indicate the language of the contained text; -- see [RFC2482] for details)
PKIBody ::= CHOICE { -- message-specific body elements ir [0] CertReqMessages, --Initialization Request ip [1] CertRepMessage, --Initialization Response cr [2] CertReqMessages, --Certification Request cp [3] CertRepMessage, --Certification Response
ProtectedPart ::= SEQUENCE { header PKIHeader, body PKIBody }
id-PasswordBasedMac OBJECT IDENTIFIER ::= { iso(1) member-body(2) usa(840) nt(113533) nsn(7) algorithms(66) 13 } PBMParameter ::= SEQUENCE { salt OCTET STRING, -- note: implementations MAY wish to limit acceptable sizes -- of this string to values appropriate for their environment -- in order to reduce the risk of denial-of-service attacks owf AlgorithmIdentifier{DIGEST-ALGORITHM, {...}}, -- AlgId for a One-Way Function (SHA-1 recommended) iterationCount INTEGER, -- number of times the OWF is applied -- note: implementations MAY wish to limit acceptable sizes -- of this integer to values appropriate for their environment -- in order to reduce the risk of denial-of-service attacks mac AlgorithmIdentifier{MAC-ALGORITHM, {...}} -- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11], -- or HMAC [RFC2104, RFC2202])
Hoffman & Schaad Informational [Page 45]
RFC 5912 New ASN.1 for PKIX June 2010
}
id-DHBasedMac OBJECT IDENTIFIER ::= { iso(1) member-body(2) usa(840) nt(113533) nsn(7) algorithms(66) 30 } DHBMParameter ::= SEQUENCE { owf AlgorithmIdentifier{DIGEST-ALGORITHM, {...}}, -- AlgId for a One-Way Function (SHA-1 recommended) mac AlgorithmIdentifier{MAC-ALGORITHM, {...}} -- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11], -- or HMAC [RFC2104, RFC2202]) }
PKIStatus ::= INTEGER { accepted (0), -- you got exactly what you asked for grantedWithMods (1), -- you got something like what you asked for; the -- requester is responsible for ascertaining the differences rejection (2), -- you don't get it, more information elsewhere in the message waiting (3), -- the request body part has not yet been processed; expect to -- hear more later (note: proper handling of this status -- response MAY use the polling req/rep PKIMessages specified -- in Section 5.3.22; alternatively, polling in the underlying -- transport layer MAY have some utility in this regard) revocationWarning (4), -- this message contains a warning that a revocation is -- imminent revocationNotification (5), -- notification that a revocation has occurred keyUpdateWarning (6) -- update already done for the oldCertId specified in -- CertReqMsg }
PKIFailureInfo ::= BIT STRING { -- since we can fail in more than one way! -- More codes may be added in the future if/when required. badAlg (0), -- unrecognized or unsupported Algorithm Identifier badMessageCheck (1), -- integrity check failed (e.g., signature did not verify) badRequest (2), -- transaction not permitted or supported badTime (3), -- messageTime was not sufficiently close to the system time, -- as defined by local policy
Hoffman & Schaad Informational [Page 46]
RFC 5912 New ASN.1 for PKIX June 2010
badCertId (4), -- no certificate could be found matching the provided criteria badDataFormat (5), -- the data submitted has the wrong format wrongAuthority (6), -- the authority indicated in the request is different from the -- one creating the response token incorrectData (7), -- the requester's data is incorrect (for notary services) missingTimeStamp (8), -- when the timestamp is missing but should be there -- (by policy) badPOP (9), -- the proof-of-possession failed certRevoked (10), -- the certificate has already been revoked certConfirmed (11), -- the certificate has already been confirmed wrongIntegrity (12), -- invalid integrity, password based instead of signature or -- vice versa badRecipientNonce (13), -- invalid recipient nonce, either missing or wrong value timeNotAvailable (14), -- the TSA's time source is not available unacceptedPolicy (15), -- the requested TSA policy is not supported by the TSA unacceptedExtension (16), -- the requested extension is not supported by the TSA addInfoNotAvailable (17), -- the additional information requested could not be -- understood or is not available badSenderNonce (18), -- invalid sender nonce, either missing or wrong size badCertTemplate (19), -- invalid cert. template or missing mandatory information signerNotTrusted (20), -- signer of the message unknown or not trusted transactionIdInUse (21), -- the transaction identifier is already in use unsupportedVersion (22), -- the version of the message is not supported notAuthorized (23), -- the sender was not authorized to make the preceding -- request or perform the preceding action systemUnavail (24), -- the request cannot be handled due to system unavailability systemFailure (25),
Hoffman & Schaad Informational [Page 47]
RFC 5912 New ASN.1 for PKIX June 2010
-- the request cannot be handled due to system failure duplicateCertReq (26) -- certificate cannot be issued because a duplicate -- certificate already exists }
OOBCertHash ::= SEQUENCE { hashAlg [0] AlgorithmIdentifier{DIGEST-ALGORITHM, {...}} OPTIONAL, certId [1] CertId OPTIONAL, hashVal BIT STRING -- hashVal is calculated over the DER encoding of the -- self-signed certificate with the identifier certID. }
POPODecKeyChallContent ::= SEQUENCE OF Challenge -- One Challenge per encryption key certification request (in the -- same order as these requests appear in CertReqMessages).
Challenge ::= SEQUENCE { owf AlgorithmIdentifier{DIGEST-ALGORITHM, {...}} OPTIONAL, -- MUST be present in the first Challenge; MAY be omitted in -- any subsequent Challenge in POPODecKeyChallContent (if -- omitted, then the owf used in the immediately preceding -- Challenge is to be used). witness OCTET STRING, -- the result of applying the one-way function (owf) to a -- randomly-generated INTEGER, A. [Note that a different -- INTEGER MUST be used for each Challenge.] challenge OCTET STRING -- the encryption (under the public key for which the cert. -- request is being made) of Rand, where Rand is specified as -- Rand ::= SEQUENCE { -- int INTEGER, -- - the randomly-generated INTEGER A (above) -- sender GeneralName -- - the sender's name (as included in PKIHeader) -- } }
Hoffman & Schaad Informational [Page 48]
RFC 5912 New ASN.1 for PKIX June 2010
POPODecKeyRespContent ::= SEQUENCE OF INTEGER -- One INTEGER per encryption key certification request (in the -- same order as these requests appear in CertReqMessages). The -- retrieved INTEGER A (above) is returned to the sender of the -- corresponding Challenge.
CertRepMessage ::= SEQUENCE { caPubs [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate OPTIONAL, response SEQUENCE OF CertResponse }
CertResponse ::= SEQUENCE { certReqId INTEGER, -- to match this response with the corresponding request (a value -- of -1 is to be used if certReqId is not specified in the -- corresponding request) status PKIStatusInfo, certifiedKeyPair CertifiedKeyPair OPTIONAL, rspInfo OCTET STRING OPTIONAL -- analogous to the id-regInfo-utf8Pairs string defined -- for regInfo in CertReqMsg [RFC4211] }
CertifiedKeyPair ::= SEQUENCE { certOrEncCert CertOrEncCert, privateKey [0] EncryptedValue OPTIONAL, -- see [RFC4211] for comment on encoding publicationInfo [1] PKIPublicationInfo OPTIONAL }
RevDetails ::= SEQUENCE { certDetails CertTemplate, -- allows requester to specify as much as they can about -- the cert. for which revocation is requested -- (e.g., for cases in which serialNumber is not available) crlEntryDetails Extensions{{...}} OPTIONAL
Hoffman & Schaad Informational [Page 49]
RFC 5912 New ASN.1 for PKIX June 2010
-- requested crlEntryExtensions }
RevRepContent ::= SEQUENCE { status SEQUENCE SIZE (1..MAX) OF PKIStatusInfo, -- in same order as was sent in RevReqContent revCerts [0] SEQUENCE SIZE (1..MAX) OF CertId OPTIONAL, -- IDs for which revocation was requested -- (same order as status) crls [1] SEQUENCE SIZE (1..MAX) OF CertificateList OPTIONAL -- the resulting CRLs (there may be more than one) }
CAKeyUpdAnnContent ::= SEQUENCE { oldWithNew CMPCertificate, -- old pub signed with new priv newWithOld CMPCertificate, -- new pub signed with old priv newWithNew CMPCertificate -- new pub signed with new priv }
-- Example InfoTypeAndValue contents include, but are not limited -- to, the following (uncomment in this ASN.1 module and use as -- appropriate for a given environment):
-- May be sent by EE, RA, or CA (depending on message content). -- The OPTIONAL infoValue parameter of InfoTypeAndValue will -- typically be omitted for some of the examples given above. -- The receiver is free to ignore any contained OBJECT IDs that it -- does not recognize. If sent from EE to CA, the empty set -- indicates that the CA may send -- any/all information that it wishes.
GenRepContent ::= SEQUENCE OF InfoTypeAndValue -- Receiver MAY ignore any contained OIDs that it does not -- recognize.
CertStatus ::= SEQUENCE { certHash OCTET STRING, -- the hash of the certificate, using the same hash algorithm -- as is used to create and verify the certificate signature certReqId INTEGER, -- to match this confirmation with the corresponding req/rep statusInfo PKIStatusInfo OPTIONAL }
PollReqContent ::= SEQUENCE OF SEQUENCE { certReqId INTEGER }
PollRepContent ::= SEQUENCE OF SEQUENCE { certReqId INTEGER, checkAfter INTEGER, -- time in seconds reason PKIFreeText OPTIONAL }
OptionalValidity ::= SEQUENCE { notBefore [0] Time OPTIONAL, notAfter [1] Time OPTIONAL } -- at least one MUST be present
Controls ::= SEQUENCE SIZE(1..MAX) OF SingleAttribute {{RegControlSet}}
Hoffman & Schaad Informational [Page 54]
RFC 5912 New ASN.1 for PKIX June 2010
ProofOfPossession ::= CHOICE { raVerified [0] NULL, -- used if the RA has already verified that the requester is in -- possession of the private key signature [1] POPOSigningKey, keyEncipherment [2] POPOPrivKey, keyAgreement [3] POPOPrivKey }
POPOSigningKey ::= SEQUENCE { poposkInput [0] POPOSigningKeyInput OPTIONAL, algorithmIdentifier AlgorithmIdentifier{SIGNATURE-ALGORITHM, {SignatureAlgorithms}}, signature BIT STRING } -- The signature (using "algorithmIdentifier") is on the -- DER-encoded value of poposkInput. NOTE: If the CertReqMsg -- certReq CertTemplate contains the subject and publicKey values, -- then poposkInput MUST be omitted and the signature MUST be -- computed over the DER-encoded value of CertReqMsg certReq. If -- the CertReqMsg certReq CertTemplate does not contain both the -- public key and subject values (i.e., if it contains only one -- of these, or neither), then poposkInput MUST be present and -- MUST be signed.
POPOSigningKeyInput ::= SEQUENCE { authInfo CHOICE { sender [0] GeneralName, -- used only if an authenticated identity has been -- established for the sender (e.g., a DN from a -- previously-issued and currently-valid certificate) publicKeyMAC PKMACValue }, -- used if no authenticated GeneralName currently exists for -- the sender; publicKeyMAC contains a password-based MAC -- on the DER-encoded value of publicKey publicKey SubjectPublicKeyInfo } -- from CertTemplate
PKMACValue ::= SEQUENCE { algId AlgorithmIdentifier{MAC-ALGORITHM, {Password-MACAlgorithms}}, value BIT STRING }
-- -- Define the currently only acceptable MAC algorithm to be used -- for the PKMACValue structure --
Password-MACAlgorithms MAC-ALGORITHM ::= { {IDENTIFIER id-PasswordBasedMac PARAMS TYPE PBMParameter ARE required IS-KEYED-MAC TRUE }, ... }
PBMParameter ::= SEQUENCE { salt OCTET STRING, owf AlgorithmIdentifier{DIGEST-ALGORITHM, {DigestAlgorithms}}, -- AlgId for a One-Way Function (SHA-1 recommended) iterationCount INTEGER, -- number of times the OWF is applied mac AlgorithmIdentifier{MAC-ALGORITHM, {MACAlgorithms}} -- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC, or HMAC }
MACAlgorithms MAC-ALGORITHM ::= { -- The modules containing the ASN.1 for the DES and 3DES MAC -- algorithms have not been updated at the time that this is -- being published. Users of this module should define the -- appropriate MAC-ALGORITHM objects and uncomment the -- following lines if they support these MAC algorithms. -- maca-des-mac | maca-3des-mac -- maca-hMAC-SHA1, ... }
POPOPrivKey ::= CHOICE { thisMessage [0] BIT STRING, -- Deprecated -- possession is proven in this message (which contains -- the private key itself (encrypted for the CA)) subsequentMessage [1] SubsequentMessage, -- possession will be proven in a subsequent message dhMAC [2] BIT STRING, -- Deprecated agreeMAC [3] PKMACValue, encryptedKey [4] EnvelopedData } -- for keyAgreement (only), possession is proven in this message -- (which contains a MAC (over the DER-encoded value of the -- certReq parameter in CertReqMsg, which MUST include both -- subject and publicKey) based on a key derived from the end -- entity's private DH key and the CA's public DH key);
Hoffman & Schaad Informational [Page 56]
RFC 5912 New ASN.1 for PKIX June 2010
SubsequentMessage ::= INTEGER { encrCert (0), -- requests that resulting certificate be encrypted for the -- end entity (following which, POP will be proven in a -- confirmation message) challengeResp (1) } -- requests that CA engage in challenge-response exchange with -- end entity in order to prove private key possession
-- -- id-ct-encKeyWithID content type used as the content type for the -- EnvelopedData in POPOPrivKey. -- It contains both a private key and an identifier for key escrow -- agents to check against recovery requestors. --
ct-encKeyWithID CONTENT-TYPE ::= { EncKeyWithID IDENTIFIED BY id-ct-encKeyWithID }
PKIPublicationInfo ::= SEQUENCE { action INTEGER { dontPublish (0), pleasePublish (1) }, pubInfos SEQUENCE SIZE (1..MAX) OF SinglePubInfo OPTIONAL } -- pubInfos MUST NOT be present if action is "dontPublish" -- (if action is "pleasePublish" and pubInfos is omitted, -- "dontCare" is assumed)
PKIArchiveOptions ::= CHOICE { encryptedPrivKey [0] EncryptedKey, -- the actual value of the private key keyGenParameters [1] KeyGenParameters, -- parameters that allow the private key to be re-generated archiveRemGenPrivKey [2] BOOLEAN } -- set to TRUE if sender wishes receiver to archive the private -- key of a key pair that the receiver generates in response to -- this request; set to FALSE if no archive is desired.
EncryptedKey ::= CHOICE { encryptedValue EncryptedValue, -- Deprecated envelopedData [0] EnvelopedData } -- The encrypted private key MUST be placed in the envelopedData -- encryptedContentInfo encryptedContent OCTET STRING.
-- -- We skipped doing the full constraints here since this structure -- has been deprecated in favor of EnvelopedData --
EncryptedValue ::= SEQUENCE { intendedAlg [0] AlgorithmIdentifier{ALGORITHM, {...}} OPTIONAL, -- the intended algorithm for which the value will be used symmAlg [1] AlgorithmIdentifier{ALGORITHM, {...}} OPTIONAL, -- the symmetric algorithm used to encrypt the value encSymmKey [2] BIT STRING OPTIONAL, -- the (encrypted) symmetric key used to encrypt the value keyAlg [3] AlgorithmIdentifier{ALGORITHM, {...}} OPTIONAL, -- algorithm used to encrypt the symmetric key valueHint [4] OCTET STRING OPTIONAL, -- a brief description or identifier of the encValue content -- (may be meaningful only to the sending entity, and used only -- if EncryptedValue might be re-examined by the sending entity
Hoffman & Schaad Informational [Page 59]
RFC 5912 New ASN.1 for PKIX June 2010
-- in the future) encValue BIT STRING } -- the encrypted value itself -- When EncryptedValue is used to carry a private key (as opposed to -- a certificate), implementations MUST support the encValue field -- containing an encrypted PrivateKeyInfo as defined in [PKCS11], -- section 12.11. If encValue contains some other format/encoding -- for the private key, the first octet of valueHint MAY be used -- to indicate the format/encoding (but note that the possible values -- of this octet are not specified at this time). In all cases, the -- intendedAlg field MUST be used to indicate at least the OID of -- the intended algorithm of the private key, unless this information -- is known a priori to both sender and receiver by some other means.
KeyGenParameters ::= OCTET STRING
-- -- 6.5. OldCert ID Control --
regCtrl-oldCertID ATTRIBUTE ::= { TYPE OldCertId IDENTIFIED BY id-regCtrl-oldCertID }
ContentInfo FROM CryptographicMessageSyntax-2009 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-cms-2004-02(41) }; -- Define the set of extensions that can appear. -- Some of these are imported from PKIX Cert
AttributeCertificateInfo ::= SEQUENCE { version AttCertVersion, -- version is v2 holder Holder, issuer AttCertIssuer, signature AlgorithmIdentifier{SIGNATURE-ALGORITHM, {SignatureAlgorithms}}, serialNumber CertificateSerialNumber, attrCertValidityPeriod AttCertValidityPeriod, attributes SEQUENCE OF AttributeSet{{AttributesDefined}}, issuerUniqueID UniqueIdentifier OPTIONAL, extensions Extensions{{AttributeCertExtensions}} OPTIONAL }
AttCertVersion ::= INTEGER { v2(1) }
Holder ::= SEQUENCE { baseCertificateID [0] IssuerSerial OPTIONAL, -- the issuer and serial number of -- the holder's Public Key Certificate entityName [1] GeneralNames OPTIONAL, -- the name of the claimant or role objectDigestInfo [2] ObjectDigestInfo OPTIONAL -- used to directly authenticate the -- holder, for example, an executable }
ObjectDigestInfo ::= SEQUENCE { digestedObjectType ENUMERATED { publicKey (0), publicKeyCert (1), otherObjectTypes (2) }, -- otherObjectTypes MUST NOT -- be used in this profile otherObjectTypeID OBJECT IDENTIFIER OPTIONAL, digestAlgorithm AlgorithmIdentifier{DIGEST-ALGORITHM, {...}},
Hoffman & Schaad Informational [Page 88]
RFC 5912 New ASN.1 for PKIX June 2010
objectDigest BIT STRING }
AttCertIssuer ::= CHOICE { v1Form GeneralNames, -- MUST NOT be used in this -- profile v2Form [0] V2Form -- v2 only }
V2Form ::= SEQUENCE { issuerName GeneralNames OPTIONAL, baseCertificateID [0] IssuerSerial OPTIONAL, objectDigestInfo [1] ObjectDigestInfo OPTIONAL -- issuerName MUST be present in this profile -- baseCertificateID and objectDigestInfo MUST -- NOT be present in this profile }
-- attribute data types AttributeType ::= ATTRIBUTE.&id
-- Replaced by SingleAttribute{} -- -- AttributeTypeAndValue ::= SEQUENCE { -- type ATTRIBUTE.&id({SupportedAttributes}), -- value ATTRIBUTE.&Type({SupportedAttributes}{@type}) } --
-- Suggested naming attributes: Definition of the following -- information object set may be augmented to meet local -- requirements. Note that deleting members of the set may -- prevent interoperability with conforming implementations. -- All attributes are presented in pairs: the AttributeType -- followed by the type definition for the corresponding -- AttributeValue.
TBSCertList ::= SEQUENCE { version Version OPTIONAL, -- if present, MUST be v2 signature AlgorithmIdentifier{SIGNATURE-ALGORITHM, {SignatureAlgorithms}}, issuer Name, thisUpdate Time, nextUpdate Time OPTIONAL, revokedCertificates SEQUENCE SIZE (1..MAX) OF SEQUENCE { userCertificate CertificateSerialNumber, revocationDate Time, ... , [[2: -- if present, version MUST be v2
Hoffman & Schaad Informational [Page 97]
RFC 5912 New ASN.1 for PKIX June 2010
crlEntryExtensions Extensions{{CrlEntryExtensions}} OPTIONAL ]], ... } OPTIONAL, ... , [[2: -- if present, version MUST be v2 crlExtensions [0] Extensions{{CrlExtensions}} OPTIONAL ]], ... }
-- Version, Time, CertificateSerialNumber, and Extensions were -- defined earlier for use in the certificate structure
-- -- The two object sets below should be expanded to include -- those algorithms which are supported by the system. -- -- For example: -- SignatureAlgorithms SIGNATURE-ALGORITHM ::= { -- PKIXAlgs-2008.SignatureAlgs, ..., -- - - RFC 3279 provides the base set -- PKIX1-PSS-OAEP-ALGORITHMS.SignatureAlgs | -- - - RFC 4055 provides extension algs -- OtherModule.SignatureAlgs -- - - RFC XXXX provides additional extension algs -- }
-- Note - upper bounds on string types, such as TeletexString, are -- measured in characters. Excepting PrintableString or IA5String, a -- significantly greater number of octets will be required to hold -- such a value. As a minimum, 16 octets or twice the specified -- upper bound, whichever is the larger, should be allowed for -- TeletexString. For UTF8String or UniversalString, at least four -- times the upper bound should be allowed.
-- Information object classes used in the definition -- of certificates and CRLs
-- Parameterized Type SIGNED -- -- Three different versions of doing SIGNED: -- 1. Simple and close to the previous version -- -- SIGNED{ToBeSigned} ::= SEQUENCE { -- toBeSigned ToBeSigned, -- algorithm AlgorithmIdentifier{SIGNATURE-ALGORITHM, -- {SignatureAlgorithms}}, -- signature BIT STRING -- }
-- 2. From Authenticated Framework -- -- SIGNED{ToBeSigned} ::= SEQUENCE { -- toBeSigned ToBeSigned, -- COMPONENTS OF SIGNATURE{ToBeSigned} -- } -- SIGNATURE{ToBeSigned} ::= SEQUENCE { -- algorithmIdentifier AlgorithmIdentifier, -- encrypted ENCRYPTED-HASH{ToBeSigned} -- } -- ENCRYPTED-HASH{ToBeSigned} ::= -- BIT STRING -- (CONSTRAINED BY { -- shall be the result of applying a hashing procedure to -- the DER-encoded (see 4.1) octets of a value of -- ToBeSigned and then applying an encipherment procedure -- to those octets -- }) -- -- -- 3. A more complex version, but one that automatically ties -- together both the signature algorithm and the -- signature value for automatic decoding. -- SIGNED{ToBeSigned} ::= SEQUENCE {
-- name constraints extension OID and syntax ext-NameConstraints EXTENSION ::= { SYNTAX NameConstraints IDENTIFIED BY id-ce-nameConstraints } id-ce-nameConstraints OBJECT IDENTIFIER ::= { id-ce 30 }
NameConstraints ::= SEQUENCE { permittedSubtrees [0] GeneralSubtrees OPTIONAL, excludedSubtrees [1] GeneralSubtrees OPTIONAL } -- -- This is a constraint in the issued certificates by CAs, but is -- not a requirement on EEs. -- -- (WITH COMPONENTS { ..., permittedSubtrees PRESENT} | -- WITH COMPONENTS { ..., excludedSubtrees PRESENT }}
GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree
GeneralSubtree ::= SEQUENCE { base GeneralName, minimum [0] BaseDistance DEFAULT 0, maximum [1] BaseDistance OPTIONAL }
PolicyConstraints ::= SEQUENCE { requireExplicitPolicy [0] SkipCerts OPTIONAL, inhibitPolicyMapping [1] SkipCerts OPTIONAL } -- -- This is a constraint in the issued certificates by CAs, -- but is not a requirement for EEs -- -- (WITH COMPONENTS { ..., requireExplicitPolicy PRESENT} | -- WITH COMPONENTS { ..., inhibitPolicyMapping PRESENT})
SkipCerts ::= INTEGER (0..MAX)
Hoffman & Schaad Informational [Page 105]
RFC 5912 New ASN.1 for PKIX June 2010
-- CRL distribution points extension OID and syntax
DistributionPoint ::= SEQUENCE { distributionPoint [0] DistributionPointName OPTIONAL, reasons [1] ReasonFlags OPTIONAL, cRLIssuer [2] GeneralNames OPTIONAL } -- -- This is not a requirement in the text, but it seems as if it -- should be -- --(WITH COMPONENTS {..., distributionPoint PRESENT} | -- WITH COMPONENTS {..., cRLIssuer PRESENT})
-- Note - upper bounds on string types, such as TeletexString, are -- measured in characters. Excepting PrintableString or IA5String, a -- significantly greater number of octets will be required to hold -- such a value. As a minimum, 16 octets or twice the specified -- upper bound, whichever is the larger, should be allowed for -- TeletexString. For UTF8String or UniversalString, at least four -- times the upper bound should be allowed.
Even though all the RFCs in this document are security-related, the document itself does not have any security considerations. The ASN.1 modules keep the same bits-on-the-wire as the modules that they replace.
[ASN1-2002] ITU-T, "ITU-T Recommendation X.680, X.681, X.682, and X.683", ITU-T X.680, X.681, X.682, and X.683, 2002.
[RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 2560, June 1999.
[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification Request Syntax Specification Version 1.7", RFC 2986, November 2000.
[RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279, April 2002.
[RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
[RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 4055, June 2005.
[RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, "Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP)", RFC 4210, September 2005.
[RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)", RFC 4211, September 2005.
[RFC5055] Freeman, T., Housley, R., Malpani, A., Cooper, D., and W. Polk, "Server-Based Certificate Validation Protocol (SCVP)", RFC 5055, December 2007.
[RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS (CMC)", RFC 5272, June 2008.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
Hoffman & Schaad Informational [Page 116]
RFC 5912 New ASN.1 for PKIX June 2010
[RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, "Elliptic Curve Cryptography Subject Public Key Information", RFC 5480, March 2009.
[RFC5755] Farrell, S., Housley, R., and S. Turner, "An Internet Attribute Certificate Profile for Authorization", RFC 5755, January 2010.
[RFC5911] Hoffman, P. and J. Schaad, "New ASN.1 Modules for Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911, June 2010.
Authors' Addresses
Paul Hoffman VPN Consortium 127 Segre Place Santa Cruz, CA 95060 US