pkcs9

PKCS #9 v2.0: Selected Object Classes and Attribute Types PKCS #9 v2.0: Selected Object Classes and Attribute Types RSA Laboratories February 25, 2000 Table of Contents TOC \o "1-1" \t "Heading 2,2,Appendix 2,2" 1. Introduction 2 2. Definitions, notation and document conventions 2 2.1 Definitions 2 2.2 Notation and document conventions 3 3. Overview 3 4. Auxiliary object classes 4 4.1 The pkcsEntity auxiliary object class 4 4.2 The naturalPerson auxiliary object class 4 5. Selected attribute types 5 5.1 Attribute types for use with the “pkcsEntity” object class 5 5.2 Attribute types for use with the “naturalPerson” object class 6 5.3 Attribute types for use in PKCS #7 data 10 5.4 Attribute types for use with PKCS #10 certificate requests 14 5.5 Attributes for use in PKCS #12 “PFX” PDUs or PKCS #15 tokens 15 5.6 Attributes defined in S/MIME 16 6. Matching rules 17 6.1 Case ignore match 17 6.2 Signing time match 17 A. ASN.1 module 19 B. BNF schema summary 26 B.1 Syntaxes 26 B.2 Object Classes 27 B.3 Attribute types 27 B.4 Matching rules 31 C. Intellectual property considerations 31 D. Revision history 32 E. References 33 F. About PKCS 34 1.​ Introduction This document defines two new auxiliary object classes, pkcsEntity and naturalPerson, and selected attribute types for use with these classes. It also defines some attribute types for use in conjunction with PKCS #7 [14] (and S/MIME CMS [3]) digitally signed messages, PKCS #10 [16] certificate-signing requests, PKCS #12 [17] personal information exchanges and PKCS #15 [18] cryptographic tokens. Matching rules for use with these attributes are also defined, whenever necessary. 2.​ Definitions, notation and document conventions 2.1​ Definitions For the purposes of this document, the following definitions apply. ASN.1 Abstract Syntax Notation One, as defined in [5]. Attributes An ASN.1 type that specifies a set of attributes. Each attribute contains an attribute type (specified by object identifier) and one or more attribute values. Some attribute types are restricted in their definition to have a single value; others may have multiple values. This type is defined in [7]. CertificationRequestInfo An ASN.1 type that specifies a subject name, a public key, and a set of attributes. This type is defined in [16]. ContentInfo An ASN.1 type that specifies content exchanged between entities. The contentType field, which has type OBJECT IDENTIFIER, specifies the content type, and the content field, whose type is defined by the contentType field, contains the content value. This type is defined in [14] and [3]. PrivateKeyInfo A type that specifies a private key and a set of extended attributes. This type and the associated EncryptedPrivateKeyInfo type are defined in [15]. SignerInfo A type that specifies per-signer information in the signed-data content type, including a set of attributes authenticated by the signer, and a set of attributes not authenticated by the signer. This type is defined in [14] and [3]. DER Distinguished Encoding Rules for ASN.1, as defined in [6]. UCS Universal Multiple-Octet Coded Character Set, as defined in [11]. UTF8String UCS Transformation Format encoded string. The UTF-8 encoding is defined in [11]. 2.2​ Notation and document conventions In this document, all ASN.1 types and values are written in bold Helvetica. Attribute type and object class definitions are written in the ASN.1 value notation defined in [5]. Appendix B contains most of these definitions written in the augmented BNF notation defined in [2] as well. This has been done in an attempt to simplify the task of integrating this work into LDAP [22] development environments. The keywords “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [1]. 3.​ Overview This document specifies two new auxiliary object classes, pkcsEntity and naturalPerson, and some new attribute types and matching rules. All ASN.1 object classes, attributes, matching rules and types are exported for use in other environments. Attribute types defined in this document that are useful in conjunction with storage of PKCS-related data and the pkcsEntity object class includes PKCS #12 PFX PDUs, PKCS #15 tokens and encrypted private keys. Attribute types defined in this document that are useful in conjunction with PKCS #10 certificate requests and the naturalPerson object class includes electronic-mail address, pseudonym, unstructured name, and unstructured address. Attribute types defined in this document that are useful in PKCS #7 digitally signed messages are content type, message digest, signing time, sequence number, random nonce and countersignature. The attributes would be used in the authenticatedAttributes and unauthenticatedAttributes fields of a SignerInfo or an AuthenticatedData ([3]) value. Attribute types that are useful especially in PKCS #10 certification requests are the challenge password and the extension-request attribute. The attributes would be used in the attributes field of a CertificationRequestInfo value. Note – The attributes types (from [8]) in Table 1, and probably several others, might also be helpful in PKCS #10, PKCS #12 and PKCS #15-aware applications. businessCategory preferredDeliveryMethod commonName presentationAddress countryName registeredAddress description roleOccupant destinationIndicator serialNumber facsimileTelephoneNumber stateOrProvinceName iSDNAddress streetAddress localityName supportedApplicationContext member surname objectClass telephoneNumber organizationName teletexTerminalIdentifier physicalDeliveryOfficeName telexNumber postalAddress title postalCode x121Address postOfficeBox Table 1: ISO/IEC 9594-6 attribute types useful in PKCS documents 4.​ Auxiliary object classes This document defines two new auxiliary object classes: pkcsEntity and naturalPerson. 4.1​ The pkcsEntity auxiliary object class The pkcsEntity object class is a general-purpose auxiliary object class that is intended to hold attributes about PKCS-related entities. It has been designed for use within directory services based on the LDAP protocol [22] and the X.500 family of protocols, where support for PKCS-defined attributes is considered useful. pkcsEntity OBJECT-CLASS ::= { SUBCLASS OF { top } KIND auxiliary MAY CONTAIN { PKCSEntityAttributeSet } ID pkcs-9-oc-pkcsEntity } PKCSEntityAttributeSet ATTRIBUTE ::= { pKCS7PDU | userPKCS12 | pKCS15Token | encryptedPrivateKeyInfo, ... -- For future extensions } Attributes in the PKCSEntityAttributeSet are defined in Section 5. 4.2​ The naturalPerson auxiliary object class The naturalPerson object class is a general-purpose auxiliary object class that is intended to hold attributes about human beings. It has been designed for use within directory services based on the LDAP protocol [22] and the X.500 family of protocols, where support for these attributes is considered useful. naturalPerson OBJECT-CLASS ::= { SUBCLASS OF { top } KIND auxilary MAY CONTAIN { NaturalPersonAttributeSet } ID pkcs-9-oc-naturalPerson } NaturalPersonAttributeSet ATTRIBUTE ::= { emailAddress | unstructuredName | unstructuredAddress | dateOfBirth | placeOfBirth | gender | countryOfCitizenship | countryOfResidence | pseudonym | serialNumber, ... -- For future extensions } Attributes in the NaturalPersonAttributeSet are defined in Section 5. 5.​ Selected attribute types 5.1​ Attribute types for use with the “pkcsEntity” object class 5.1.1​ PKCS #7 PDU PKCS #7 provides several formats for enveloped, signed and otherwise protected data. When such information is stored in a directory service, the pKCS7PDU attribute may be used. pKCS7PDU ATTRIBUTE ::= { WITH SYNTAX ContentInfo ID pkcs-9-at-pkcs7PDU } 5.1.2​ PKCS #12 token PKCS #12 provides a format for exchange of personal identity information. When such information is stored in a directory service, the userPKCS12 attribute should be used. userPKCS12 ATTRIBUTE ::= { WITH SYNTAX PFX ID pkcs-9-at-userPKCS12 } This type was originally defined in [20]. 5.1.3​ PKCS #15 token PKCS #15 provides a format for cryptographic tokens. When software variants of such tokens are stored in a directory service, the pKCS15Token attribute should be used. pKCS15Token ATTRIBUTE ::= { WITH SYNTAX PKCS15Token ID pkcs-9-at-pkcs15Token } 5.1.4​ PKCS #8 encrypted private key information PKCS #8 provides a format for encrypted private keys. When such information is stored in a directory service, the encryptedPrivateKeyInfo attribute should be used. encryptedPrivateKeyInfo ATTRIBUTE ::= { WITH SYNTAX EncryptedPrivateKeyInfo ID pkcs-9-at-encryptedPrivateKeyInfo } 5.2​ Attribute types for use with the “naturalPerson” object class1 5.2.1​ Electronic-mail address The emailAddress attribute type specifies the electronic-mail address or addresses of a subject as an unstructured ASCII string. The interpretation of electronic-mail addresses is intended to be specified by certificate issuers etc.; no particular interpretation is required. emailAddress ATTRIBUTE ::= { WITH SYNTAX IA5String (SIZE(1..pkcs-9-ub-emailAddress)) EQUALITY MATCHING RULE pkcs9CaseIgnoreMatch ID pkcs-9-at-emailAdress } An electronic-mail address attribute can have multiple attribute values. When comparing two email addresses, case is irrelevant. The pkcs9CaseIgnoreMatch is defined in Section 6. Note – It is likely that other standards bodies overseeing electronic-mail systems will, or have, registered electronic-mail address attribute types specific to their system. The electronic-mail address attribute type defined here was intended as a short-term substitute for those specific attribute types, but is included here for backwards-compatibility reasons. 5.2.2​ Unstructured name The unstructuredName attribute type specifies the name or names of a subject as an unstructured ASCII string. The interpretation of unstructured names is intended to be specified by certificate issuers etc.; no particular interpretation is required. unstructuredName ATTRIBUTE ::= { WITH SYNTAX PKCS9String {pkcs-9-ub-unstructuredName} EQUALITY MATCHING RULE pkcs9CaseIgnoreMatch ID pkcs-9-at-unstructuredName } PKCS9String { INTEGER : maxSize} ::= CHOICE { ia5String IA5String (SIZE(1..maxSize)), directoryString DirectoryString {maxSize} } An unstructured-name attribute can have multiple attribute values. When comparing two unstructured names, case is irrelevant. The PKCS9String type is defined as a choice of IA5String and DirectoryString. Applications SHOULD use the IA5String type when generating attribute values in accordance with this version of this document, unless internationalization issues makes this impossible. In that case, the UTF8String alternative of the DirectoryString alternative is the preferred choice. PKCS #9-attribute processing systems MUST be able to recognize and process all string types in PKCS9String values. Note – Version 1.1 of this document defined unstructuredName as having the syntax IA5String, but did contain a note explaining that this might be changed to a CHOICE of different string types in future versions. To better accommodate international names, this type has been extended to also include a directory string in this version of this document. Since [21] does not support a directory string type containing IA5Strings, a separate syntax object identifier has been defined (see [21] and Appendix B). 5.2.3​ Unstructured address The unstructuredAddress attribute type specifies the address or addresses of a subject as an unstructured directory string. The interpretation of unstructured addresses is intended to be specified by certificate issuers etc; no particular interpretation is required. A likely interpretation is as an alternative to the postalAddress attribute type defined in [8]. unstructuredAddress ATTRIBUTE ::= { WITH SYNTAX DirectoryString {pkcs-9-ub-unstructuredAddress} EQUALITY MATCHING RULE caseIgnoreMatch ID pkcs-9-at-unstructuredAddress } An unstructured-address attribute can have multiple attribute values. The caseIgnoreMatch matching rule is defined in [8]. Note 1 – It is recommended to use the ASN.1 type TeletexString’s new-line character (hexadecimal code 0d) as a line separator in multi-line addresses. Note 2 – Previous versions of this document defined unstructuredAddress as having the following syntax: CHOICE { teletexString TeletexString, printableString PrintableString, } But also mentioned the possibility of a future definition as follows: CHOICE { teletexString TeletexString, printableString PrintableString, universalString UniversalString } In this version of this document, the X.520 type DirectoryString has been used in order to be more aligned with international standards and current practice. When generating attribute values in accordance with this version of this document, applications SHOULD use the PrintableString alternative unless internationalization issues makes this impossible. In those cases, the UTF8String alternative SHOULD be used. PKCS #9-attribute processing systems MUST be able to recognize and process all string types in DirectoryString values. 5.2.4​ Date of birth The dateOfBirth attribute specifies the date of birth for the subject it is associated with. dateOfBirth ATTRIBUTE ::= { WITH SYNTAX GeneralizedTime EQUALITY MATCHING RULE generalizedTimeMatch SINGLE VALUE TRUE ID pkcs-9-at-dateOfBirth } dateOfBirth attributes must be single-valued. The generalizedTimeMatch matching rule is defined in [8]. 5.2.5​ Place of birth The placeOfBirth attribute specifies the place of birth for the subject it is associated with. placeOfBirth ATTRIBUTE ::= { WITH SYNTAX DirectoryString {pkcs-9-ub-placeOfBirth} EQUALITY MATCHING RULE caseExactMatch SINGLE VALUE TRUE ID pkcs-9-at-placeOfBirth } placeOfBirth attributes must be single-valued. The caseExactMatch matching rule is defined in [8]. 5.2.6​ Gender The gender attribute specifies the gender of the subject it is associated with. gender ATTRIBUTE ::= { WITH SYNTAX PrintableString (SIZE(1) ^ FROM (“M” | ”F” | “m” | “f”)) EQUALITY MATCHING RULE caseIgnoreMatch SINGLE VALUE TRUE ID pkcs-9-at-gender } The letter “M” (or “m”) represents “male” and the letter “F” (or “f”) represents “female”. gender attributes must be single-valued. 5.2.7​ Country of citizenship The countryOfCitizenship attribute specifies the (claimed) countries of citizenship for the subject it is associated with. It SHALL be a 2-letter acronym of a country in accordance with [4]. countryOfCitizenship ATTRIBUTE ::= { WITH SYNTAX PrintableString (SIZE(2) ^ CONSTRAINED BY { -- Must be a two-letter country acronym in accordance with ISO/IEC 3166 --}) EQUALITY MATCHING RULE caseIgnoreMatch ID pkcs-9-at-countryOfCitizenship } Attributes of this type need not be single-valued. 5.2.8​ Country of residence The countryOfResidence attribute specifies the (claimed) country of residence for the subject is associated with. It SHALL be a 2-letter acronym of a country in accordance with [4]. countryOfResidence ATTRIBUTE ::= { WITH SYNTAX PrintableString (SIZE(2) ^ CONSTRAINED BY { -- Must be a two-letter country acronym in accordance with ISO/IEC 3166 --}) EQUALITY MATCHING RULE caseIgnoreMatch ID pkcs-9-at-countryOfResidence } Attributes of this type need not be single-valued, since it is possible to be a resident of several countries. 5.2.9​ Pseudonym The pseudonym attribute type shall contain a pseudonym of a subject. The exact interpretation of pseudonyms is intended to be specified by certificate issuers etc.; no particular interpretation is required. pseudonym ATTRIBUTE ::= { WITH SYNTAX DirectoryString {pkcs-9-ub-pseudonym} EQUALITY MATCHING RULE caseExactMatch ID id-at-pseudonym } Note – The pseudonym attribute has received an object identifier in the joint-iso-itu-t object identifier tree. The caseExactMatch matching rule is defined in [8]. 5.2.10​ Serial number The serialNumber attribute is defined in [8]. 5.3​ Attribute types for use in PKCS #7 data 5.3.1​ Content type The contentType attribute type specifies the content type of the ContentInfo value being signed in PKCS #7 (or S/MIME CMS) digitally signed data. In such data, the contentType attribute type is required if there are any PKCS #7 authenticated attributes. contentType ATTRIBUTE ::= { WITH SYNTAX ContentType EQUALITY MATCHING RULE objectIdentifierMatch SINGLE VALUE TRUE ID pkcs-9-at-contentType } ContentType ::= OBJECT IDENTIFIER As indicated, content-type attributes must have a single attribute value. For two content-type values to match, their octet string representation must be of equal length and corresponding octets identical. The objectIdentifierMatch matching rule is defined in [7]. Note – This attribute type is described in [3] as well. 5.3.2​ Message digest The messageDigest attribute type specifies the message digest of the contents octets of the DER-encoding of the content field of the ContentInfo value being signed in PKCS #7 digitally signed data, where the message digest is computed under the signer’s message digest algorithm. The message-digest attribute type is required in these cases if there are any PKCS #7 authenticated attributes present. messageDigest ATTRIBUTE ::= { WITH SYNTAX MessageDigest EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID pkcs-9-at-messageDigest } MessageDigest ::= OCTET STRING As indicated, a message-digest attribute must have a single attribute value. For two messageDigest values to match, their octet string representation must be of equal length and corresponding octets identical. The octetStringMatch matching rule is defined in [8]. Note – This attribute is described in [3] as well. 5.3.3​ Signing time The signingTime attribute type is intended for PKCS #7 digitally signed data. It specifies the time at which the signer (purportedly) performed the signing process. signingTime ATTRIBUTE ::= { WITH SYNTAX SigningTime EQUALITY MATCHING RULE signingTimeMatch SINGLE VALUE TRUE ID pkcs-9-at-signingTime } SigningTime ::= Time -- imported from ISO/IEC 9594-8 A signing-time attribute must have a single attribute value The signingTimeMatch matching rule (defined in Section 6.1) returns TRUE if an attribute value represents the same time as a presented value. Quoting from [3]: “Dates between 1 January 1950 and 31 December 2049 (inclusive) MUST be encoded as UTCTime. Any dates with year values before 1950 or after 2049 MUST be encoded as GeneralizedTime. [Further,] UTCTime values MUST be expressed in Greenwich Mean Time (Zulu) and MUST include seconds (i.e., times are YYMMDDHHMMSSZ), even where the number of seconds is zero. Midnight (GMT) must be represented as “YYMMDD000000Z”. Century information is implicit, and the century shall be determined as follows: ​ Where YY is greater than or equal to 50, the year shall be interpreted as 19YY; and ​ Where YY is less than 50, the year shall be interpreted as 20YY. GeneralizedTime values shall be expressed in Greenwich Mean Time (Zulu) and must include seconds (i.e., times are YYYYMMDDHHMMSSZ), even where the number of seconds is zero. GeneralizedTime values must not include fractional seconds.” Note 1 – The definition of SigningTime matches the definition of Time specified in [10]. Note 2 – No requirement is imposed concerning the correctness of the signing time, and acceptance of a purported signing time is a matter of a recipient’s discretion. It is expected, however, that some signers, such as time-stamp servers, will be trusted implicitly. 5.3.4​ Random nonce The randomNonce attribute type is intended for PKCS #7 digitally signed data. It may be used by a signer unable (or unwilling) to specify the time at which the signing process was performed. Used in a correct manner, it will make it possible for the signer to protect against certain attacks, i.e. replay attacks. randomNonce ATTRIBUTE ::= { WITH SYNTAX RandomNonce EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID pkcs-9-at-randomNonce } Ra