rfc3039.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,771 行 · 第 1/5 页

   The SementicsInformation component identified by id-qcs-
   pkixQCSyntax-v1 MAY contain a semantics identifier and MAY identify
   one or more name registration authorities.

   The semanticsIdentifier component, if present, SHALL contain an OID,
   defining semantics for attributes and names in basic certificate
   fields and certificate extensions.  The OID may define semantics for
   all, or for a subgroup of all present attributes and/or names.

   The NameRegistrationAuthorities component, if present, SHALL contain
   a name of one or more name registration authorities, responsible for
   registration of attributes or names associated with the subject.  The
   association between an identified name registration authority and
   present attributes MAY be defined by a semantics identifier OID, by a
   certificate policy (or CPS) or some other implicit factors.



Santesson, et al.           Standards Track                    [Page 13]

RFC 3039             Qualified Certificates Profile         January 2001


   If a value of type SemanticsInformation is present in a QCStatement
   then at least one of the fields semanticsIdentifier and
   nameRegistrationAuthorities must be present, as indicated.

4  Security Considerations

   The legal value of a digital signature that is validated with a
   Qualified Certificate will be highly dependent upon the policy
   governing the use of the associated private key.  Both the private
   key holder as well as the relying party should make sure that the
   private key is used only with the consent of the legitimate key
   holder.

   Since the public keys are for public use with legal implications for
   involved parties, certain conditions should exist before CAs issue
   certificates as Qualified Certificates.  The associated private keys
   must be unique for the subject, and must be maintained under the
   subject's sole control.  That is, a CA should not issue a qualified
   certificate if the means to use the private key is not protected
   against unintended usage.  This implies that the CA have some
   knowledge about the subject's cryptographic module.

   The CA must further verify that the public key contained in the
   certificate is legitimately representing the subject.

   CAs should not issue CA certificates with policy mapping extensions
   indicating acceptance of another CA's policy unless these conditions
   are met.

   Combining the nonRepudiation bit in the keyUsage certificate
   extension with other keyUsage bits may have security implications and
   this specification therefore recommends against such practices.

   The ability to compare two qualified certificates to determine if
   they represent the same physical entity is dependent on the semantics
   of the subjects' names.  The semantics of a particular attribute may
   be different for different issuers.  Comparing names without
   knowledge of the semantics of names in these particular certificates
   may provide misleading results.

   This specification is a profile of RFC 2459.  The security
   considerations section of that document applies to this specification
   as well.








Santesson, et al.           Standards Track                    [Page 14]

RFC 3039             Qualified Certificates Profile         January 2001


5 References

   [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC 2247] Kille, S., Wahl, M., Grimstad, A., Huber, R. and S.
              Sataluri, "Using Domains in LDAP/X.500 Distinguished
              Names", RFC 2247, January 1998.

   [RFC 2459] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet
              X.509 Public Key Infrastructure: Certificate and CRL
              Profile", RFC 2459, January 1999.

   [RFC 2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object
              Classes and Attribute Types Version 2.0", RFC 2985,
              November 2000.

   [X.501]    ITU-T Recommendation X.501: Information Technology - Open
              Systems Interconnection - The Directory: Models, June
              1993.

   [X.509]    ITU-T Recommendation X.509: Information Technology - Open
              Systems Interconnection - The Directory: Authentication
              Framework, June 1997.

   [X.520]    ITU-T Recommendation X.520: Information Technology - Open
              Systems Interconnection - The Directory: Selected
              Attribute Types, June 1993.

   [X.680]    ITU-T Recommendation X.680: Information Technology -
              Abstract Syntax Notation One, 1997.

   [ISO 3166] ISO Standard 3166: Codes for the representation of names
              of countries, 1993.

















Santesson, et al.           Standards Track                    [Page 15]

RFC 3039             Qualified Certificates Profile         January 2001


6 Intellectual Property Rights

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.






























Santesson, et al.           Standards Track                    [Page 16]

RFC 3039             Qualified Certificates Profile         January 2001


A. ASN.1 definitions

   As in RFC 2459, ASN.1 modules are supplied in two different variants
   of the ASN.1 syntax.

   Appendix A.1 is in the 1988 syntax, and does not use macros.
   However, since the module imports type definitions from modules in
   RFC 2459 which are not completely in the 1988 syntax, the same
   comments as in RFC 2459 regarding its use applies here as well; i.e.,
   Appendix A.1 may be parsed by an 1988 ASN.1-parser by removing the
   definitions for the UNIVERSAL types and all references to them in RFC
   2459's 1988 modules.

   Appendix A.2 is in the 1993 syntax.  However, since the module
   imports type definitions from modules in RFC 2459 which are not
   completely in the 1993 syntax, the same comments as in RFC 2459
   regarding its use applies here as well; i.e., Appendix A.2 may be
   parsed by an 1993 ASN.1-parser by removing the UTF8String choice from
   the definition of DirectoryString in the module PKIX1Explicit93 in
   RFC 2459.  Appendix A.2 may be parsed "as is" by an 1997 ASN.1
   parser, however.

   In case of discrepancies between these modules, the 1988 module is
   the normative one.

A.1 1988 ASN.1 Module

PKIXqualified88 {iso(1) identified-organization(3) dod(6)
    internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
    id-mod-qualified-cert-88(10) }

DEFINITIONS EXPLICIT TAGS ::=

BEGIN

-- EXPORTS ALL --

IMPORTS

GeneralName
    FROM PKIX1Implicit88 {iso(1) identified-organization(3) dod(6)
    internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
    id-pkix1-implicit-88(2)}

AlgorithmIdentifier, DirectoryString, Attribute, AttributeType,
    id-pkix, id-pe, id-at
    FROM PKIX1Explicit88 {iso(1) identified-organization(3) dod(6)
    internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)



Santesson, et al.           Standards Track                    [Page 17]

RFC 3039             Qualified Certificates Profile         January 2001


    id-pkix1-explicit-88(1)};

-- Locally defined OIDs

-- Arc for QC personal data attributes
id-pda  OBJECT IDENTIFIER ::= { id-pkix 9 }
-- Arc for QC statements
id-qcs  OBJECT IDENTIFIER ::= { id-pkix 11 }

-- Attributes

id-at-serialNumber          AttributeType ::= { id-at 5 }
SerialNumber ::=            PrintableString (SIZE(1..64))

id-at-postalAddress         AttributeType ::= { id-at 16 }
PostalAddress ::=           SEQUENCE SIZE (1..6) OF DirectoryString

id-at-pseudonym             AttributeType ::= { id-at 65 }
Pseudonym ::=               DirectoryString

domainComponent             AttributeType ::=
                            { 0 9 2342 19200300 100 1 25 }
DomainComponent ::=         IA5String

id-pda-dateOfBirth          AttributeType ::= { id-pda 1 }
DateOfBirth ::=             GeneralizedTime

id-pda-placeOfBirth         AttributeType ::= { id-pda 2 }
PlaceOfBirth ::=            DirectoryString

id-pda-gender               AttributeType ::= { id-pda 3 }
Gender ::=                  PrintableString (SIZE(1))
                            -- "M", "F", "m" or "f"

id-pda-countryOfCitizenship AttributeType ::= { id-pda 4 }
CountryOfCitizenship ::=    PrintableString (SIZE (2))
                            -- ISO 3166 Country Code

id-pda-countryOfResidence   AttributeType ::= { id-pda 5 }
CountryOfResidence ::=      PrintableString (SIZE (2))
                            -- ISO 3166 Country Code

-- Private extensions

-- Biometric info extension

id-pe-biometricInfo OBJECT IDENTIFIER  ::= {id-pe 2}




Santesson, et al.           Standards Track                    [Page 18]

RFC 3039             Qualified Certificates Profile         January 2001


BiometricSyntax ::= SEQUENCE OF BiometricData

BiometricData ::= SEQUENCE {
    typeOfBiometricData  TypeOfBiometricData,
    hashAlgorithm        AlgorithmIdentifier,
    biometricDataHash    OCTET STRING,
    sourceDataUri        IA5String OPTIONAL }

TypeOfBiometricData ::= CHOICE {
    predefinedBiometricType   PredefinedBiometricType,
    biometricDataOid          OBJECT IDENTIFIER }

PredefinedBiometricType ::= INTEGER {
    picture(0),handwritten-signature(1)}
    (picture|handwritten-signature)

-- QC Statements Extension

id-pe-qcStatements OBJECT IDENTIFIER ::= { id-pe 3}

QCStatements ::= SEQUENCE OF QCStatement

QCStatement ::= SEQUENCE {
    statementId        OBJECT IDENTIFIER,
    statementInfo      ANY DEFINED BY statementId OPTIONAL}

-- QC statements
id-qcs-pkixQCSyntax-v1   OBJECT IDENTIFIER ::= { id-qcs 1 }

--  This statement identifies conformance with syntax and
--  semantics defined in this Qualified Certificate profile
--  (Version 1). This statement may optionally contain
--  additional semantics information as specified below.

SemanticsInformation  ::= SEQUENCE {
    semanticsIndentifier        OBJECT IDENTIFIER OPTIONAL,
    nameRegistrationAuthorities NameRegistrationAuthorities OPTIONAL
    } -- At least one field shall be present

NameRegistrationAuthorities ::= SEQUENCE SIZE (1..MAX) OF GeneralName

END

A.2 1993 ASN.1  Module

PKIXqualified93 {iso(1) identified-organization(3) dod(6)
    internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
    id-mod-qualified-cert-93(11) }