rfc2985.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

           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.





Nystrom & Kaliski            Informational                      [Page 8]

RFC 2985      Selected Object Classes and Attribute Types  November 2000


   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
   }





Nystrom & Kaliski            Informational                      [Page 9]

RFC 2985      Selected Object Classes and Attribute Types  November 2000


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













Nystrom & Kaliski            Informational                     [Page 10]

RFC 2985      Selected Object Classes and Attribute Types  November 2000


  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.



Nystrom & Kaliski            Informational                     [Page 11]

RFC 2985      Selected Object Classes and Attribute Types  November 2000


  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.





Nystrom & Kaliski            Informational                     [Page 12]

RFC 2985      Selected Object Classes and Attribute Types  November 2000


  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.





Nystrom & Kaliski            Informational                     [Page 13]

RFC 2985      Selected Object Classes and Attribute Types  November 2000


   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
   }

   RandomNonce ::= OCTET STRING (SIZE(4..MAX))
           -- At least four bytes long

   A random nonce attribute must have a single attribute value.





Nystrom & Kaliski            Informational                     [Page 14]

RFC 2985      Selected Object Classes and Attribute Types  November 2000


  5.3.5 Sequence number

   The sequenceNumber attribute type is intended for PKCS #7 digitally
   signed data.  A signer wishing to associate a sequence number to all
   signature operations (much like a physical checkbook) may use it as
   an alternative to the randomNonce attribute.  Used in a correct
   manner, it will make it possible for the signer to protect against
   certain attacks, i.e. replay attacks.

   sequenceNumber ATTRIBUTE ::= {
           WITH SYNTAX SequenceNumber
           EQUALITY MATCHING RULE integerMatch
           SINGLE VALUE TRUE
           ID pkcs-9-at-sequenceNumber
   }

   SequenceNumber ::= INTEGER (1..MAX)

   A sequence number attribute must have a single attribute value.

   The integerMatch matching rule is defined in [8].

  5.3.6 Countersignature

   The counterSignature attribute type specifies one or more signatures
   on the content 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 [14] and Section 5.3 of
   [3]), except that:

   1. The authenticatedAttributes field must contain a messageDigest
   attribute if it contains any other attributes, but need not contain a
   contentType attribute, as there is no content type for
   countersignatures; and






Nystrom & Kaliski            Informational                     [Page 15]

RFC 2985      Selected Object Classes and Attribute Types  November 2000


   2. The input to the message-digesting process is the content 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.

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

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