PKCS #9: Selected Attribute Types

An RSA Laboratories Technical Note
Version 2.0

1st draft version, May 21, 1999.

Editor's note: This is a first draft version of PKCS #9 v2 which is
available for a 30-day public review. Please send comments and
questions, both editorial and technical, to pkcs-editor@rsa.com or
pkcs-tng@rsa.com.

Copyright (C) 1991-1999 RSA Laboratories, a division of RSA
Data Security, Inc. License to copy this document is granted
provided that it is identified as "RSA Data Security, Inc.
Public-Key Cryptography Standards (PKCS)" in all material
mentioning or referencing this document.

003-903024-110-000-000


1. Introduction

This standard defines an auxiliary object class, "pkcsEntity", and
selected attribute types for use with this class. It also defines some
attribute types for use in conjunction with PKCS #7 (and S/MIME CMS)
digitally signed messages, PKCS #10 certificate-signing requests, 
PKCS #12 personal information exchanges and PKCS #15 cryptographic
tokens.


2. Definitions

For the purposes of this standard, the following definitions
apply.

ASN.1: Abstract Syntax Notation One, as defined in X.680.

Attributes: A 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 X.501.

CertificationRequestInfo: A type that specifies a subject
name, a public key, and a set of attributes. This type is
defined in PKCS #10.

ContentInfo: A 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 PKCS #7 and IETF RFC
[Housley].

PrivateKeyInfo: A type that specifies a private key and a
set of extended attributes. This type is defined in PKCS #8.

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 PKCS #7 and IETF
RFC [Housley].

DER: Distinguished Encoding Rules for ASN.1, as defined in
X.690.

UCS: Universal Multiple-Octet Coded Character Set, as
defined in ISO/IEC 10646-1.

UTF8String: UCS Transformation Format encoded string. The UTF-8
encoding is defined in ISO 10646-1.


3. Notation

The attribute type and object class definitions in this document are
written in the ASN.1 value notation defined in X.680. Appendix B
contains the most of these definitions written in the BNF notation defined in
IETF RFC 2252. This has been done in an attempt to simplify the task
of integrating this work into LDAP development environments.

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 IETF RFC 2119.


4. Overview

This document specifies a new auxiliary object class, "pkcsEntity",
and some new attribute types. All ASN.1 classes, attributes and types
are exported for use in other environments.

Attribute types defined in this document that are useful in
conjunction with PKCS #10 certificate requests and the "pkcsEntity"
object class includes electronic-mail address, 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, and countersignature. The attributes would be used in the
authenticatedAttributes and unauthenticatedAttributes fields of a
SignerInfo value.

Attribute types that are useful especially in PKCS #10 certification
requests are the challenge password and the extended- certificate
attribute. The attributes would be used in the attributes field of a
CertificationRequestInfo value.

Note: 
      The X.520 attributes types in Table 1, and probably several
      others, might also be helpful in PKCS #10, PKCS #12 and PKCS
      #15-using 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. X.520 attribute types useful in PKCS documents


5. Auxiliary object classes

This standard defines one new auxiliary object class: pkcsEntity.


5.1 The pkcsEntity auxiliary object class

The pkcsEntity object class is a general purpose auxiliary object
class that is intended to hold attributes about people. It is designed
to be used within directory services based on the LDAP [RFC2251] 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	{ PKCS9AttributeSet }
	ID		pkcs-9-oc-pkcsEntity
}

PKCS9AttributeSet ATTRIBUTE ::= {
	userPKCS12 |
	pKCS15Token |
	encryptedPrivateKeyInfo |
	emailAddress |
	unstructuredName |
	unstructuredAddress,
	... -- For future extensions
}

Attributes in the 'PKCS9AttributeSet' is defined in Section 7.


6. Attribute types


6.1 Attribute types for use in PKCS #7 data and the pkcsEntity object
    class 


6.1.1 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 IETF RFC [Smith].


6.1.2 PKCS #15 Token

PKCS #15 provides a format for cryptographic tokens. When such tokens
are stored in a directory service, the pKCS15Token attribute should be
used.

pKCS15Token ATTRIBUTE ::= {
	WITH SYNTAX PKCS15Token
	ID pkcs-9-at-pkcs15Token
}


6.1.3 PKCS #8 Encrypted Private Key Information

PKCS #8 provides a format for encrypted private keys. When values of
this type are stored in a directory service, the
encryptedPrivateKeyInfo attribute should be used.

encryptedPrivateKeyInfo ATTRIBUTE ::= {
	WITH SYNTAX EncryptedPrivateKeyInfo
	ID pkcs-9-at-encryptedPrivateKeyInfo
}


6.1.4 Electronic-mail Address

The electronic-mail address attribute type specifies the
electronic-mail address or addresses of the subject of a certificate
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. The electronic-mail address
attribute type is intended for use in conjunction with certificates
and the 'pkcsEntity' object class.

emailAddress ATTRIBUTE ::= {
	WITH SYNTAX IA5String
	EQUALITY MATCHING RULE caseIgnoreMatch
	ID pkcs-9-at-emailAdress
}

An electronic-mail address attribute can have multiple attribute
values. When comparing two email addresses, case is irrelevant.

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.


6.1.5 Unstructured Name

The unstructured-name attribute type specifies the name or names of
the subject of a certificate as an unstructured ASCII string. The
interpretation of the names is intended to be specified by the issuer
of the certificate; no particular interpretation is required. The
unstructured-name attribute type is intended for use in certificates.

unstructuredName ATTRIBUTE ::= {
	WITH SYNTAX PKCS9String
	EQUALITY MATCHING RULE caseIgnoreMatch
	ID pkcs-9-at-unstructuredName
}

PKCS9String ::= CHOICE {
	ia5String	IA5String,
        directoryString	DirectoryString {pkcs-9-ub-pkcs9String}
}

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. The UTF8String alternative of the DirectoryString
alternative is the preferred choice, and atttribute values generated
in accordance with this version of this standard SHOULD use the
UTF8String encoding. Attribute-processing systems MUST be able to
recognize and process all string types in PKCS9String values.

Note: 
      Version 1.2 of this standard 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. In order to better accomodate international
      names, this type has been extended to also include a directory
      string in this version of this standard. Since [RFC2252] does
      not support a directory string type containing IA5Strings, a
      separate syntax object identifier has been defined.


6.1.6 Unstructured address

The unstructured-address attribute type specifies the address or
addresses of the subject of a certificate as an unstructured directory
string. The interpretation of the addresses is intended to be
specified by the issuer of the certificate; no particular
interpretation is required. A likely interpretation is as an
alternative to the X.520 postalAddress attribute type.

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.

Notes:
	1. T.61's newline character (hexadecimal code 0d) is
	   recommended as a line separator in multi-line addresses.

	2. Previous versions of this standard defined
           unstructuredAddress as having the 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 if this standard, the X.520 type
	   DirectoryString has been used in order to be more aligned
	   with international standards and current practice. Within a
	   DirectoryString, the UTF8String is the preferred choice,
	   and atttribute values generated in accordance with this
	   version of this standard SHOULD use the UTF8String
	   encoding. Attribute-processing systems MUST be able to
	   recognize and process all string types in DirectoryString
	   values.


6.2 Attributes for use in PKCS #7 data


6.2.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 octetStringMatch
	SINGLE VALUE TRUE
	ID pkcs-9-at-contentType
}

ContentType ::= OCTET STRING

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.

Note: 
      This attribute type is described in IETF RFC [Housley] as well.


6.2.2 Message digest

The message-digest 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
	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.

Note:
       This attribute has also been described in IETF RFC [Housley].


6.2.3 Signing time

The signing-time attribute type specifies the time at which the signer
(purportedly) performed the signing process. The signing-time
attribute type is intended for PKCS #7 digitally signed data.

signingTime ATTRIBUTE ::= {
	WITH SYNTAX SigningTime
	EQUALITY MATCHING RULE uTCTimeMatch
	SINGLE VALUE TRUE
	ID pkcs-9-at-signingTime
}

SigningTime ::= UTCTime

A signing-time attribute must have a single attribute value.

The 'uTCTimeMatch' matching rule (defined in X.520) returns TRUE if an
attribute value represents the same time as a presented value. If a
UTC time is specified with the seconds absent, the number of seconds
is assumed to be zero.

Note:
      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.


6.2.4 Countersignature

The countersignature attribute type specifies one or more signatures
on the contents octets of the DER encoding of the encryptedDigest
field of a SignerInfo value in PKCS #7 digitally signed data. Thus,
the countersignature attribute type countersigns (signs in serial)
another signature. The countersignature attribute must be an
unauthenticated PKCS #7 attribute; it cannot be an authenticated
attribute.

counterSignature ATTRIBUTE ::= {
	WITH SYNTAX SignerInfo
	ID pkcs-9-at-counterSignature
}

Countersignature values have the same meaning as SignerInfo values for
ordinary signatures (see Section 9 of PKCS #7 v1.5 and Section 5.3 of
IETF RFC [Housley]), except that:

     	1. The authenticatedAttributes field must contain a
           message-digest attribute if it contains any other
           attributes, but need not contain a content-type attribute,
           as there is no content type for countersignatures.

     	2. The input to the message-digesting process is the contents
           octets of the DER encoding of the signatureValue field of
           the SignerInfo value with which the attribute is
           associated.

A countersignature attribute can have multiple attribute values.  

Notes:

	1. The fact that a countersignature is computed on a signature
	   (encrypted digest) means that the countersigning process
	   need not know the original content input to the signing
	   process. This has advantages both in efficiency and in
	   confidentiality.

	2. A countersignature, since it has type SignerInfo, can
           itself contain a countersignature attribute.  Thus it is
           possible to construct arbitrarily long series of
           countersignatures.


6.3 Attributes for use with PKCS #10 Certificate request


6.3.1 Challenge password

The challenge-password attribute type specifies a password by which an
entity may request certificate revocation. The interpretation of the
password is intended to be specified by the issuer of the certificate;
no particular interpretation is required.

challengePassword ATTRIBUTE ::= {
	WITH SYNTAX PKCS9String
	EQUALITY MATCHING RULE caseExactMatch
	SINGLE VALUE TRUE
	ID pkcs-9-at-challengePassword
}

A challenge-password attribute must have a single attribute value.

The UTF8String encoding is the preferred encoding, and atttribute
values generated in accordance with this version of this standard
SHOULD use the UTF8String encoding. Attribute-processing systems MUST
be able to recognize and process all string types in PKCS9String
values.

The 'caseExactMatch' matching rule is defined in X.520.

Note: 
      Version 1.2 of this standard defined challengePassword as having
      the syntax IA5String, but did contain a note explaining that
      this might be changed to a CHOICE of different string types in
      the future.


6.3.2 Extension request

This attribute may be used to carry information about certificate extensions
the requester wishes to be included in a certificate.

extensionRequest ATTRIBUTE ::= {
        WITH SYNTAX ExtensionRequest
        SINGLE VALUE TRUE
        ID pkcs-9-at-extensionRequest
}

ExtensionRequest ::= SEQUENCE OF Extension

The extension request attribute was originally used in RSA DSI's TIPEM
product.


6.3.3 Extended-certificate attributes (deprecated)

The extended-certificate-attributes attribute type specified a set of
attributes for a PKCS #6 extended certificate in a PKCS #10
certification request (the value of the extended
certificate-attributes attribute would become the extension in the
requested PKCS #6 extended certificate). Since, after the introduction
of X.509 v3 certificates, the status of PKCS #6 is historic, the use
of this attribute is deprecated.

extendedCertificateAttributes ATTRIBUTE ::= {
        WITH SYNTAX SET OF Attribute
	SINGLE VALUE TRUE
	ID pkcs-9-at-extendedCertificateAttributes
}

An extended-certificate-attributes attribute must have a single
attribute value (that value is a set, which itself may contain
multiple values, but there must only be one set).


6.4 Attributes for use in PKCS #12 PFX PDUs or PKCS #15 tokens


6.4.1. The Friendly Name Attribute

The friendly name attributes carries a user-friendly name of the
object it belongs to. It is referenced in PKCS #12 v1.0.

friendlyName ATTRIBUTE ::= {
	WITH SYNTAX BMPString
	EQUALITY MATCHING RULE caseIgnoreMatch
	SINGLE VALUE TRUE
	ID pkcs-9-at-friendlyName
}

As indicated, friendlyName attributes must have a single attribute
value.


6.4.2 The Local Key Identifier Attribute

The local key identifier attribute carries an identifier for a
particular key. It is only to be used locally in applications. This
attribute is referenced in PKCS #12 v1.0.

localKeyId ATTRIBUTE ::= {
	WITH SYNTAX OCTET STRING
	EQUALITY MATCHING RULE octetStringMatch
	SINGLE VALUE TRUE
	ID pkcs-9-at-localKeyId
}

As indicated, friendlyName attributes must have a single attribute
value. For two friendlyName values to match, their octet string
representation must be of equal length and corresponding octets
identical.


6.5 Attributes defined in S/MIME

IETF RFC 2311 defines some attributes and object identifiers in the
PKCS #9 tree. For completeness, they are mentioned here.


6.5.1 Signing Description

This attribute was first mentioned in the document "S/MIME
Implementation Guide, Interoperability Profile, Version 1", published
on RSA Laboratoriew web pages in August, 1995. It was defined as an
attribute suitable for use in SignerInfo values.

signingDescription ATTRIBUTE ::= {
	WITH SYNTAX DirectoryString {pkcs-9-ub-signingDescription}
	EQUALITY MATCHING RULE caseIgnoreMatch
	SINGLE VALUE TRUE
	ID pkcs-9-at-signingDescription
}

The signingDescription attribute is intended to provide a short
synopsis of the message which can be used to present a user with an
additional confirmation step before committing to a cryptographic
operation.  In most cases, the replication of the Subject line from
the header of a message should be sufficient and is recommended.


6.5.2 S/MIME Capabilities

The syntax and semantics of the S/MIME capabilities attribute is
defined in IETF RFC 2311. It is included here for the sake of
completeness.

smimeCapabilities ATTRIBUTE ::= {
	WITH SYNTAX SMIMECapabilities
	SINGLE VALUE
	ID pkcs-9-at-symmetricCapabilities
}


A. ASN.1 Module

This appendix includes all of the ASN.1 type and value definitions
contained in this standard in the form of the ASN.1 module PKCS-9.

PKCS-9 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
modules(0) pkcs-9(1)}

-- This module has been checked for conformance with the ASN.1 standard
-- by the OSS ASN.1 Tools

DEFINITIONS IMPLICIT TAGS ::=

BEGIN

-- EXPORTS All --
-- All types and values defined in this module is exported for use in other
-- ASN.1 modules.

IMPORTS

informationFramework, authenticationFramework, selectedAttributeTypes
        FROM UsefulDefinitions {joint-iso-itu-t ds(5) module(1)
                                usefulDefinitions(0) 3} 

OBJECT-CLASS, ATTRIBUTE, Attribute, top
        FROM InformationFramework informationFramework

ALGORITHM, Extension
        FROM AuthenticationFramework authenticationFramework

DirectoryString, octetStringMatch, caseIgnoreMatch, caseExactMatch,
uTCTimeMatch 
        FROM SelectedAttributeTypes selectedAttributeTypes

IssuerAndSerialNumber, SignerInfo
        FROM CryptographicMessageSyntax {iso(1) member-body(2) us(840)
        rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1)}

EncryptedPrivateKeyInfo
	FROM PKCS-8 {iso(1) member-body(2) us(840) rsadsi(113549)
	pkcs(1) pkcs-8(8) modules(1) pkcs-8(1)}

PFX
	FROM PKCS-12 {iso(1) member-body(2) us(840) rsadsi(113549)
	pkcs(1) pkcs-12(12) modules(1) pkcs-12(1)}

PKCS15Token
	FROM PKCS-15 {iso(1) member-body(2) us(840) rsadsi(113549)
	pkcs(1) pkcs-15(15) modules(1) pkcs-15(1)};

-- Constants

pkcs-9-ub-pkcs9String		INTEGER ::= 255
pkcs-9-ub-unstructuredAddress	INTEGER ::= pkcs-9-ub-pkcs9String
pkcs-9-ub-signingDescription	INTEGER ::= pkcs-9-ub-pkcs9String

-- Object Identifiers

pkcs-9 OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840)
			      rsadsi(113549) pkcs(1) 9}

  -- Main arcs
pkcs-9-mo OBJECT IDENTIFIER ::= {pkcs-9 0} -- Modules branch
pkcs-9-oc OBJECT IDENTIFIER ::= {pkcs-9 24} -- Object class branch
pkcs-9-at OBJECT IDENTIFIER ::= {pkcs-9 25} -- Attribute branch, for new
				       -- attributes
pkcs-9-sx OBJECT IDENTIFIER ::= {pkcs-9 26} -- For syntaxes (RFC 2252)

  -- Object classes
pkcs-9-oc-pkcsEntity		OBJECT IDENTIFIER ::= { pkcs-9-oc 1}

  -- Attributes
pkcs-9-at-emailAddress		OBJECT IDENTIFIER ::= {pkcs-9 1}
pkcs-9-at-unstructuredName	OBJECT IDENTIFIER ::= {pkcs-9 2}
pkcs-9-at-contentType		OBJECT IDENTIFIER ::= {pkcs-9 3}
pkcs-9-at-messageDigest		OBJECT IDENTIFIER ::= {pkcs-9 4}
pkcs-9-at-signingTime		OBJECT IDENTIFIER ::= {pkcs-9 5}
pkcs-9-at-counterSignature	OBJECT IDENTIFIER ::= {pkcs-9 6}
pkcs-9-at-challengePassword	OBJECT IDENTIFIER ::= {pkcs-9 7}
pkcs-9-at-unstructuredAddress	OBJECT IDENTIFIER ::= {pkcs-9 8}
pkcs-9-at-extendedCertificateAttributes 
				OBJECT IDENTIFIER ::= {pkcs-9 9}

-- Obsolete (?) attribute identifiers, purportedly from "tentative
-- PKCS #9 draft"
-- pkcs-9-at-issuerAndSerialNumber OBJECT IDENTIFIER ::= {pkcs-9 10}
-- pkcs-9-at-passwordCheck	OBJECT IDENTIFIER ::= {pkcs-9 11}
-- pkcs-9-at-publicKey		OBJECT IDENTIFIER ::= {pkcs-9 12}

pkcs-9-at-signingDescription	OBJECT IDENTIFIER ::= {pkcs-9 13}
pkcs-9-at-extensionRequest	OBJECT IDENTIFIER ::= {pkcs-9 14}
pkcs-9-at-smimeCapabilities	OBJECT IDENTIFIER ::= {pkcs-9 15}

-- Unused (?)
-- pkcs-9-at-?		OBJECT IDENTIFIER ::= {pkcs-9 17}
-- pkcs-9-at-?		OBJECT IDENTIFIER ::= {pkcs-9 18}
-- pkcs-9-at-?		OBJECT IDENTIFIER ::= {pkcs-9 19}

pkcs-9-at-friendlyName	OBJECT IDENTIFIER ::= {pkcs-9 20}
pkcs-9-at-localKeyId	OBJECT IDENTIFIER ::= {pkcs-9 21}
pkcs-9-at-userPKCS12	OBJECT IDENTIFIER ::= {2 16 840 1 113730 3 1 216}
pkcs-9-at-pkcs15Token	OBJECT IDENTIFIER ::= {pkcs-9-at 1}
pkcs-9-at-encryptedPrivateKeyInfo OBJECT IDENTIFIER ::= {pkcs-9-at 2}

  -- Syntaxes (for use with LDAP accessible directories)
pkcs-9-sx-pkcs9String		OBJECT IDENTIFIER ::= {pkcs-9-sx 1}

  -- Object identifiers defined elsewhere

smime		  OBJECT IDENTIFIER ::= {pkcs-9 16} 
  -- Main arc for S/MIME, defined in IETF RFC [Housley]
certTypes	  OBJECT IDENTIFIER ::= {pkcs-9 22} 
  -- Main arc for certificate types defined in PKCS #12 v1.0.
  -- x509Certificate	  OBJECT IDENTIFIER ::= {certTypes 1} 
  -- Defined in PKCS #12 v1.0
  -- sdsiCertificate	  OBJECT IDENTIFIER ::= {certTypes 2} 
  -- Defined in PKCS #12 v1.0
crlTypes	  OBJECT IDENTIFIER ::= {pkcs-9 23}
  -- Main arc for crl types defined in PKCS #12 v1.0.
  -- x509CRL	          OBJECT IDENTIFIER ::= {crlTypes 1}
  -- Defined in PKCS #12 v1.0

-- Object classes

pkcsEntity OBJECT-CLASS	::=	{
	SUBCLASS OF	{ top }
	KIND		auxiliary
	MAY CONTAIN	{ PKCS9AttributeSet }
	ID		pkcs-9-oc-pkcsEntity
}

PKCS9AttributeSet ATTRIBUTE ::= {
	userPKCS12 |
	pKCS15Token |
	encryptedPrivateKeyInfo |
	emailAddress |
	unstructuredName |
	unstructuredAddress,
	... -- For future extensions
}

-- Attributes

userPKCS12 ATTRIBUTE ::= {
	WITH SYNTAX PFX
	ID pkcs-9-at-userPKCS12
}

pKCS15Token ATTRIBUTE ::= {
	WITH SYNTAX PKCS15Token
	ID pkcs-9-at-pkcs15Token
}

encryptedPrivateKeyInfo ATTRIBUTE ::= {
	WITH SYNTAX EncryptedPrivateKeyInfo
	ID pkcs-9-at-encryptedPrivateKeyInfo
}

emailAddress ATTRIBUTE ::= {
	WITH SYNTAX IA5String
	EQUALITY MATCHING RULE caseIgnoreMatch
	ID pkcs-9-at-emailAddress
}

unstructuredName ATTRIBUTE ::= {
	WITH SYNTAX PKCS9String
	EQUALITY MATCHING RULE caseIgnoreMatch
	ID pkcs-9-at-unstructuredName
}

PKCS9String ::= CHOICE {
	ia5String	IA5String,
        directoryString	DirectoryString {pkcs-9-ub-pkcs9String}
}

unstructuredAddress ATTRIBUTE ::= {
        WITH SYNTAX DirectoryString {pkcs-9-ub-unstructuredAddress}
	EQUALITY MATCHING RULE caseIgnoreMatch
	ID pkcs-9-at-unstructuredAddress
}

ContentType ::= OCTET STRING

contentType ATTRIBUTE ::= {
	WITH SYNTAX ContentType
	EQUALITY MATCHING RULE octetStringMatch
	SINGLE VALUE TRUE
	ID pkcs-9-at-contentType
}

MessageDigest ::= OCTET STRING

messageDigest ATTRIBUTE ::= {
	WITH SYNTAX MessageDigest
	EQUALITY MATCHING RULE octetStringMatch
	ID pkcs-9-at-messageDigest
}

SigningTime ::= UTCTime

signingTime ATTRIBUTE ::= {
	WITH SYNTAX SigningTime
	EQUALITY MATCHING RULE uTCTimeMatch
	SINGLE VALUE TRUE
	ID pkcs-9-at-signingTime
}

counterSignature ATTRIBUTE ::= {
	WITH SYNTAX SignerInfo
	ID pkcs-9-at-counterSignature
}

challengePassword ATTRIBUTE ::= {
	WITH SYNTAX PKCS9String
	EQUALITY MATCHING RULE caseExactMatch
	SINGLE VALUE TRUE
	ID pkcs-9-at-challengePassword
}

ExtensionRequest ::= SEQUENCE OF Extension

extensionRequest ATTRIBUTE ::= {
        WITH SYNTAX ExtensionRequest
        SINGLE VALUE TRUE
        ID pkcs-9-at-extensionRequest
}

extendedCertificateAttributes ATTRIBUTE ::= {
        WITH SYNTAX SET OF Attribute
	SINGLE VALUE TRUE
	ID pkcs-9-at-extendedCertificateAttributes
}

friendlyName ATTRIBUTE ::= {
	WITH SYNTAX BMPString
	EQUALITY MATCHING RULE caseIgnoreMatch
	SINGLE VALUE TRUE
	ID pkcs-9-at-friendlyName
}

localKeyId ATTRIBUTE ::= {
	WITH SYNTAX OCTET STRING
	EQUALITY MATCHING RULE octetStringMatch
	SINGLE VALUE TRUE
	ID pkcs-9-at-localKeyId
}

signingDescription ATTRIBUTE ::= {
	WITH SYNTAX DirectoryString {pkcs-9-ub-signingDescription}
	EQUALITY MATCHING RULE caseIgnoreMatch
	SINGLE VALUE TRUE
	ID pkcs-9-at-signingDescription
}

smimeCapabilities ATTRIBUTE ::= {
	WITH SYNTAX SMIMECapabilities
	SINGLE VALUE TRUE
	ID pkcs-9-at-smimeCapabilities
}

SMIMECapabilities ::= SEQUENCE {
        algorithm  ALGORITHM.&id ({SMIMEv2Algorithms}),
	parameters ALGORITHM.&Type ({SMIMEv2Algorithms}{@algorithm})
}

SMIMEv2Algorithms ALGORITHM ::= {...--defined in RFC 2311--}

END


B. BNF Schema Summary

This appendix provides BNF definitions of the object class and most
attribute types included in this standard along with their associated
syntaxes and matching rules. The BNF definition has been done in
accordance with IETF RFC 2252, in an attempt to ease integration with
LDAP-accessible directory systems. Lines has been folded in some cases
to improve readability.

B.1 Object Classes

B.1.1 pkcsEntity

( 
	1.2.840.113549.1.9.24.1
	NAME 'pkcsEntity'
	SUP top
	AUXILIARY
	MAY (
	    userPKCS12 $ pKCS15Token $ encryptedPrivateKeyInfo $
	    emailAddress $ unstructuredName $ unstructuredAddress
	}
)

B.2 Attribute Types

B.2.1 userPKCS12

This attribute is to be stored and requested in binary form, as
'userPKCS12;binary'. The attribute values are PFX PDUs stored as
binary (BER- or DER-encoded) data.

( 
        2.16.840.1.113730.3.1.216
        NAME 'userPKCS12'
        DESC 'PKCS #12 PFX PDU for exchange of personal information'
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.5
)

B.2.2 pKCS15Token

This attribute is to be stored and requested in binary form, as
'pKCS15Token;binary'. The attribute values are PKCS15Token PDUs stored
as binary (BER- or DER-encoded) data.

( 
        1.2.840.113549.1.9.25.1
        NAME 'pKCS15Token'
        DESC 'PKCS #15 token PDU'
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.5
)

B.2.3 encryptedPrivateKeyInfo

This attribute is to be stored and requested in binary form, as
'encryptedPrivateKeyInfo;binary'. The attribute values are
EncryptedPrivateKeyInfo PDUs stored as binary (BER- or DER-encoded)
data.

(
        1.2.840.113549.1.9.25.2
        NAME 'encryptedPrivateKeyInfo'
        DESC 'PKCS #8 encrypted private key info'
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.5
)

B.2.4 emailAddress

( 
	1.2.840.113549.1.9.1
	NAME 'emailAddress'
	DESC 'Email address'
	EQUALITY caseIgnoreMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
)

B.2.5 unstructuredName

( 
	1.2.840.113549.1.9.2
	NAME 'unstructuredName'
	DESC 'PKCS #9 unstructured name'
	EQUALITY caseIgnoreMatch
	SYNTAX 1.2.840.113549.1.9.26.1
)

B.2.6 unstructuredAddress

( 
        1.2.840.113549.1.9.8
        NAME 'unstructuredAddress'
        DESC 'PKCS #9 unstructured address'
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)

B.2.7 contentType

In the (highly unlikely) event of this attribute being stored in a
directory it is to be stored and requested in binary form, as
'contentType;binary'. Attribute values shall be OCTET STRINGs stored
as binary (BER- or DER-encoded) data.

(
	1.2.840.113549.1.9.3
	NAME 'contentType'
	DESC 'PKCS #7 content type attribute'
	EQUALITY octetStringMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.5
	SINGLE-VALUE
)

B.2.8 messageDigest

In the (highly unlikely) event of this attribute being stored in a
directory it is to be stored and requested in binary form, as
'messageDigest;binary'. Attribute values shall be OCTET STRINGs stored
as binary (BER- or DER-encoded) data.

(
	1.2.840.113549.1.9.4
	NAME 'messageDigest'
	DESC 'PKCS #7 mesage digest attribute'
	EQUALITY octetStringMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.5
	SINGLE-VALUE
)

B.2.9 signingTime

( 
	1.2.840.113549.1.9.5
	NAME 'signingTime'
	DESC 'PKCS #7 signing time'
	EQUALITY uTCTimeMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.53
	SINGLE-VALUE
)

B.2.10 counterSignature

In the (highly unlikely) event that this attribute is to be stored in a
directory, it is to be stored and requested in binary form, as
'counterSignature;binary'. Attribute values shall be stored as binary
(BER- or DER-encoded) data.

(
	1.2.840.113549.1.9.6
	NAME 'counterSignature'
	DESC 'PKCS #7 countersignature'
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.5
)

B.2.11 challengePassword

Note: It is not recommended to store values of this attribute
unprotected in a directory.

( 
	1.2.840.113549.1.9.7
	NAME 'challengePassword'
	DESC 'Challenge password for certificate revocations'
	EQUALITY caseExactMatch
	SYNTAX 1.2.840.113549.1.9.26.1
	SINGLE-VALUE
)

B.2.12 extensionRequest

In the (highly unlikely) event that this attribute is to be stored in a
directory, it is to be stored and requested in binary form, as
'extensionRequest;binary'. Attribute values shall be stored as binary
(BER- or DER-encoded) data.

{
	1.2.840.113549.1.9.14
	NAME 'extensionRequest'
	DESC 'Extension request'
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.5
}

B.2.13 extendedCertificateAttributes (deprecated)

( 
        1.2.840.113549.1.9.9
        NAME 'extendedCertificateAttributes'
        DESC 'PKCS #6 extended certificate attributes'
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.5
)


C. Intellectual property considerations

RSA Data Security makes no patent claims on the general constructions
described in this document, although specific underlying techniques
may be covered.

License to copy this document is granted provided that it is
identified as "RSA Data Security, Inc. Public-Key Cryptography
Standards (PKCS)" in all material mentioning or referencing this
document.

RSA Data Security makes no representations regarding intellectual
property claims by other parties. Such determination is the
responsibility of the user.


D. Revision history

Version 1.0

Version 1.0 is part of the June 3, 1991 initial public
release of PKCS. Version 1.0 was published as NIST/OSI
Implementors' Workshop document SEC-SIG-91-24.

Version 1.1

Version 1.1 incorporated several editorial changes, including updates
to the references and the addition of a revision history. The
following substantive changes were made:

     o    Section 6: Challenge-password, unstructured-
          address, and extended-certificate-attributes
          attribute types are added.

     o    Section 7: challengePassword, unstructuredAddress,
          and extendedCertificateAttributes object
          identifiers are added.

Version 2.0

Version 2.0 incorporates several editorial changes as well. The
following substantive changes were made:

     o    Added a section defining a new auxiliary object class,
          "pkcsUser".

     o    Addition of several new attribute types for use in
          conjunction with the new object class

     o    Updated all ASN.1 to be inline with the 1997 version of this
          notation.

     o    Added an ASN.1 module

     o    Added, in accordance with IETF RFC 2252, BNF description of
          all attributes and object classes 

     o    Added an intellectual property considerations section

E. References

PKCS #7   RSA Laboratories. PKCS #7: Cryptographic Message
          Syntax Standard. Version 1.5, November 1993.

PKCS #8   RSA Laboratories. PKCS #8: Private-Key Information
          Syntax Standard. Version 1.2, November 1993.

PKCS #10  RSA Laboratories. PKCS #10: Certification Request
          Syntax Standard. Version 1.0, November 1993.

X.680     ITU-T. Recommendation X.680: Information technology -
          Abstract Syntax Notation One (ASN.1): Specification of Basic
          Notation. July 1994. Also available as ISO/IEC 8824-1:1995.

X.690	  ITU-T. Recommendation X.690: Information Technology -
	  ASN.1 encoding Rules: Specification of Basic Encoding Rules
	  (BER), Canonical Encoding Rules (CER) and Distinguished
	  Encoding Rules (DER). July 1994. Also available as ISO/IEC
	  8825-1:1995.

X.501	  ITU-T. Recommendation X.501: Information technology - Open
	  Systems Interconnection - The Directory: Models. 1997. Also
	  available as ISO/IEC 9594-2:1997.

X.509     ITU-T. Recommendation X.509: Information technology - Open
	  Systems Interconnection - The Directory: Authentication
	  framework. 1997. Also available as ISO/IEC 9594-8:1997.

X.520     ITU-T. Recommendation X.520: Information technology - Open
	  Systems Interconnection - The Directory: Selected attribute
	  types. 1997. Also available as ISO/IEC 9594-6:1997.

X.521	  ITU-T. Recommendation X.521: Information technology - Open
	  Systems Interconnection - The Directory: Selected object
	  classes. 1997. Also available as ISO/IEC 9594-7:1997.

ISO 10646 ISO/IEC 10646-1: Information Technology--Universal
          Multiple-Octet Coded Character Set (UCS)--Part 1:
          Architecture and Basic Multilingual Plane. 1993.

RFC 2119  IETF RFC 2119: Key words for use in RFCs to Indicate
	  Requirement Levels. March 1997.

RFC 2252  IETF RFC 2252: Lightweight Directory Access Protocol (v3):
	  Attribute Syntax Definitions. December 1997.

RFC 2311  IETF RFC 2311: S/MIME Version 2 Message Specification. March
	  1998.

RFC [Housley] IETF RFC [Housley]: Cryptographic Message Syntax CMS. 1999.

RFC [Smith] IETF RFC [Smith]: Definition of the inetOrgPerson LDAP
          Object Class. 1999.

F. About PKCS

The Public-Key Cryptography Standards are specifications produced by
RSA Laboratories in cooperation with secure systems developers
worldwide for the purpose of accelerating the deployment of public-key
cryptography. First published in 1991 as a result of meetings with a
small group of early adopters of public-key technology, the PKCS
documents have become widely referenced and implemented. Contributions
from the PKCS series have become part of many formal and de facto
standards, including ANSI X9 documents, PKIX, SET, S/MIME, and SSL.

Further development of PKCS occurs through mailing list discussions
and occasional workshops, and suggestions for improvement are
welcome. For more information, contact:

RSA Laboratories		
20 Crosby Drive
Bedford, MA  01730  USA		

E-mail: pkcs-editor@rsa.com
Web:	www.rsa.com/rsalabs/pubs/PKCS