summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3739.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3739.txt')
-rw-r--r--doc/rfc/rfc3739.txt1907
1 files changed, 1907 insertions, 0 deletions
diff --git a/doc/rfc/rfc3739.txt b/doc/rfc/rfc3739.txt
new file mode 100644
index 0000000..4ad1271
--- /dev/null
+++ b/doc/rfc/rfc3739.txt
@@ -0,0 +1,1907 @@
+
+
+
+
+
+
+Network Working Group S. Santesson
+Request for Comments: 3739 Microsoft
+Obsoletes: 3039 M. Nystrom
+Category: Standards Track RSA Security
+ T. Polk
+ NIST
+ March 2004
+
+
+ Internet X.509 Public Key Infrastructure:
+ Qualified Certificates Profile
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2004). All Rights Reserved.
+
+Abstract
+
+ This document forms a certificate profile, based on RFC 3280, for
+ identity certificates issued to natural persons.
+
+ The profile defines specific conventions for certificates that are
+ qualified within a defined legal framework, named Qualified
+ Certificates. However, the profile does not define any legal
+ requirements for such Qualified Certificates.
+
+ The goal of this document is to define a certificate profile that
+ supports the issuance of Qualified Certificates independent of local
+ legal requirements. The profile is however not limited to Qualified
+ Certificates and further profiling may facilitate specific local
+ needs.
+
+
+
+
+
+
+
+
+
+
+
+
+Santesson, et al. Standards Track [Page 1]
+
+RFC 3739 Qualified Certificates Profile March 2004
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 1.1. Changes since RFC 3039 . . . . . . . . . . . . . . . . . 3
+ 1.2. Definitions. . . . . . . . . . . . . . . . . . . . . . . 4
+ 2. Requirements and Assumptions . . . . . . . . . . . . . . . . . 4
+ 2.1. Properties . . . . . . . . . . . . . . . . . . . . . . . 5
+ 2.2. Statement of Purpose . . . . . . . . . . . . . . . . . . 5
+ 2.3. Policy Issues. . . . . . . . . . . . . . . . . . . . . . 5
+ 2.4. Uniqueness of Names. . . . . . . . . . . . . . . . . . . 6
+ 3. Certificate and Certificate Extensions Profile . . . . . . . . 6
+ 3.1. Basic Certificate Fields . . . . . . . . . . . . . . . . 6
+ 3.1.1. Issuer . . . . . . . . . . . . . . . . . . . . . 6
+ 3.1.2. Subject. . . . . . . . . . . . . . . . . . . . . 7
+ 3.2. Certificate Extensions . . . . . . . . . . . . . . . . . 9
+ 3.2.1. Subject Alternative Name . . . . . . . . . . . . 9
+ 3.2.2. Subject Directory Attributes . . . . . . . . . . 9
+ 3.2.3. Certificate Policies . . . . . . . . . . . . . . 11
+ 3.2.4. Key Usage. . . . . . . . . . . . . . . . . . . . 11
+ 3.2.5. Biometric Information. . . . . . . . . . . . . . 11
+ 3.2.6. Qualified Certificate Statements . . . . . . . . 13
+ 4. Security Considerations. . . . . . . . . . . . . . . . . . . . 15
+ A. ASN.1 Definitions. . . . . . . . . . . . . . . . . . . . . . . 17
+ A.1. 1988 ASN.1 Module (Normative). . . . . . . . . . . . . . 17
+ A.2. 1997 ASN.1 Module (Informative). . . . . . . . . . . . . 19
+ B. A Note on Attributes . . . . . . . . . . . . . . . . . . . . . 23
+ C. Example Certificate. . . . . . . . . . . . . . . . . . . . . . 23
+ C.1. ASN.1 Structure. . . . . . . . . . . . . . . . . . . . . 24
+ C.1.1. Extensions . . . . . . . . . . . . . . . . . . . 24
+ C.1.2. The Certificate. . . . . . . . . . . . . . . . . 25
+ C.2. ASN.1 Dump . . . . . . . . . . . . . . . . . . . . . . . 27
+ C.3. DER-encoding . . . . . . . . . . . . . . . . . . . . . . 30
+ C.4. CA's Public Key. . . . . . . . . . . . . . . . . . . . . 31
+ References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
+ Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 34
+
+1. Introduction
+
+ This specification is one part of a family of standards for the X.509
+ Public Key Infrastructure (PKI) for the Internet. It is based on
+ [X.509] and [RFC 3280], which defines underlying certificate formats
+ and semantics needed for a full implementation of this standard.
+
+ This profile includes specific mechanisms intended for use with
+ Qualified Certificates. The term Qualified Certificates and the
+ assumptions that affect the scope of this document are discussed in
+ Section 2.
+
+
+
+Santesson, et al. Standards Track [Page 2]
+
+RFC 3739 Qualified Certificates Profile March 2004
+
+
+ Section 3 defines requirements on certificate information content.
+ This specification provides profiles for two certificate fields:
+ issuer and subject. It also provides profiles for four certificate
+ extensions defined in RFC 3280: subject alternate name, subject
+ directory attributes, certificate policies, and key usage, and it
+ defines two additional extensions: biometric information and
+ qualified certificate statements. The certificate extensions are
+ presented in the 1997 Abstract Syntax Notation One (ASN.1) [X.680],
+ but in conformance with RFC 3280 the 1988 ASN.1 module in Appendix A
+ contains all normative definitions (the 1997 module in Appendix A is
+ informative).
+
+ In Section 4, some security considerations are discussed in order to
+ clarify the security context in which the standard may be utilized.
+
+ Appendix A contains all relevant ASN.1 structures that are not
+ already defined in RFC 3280. Appendix B contains a note on
+ attributes. Appendix C contains an example certificate.
+
+ The appendices sections are followed by the References, Authors
+ Addresses, and the Full Copyright Statement.
+
+1.1. Changes since RFC 3039
+
+ This specification obsoletes RFC 3039. This specification differs
+ from RFC 3039 in the following basic areas:
+
+ * Some editorial clarifications have been made to introductory
+ sections to clarify that this profile is generally applicable
+ to a broad type of certificates, even if its prime purpose is
+ to facilitate issuance of Qualified Certificates.
+
+ * To align with RFC 3280, support for domainComponent and title
+ attributes in subject names are included, and postalAddress is
+ no longer supported.
+
+ * To align with actual usage, support for the title attribute in
+ the subject directory attributes extension is no longer
+ supported.
+
+ * To better facilitate broad applicability of this profile, some
+ constraints on key usage settings in the key usage extension
+ have been removed.
+
+ * A new qc-Statement reflecting this second version of the
+ profile has been defined in Section 3.2.6.1. This profile
+ obsoletes RFC 3039, but the qc-statement reflecting compliance
+ with RFC 3039 is also defined for backwards compatibility.
+
+
+
+Santesson, et al. Standards Track [Page 3]
+
+RFC 3739 Qualified Certificates Profile March 2004
+
+
+1.2. Definitions
+
+ 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 BCP 14, [RFC 2119].
+
+2. Requirements and Assumptions
+
+ The term "Qualified Certificate" is used by the European Directive on
+ Electronic Signature [EU-ESDIR] to refer to a specific type of
+ certificates, with appliance in European electronic signature
+ legislation. This specification is intended to support this class of
+ certificates, but its scope is not limited to this application.
+
+ Within this standard, the term "Qualified Certificate" is used
+ generally, describing a certificate whose primary purpose is to
+ identify a person with a high level of assurance, where the
+ certificate meets some qualification requirements defined by an
+ applicable legal framework, such as the European Directive on
+ Electronic Signature [EU-ESDIR]. The actual mechanisms that decide
+ whether a certificate should or should not be considered a "Qualified
+ Certificate" in regard to any legislation are outside the scope of
+ this standard.
+
+ Harmonization in the field of identity certificates issued to natural
+ persons, in particular Qualified Certificates, is essential within
+ several aspects that fall outside the scope of RFC 3280. The most
+ important aspects that affect the scope of this specification are:
+
+ - Definition of names and identity information in order to identify
+ the associated subject in a uniform way.
+
+ - Definition of information which identifies the CA and the
+ jurisdiction under which the CA operates when issuing a particular
+ certificate.
+
+ - Definition of key usage extension usage for Qualified
+ Certificates.
+
+ - Definition of information structure for storage of biometric
+ information.
+
+ - Definition of a standardized way to store predefined statements
+ with relevance for Qualified Certificates.
+
+ - Requirements for critical extensions.
+
+
+
+
+
+Santesson, et al. Standards Track [Page 4]
+
+RFC 3739 Qualified Certificates Profile March 2004
+
+
+2.1. Properties
+
+ This profile accommodates profiling needs for Qualified Certificates
+ based on the assumptions that:
+
+ - Qualified Certificates are issued by a CA that makes a statement
+ that the certificate serves the purpose of a Qualified
+ Certificate, as discussed in Section 2.2.
+
+ - The Qualified Certificate indicates a certificate policy
+ consistent with liabilities, practices, and procedures undertaken
+ by the CA, as discussed in Section 2.3.
+
+ - The Qualified Certificate is issued to a natural person (living
+ human being).
+
+ - The Qualified Certificate contains a name which may be either
+ based on the real name of the subject or a pseudonym.
+
+2.2. Statement of Purpose
+
+ This profile defines conventions to declare within a certificate that
+ it serves the purpose of being a Qualified Certificate. This enables
+ the CA to explicitly define this intent.
+
+ The function of this declaration is thus to assist any concerned
+ entity in evaluating the risk associated with creating or accepting
+ signatures that are based on a Qualified Certificate.
+
+ This profile defines two ways to include this information:
+
+ - As information defined by a certificate policy included in the
+ certificate policies extension, and
+
+ - As a statement included in the Qualified Certificates Statements
+ extension.
+
+2.3. Policy Issues
+
+ Certain policy aspects define the context in which this profile is to
+ be understood and used. It is however outside the scope of this
+ profile to specify any policies or legal aspects that will govern
+ services that issue or utilize certificates according to this
+ profile.
+
+ It is however an underlying assumption in this profile that a
+ responsible issuing CA will undertake to follow a certificate policy
+ that is consistent with its liabilities, practices, and procedures.
+
+
+
+Santesson, et al. Standards Track [Page 5]
+
+RFC 3739 Qualified Certificates Profile March 2004
+
+
+2.4. Uniqueness of names
+
+ Distinguished name is originally defined in X.501 [X.501] as a
+ representation of a directory name, defined as a construct that
+ identifies a particular object from among a set of all objects. The
+ distinguished name MUST be unique for each subject entity certified
+ by the one CA as defined by the issuer name field, for the whole life
+ time of the CA.
+
+3. Certificate and Certificate Extensions Profile
+
+ This section defines certificate profiling conventions. The profile
+ is based on the Internet certificate profile RFC 3280, which in turn
+ is based on the X.509 version 3 format. For full implementation of
+ this section, implementers are REQUIRED to consult the underlying
+ formats and semantics defined in RFC 3280.
+
+ ASN.1 definitions, relevant for this section that are not supplied by
+ RFC 3280, are supplied in Appendix A.
+
+3.1. Basic Certificate Fields
+
+ This section provides additional details regarding the contents of
+ two fields in the basic certificate. These fields are the issuer and
+ subject fields.
+
+3.1.1. Issuer
+
+ The issuer field SHALL identify the organization responsible for
+ issuing the certificate. The name SHOULD be an officially registered
+ name of the organization.
+
+ The distinguished name of the issuer SHALL be specified using an
+ appropriate subset of the following attributes:
+
+ domainComponent;
+ countryName;
+ stateOrProvinceName;
+ organizationName;
+ localityName; and
+ serialNumber.
+
+ The domainComponent attribute is defined in [RFC 2247], all other
+ attributes are defined in [RFC 3280] and [X.520].
+
+ Additional attributes MAY be present, but they SHOULD NOT be
+ necessary to identify the issuing organization.
+
+
+
+
+Santesson, et al. Standards Track [Page 6]
+
+RFC 3739 Qualified Certificates Profile March 2004
+
+
+ A relying party MAY have to consult associated certificate policies
+ and/or the issuer's CPS, in order to determine the semantics of name
+ fields.
+
+3.1.2. Subject
+
+ The subject field of a certificate compliant with this profile SHALL
+ contain a distinguished name of the subject (see 2.4 for definition
+ of distinguished name).
+
+ The subject field SHALL contain an appropriate subset of the
+ following attributes:
+
+ domainComponent;
+ countryName;
+ commonName;
+ surname;
+ givenName;
+ pseudonym;
+ serialNumber;
+ title;
+ organizationName;
+ organizationalUnitName;
+ stateOrProvinceName; and
+ localityName.
+
+ The domainComponent attribute is defined in [RFC 2247], all other
+ attributes are defined in [RFC 3280] and [X.520].
+
+ Other attributes MAY also be present; however, the use of other
+ attributes MUST NOT be necessary to distinguish one subject name from
+ another subject name. That is, the attributes listed above are
+ sufficient to ensure unique subject names.
+
+ Of these attributes, the subject field SHALL include at least one of
+ the following:
+
+ Choice I: commonName
+ Choice II: givenName
+ Choice III: pseudonym
+
+ The countryName attribute value specifies a general context in
+ which other attributes are to be understood. The country
+ attribute does not necessarily indicate the subject's country of
+ citizenship or country of residence, nor does it have to indicate
+ the country of issuance.
+
+
+
+
+
+Santesson, et al. Standards Track [Page 7]
+
+RFC 3739 Qualified Certificates Profile March 2004
+
+
+ Note: Many X.500 implementations require the presence of countryName
+ in the DIT. In cases where the subject name, as specified in the
+ subject field, specifies a public X.500 directory entry, the
+ countryName attribute SHOULD always be present.
+
+ The commonName attribute value SHALL, when present, contain a name
+ of the subject. This MAY be in the subject's preferred
+ presentation format, or a format preferred by the CA, or some
+ other format. Pseudonyms, nicknames, and names with spelling
+ other than defined by the registered name MAY be used. To
+ understand the nature of the name presented in commonName,
+ complying applications MAY have to examine present values of the
+ givenName and surname attributes, or the pseudonym attribute.
+
+ Note: Many client implementations presuppose the presence of the
+ commonName attribute value in the subject field and use this value to
+ display the subject's name regardless of present givenName, surname,
+ or pseudonym attribute values.
+
+ The surname and givenName attribute types SHALL be used in the
+ subject field if neither the commonName attribute nor the
+ pseudonym attribute is present. In cases where the subject only
+ has a givenName, the surname attribute SHALL be omitted.
+
+ The pseudonym attribute type SHALL, if present, contain a
+ pseudonym of the subject. Use of the pseudonym attribute MUST NOT
+ be combined with use of any of the attributes surname and/or
+ givenName.
+
+ The serialNumber attribute type SHALL, when present, be used to
+ differentiate between names where the subject field would
+ otherwise be identical. This attribute has no defined semantics
+ beyond ensuring uniqueness of subject names. It MAY contain a
+ number or code assigned by the CA or an identifier assigned by a
+ government or civil authority. It is the CA's responsibility to
+ ensure that the serialNumber is sufficient to resolve any subject
+ name collisions.
+
+ The title attribute type SHALL, when present, be used to store a
+ designated position or function of the subject within the
+ organization specified by present organizational attributes in the
+ subject field. The association between the title, the subject,
+ and the organization is beyond the scope of this document.
+
+ The organizationName and the organizationalUnitName attribute
+ types SHALL, when present, be used to store the name and relevant
+ information of an organization with which the subject is
+
+
+
+
+Santesson, et al. Standards Track [Page 8]
+
+RFC 3739 Qualified Certificates Profile March 2004
+
+
+ associated. The type of association between the organization and
+ the subject is beyond the scope of this document.
+
+ The stateOrProvinceName and the localityName attribute types
+ SHALL, when present, be used to store geographical information
+ with which the subject is associated. If an organizationName
+ value is also present, then the stateOrProvinceName and
+ localityName attribute values SHALL be associated with the
+ specified organization. The type of association between the
+ stateOrProvinceName and the localityName and either the subject or
+ the organizationName is beyond the scope of this document.
+
+ Compliant implementations SHALL be able to interpret the attributes
+ named in this section.
+
+3.2. Certificate Extensions
+
+ This section provides additional details regarding the contents of
+ four certificate extensions defined in RFC 3280: Subject Alternative
+ Name, Subject directory attributes, Certificate policies, and Key
+ usage. This section also defines two additional extensions:
+ biometric information and qualified certificate statements.
+
+3.2.1. Subject Alternative Name
+
+ If the subjectAltName extension is present, and it contains a
+ directoryName name, then the directoryName MUST follow the
+ conventions specified in section 3.1.2 of this profile.
+
+3.2.2. Subject Directory Attributes
+
+ The subjectDirectoryAttributes extension MAY be present and MAY
+ contain additional attributes associated with the subject, as a
+ complement to present information in the subject field and the
+ subject alternative name extension.
+
+ Attributes suitable for storage in this extension are attributes
+ which are not part of the subject's distinguished name, but which MAY
+ still be useful for other purposes (e.g., authorization).
+
+ This extension MUST NOT be marked critical.
+
+ Compliant implementations SHALL be able to interpret the following
+ attributes:
+
+ dateOfBirth;
+ placeOfBirth;
+ gender;
+
+
+
+Santesson, et al. Standards Track [Page 9]
+
+RFC 3739 Qualified Certificates Profile March 2004
+
+
+ countryOfCitizenship; and
+ countryOfResidence.
+
+ Other attributes MAY be included according to local definitions.
+
+ The dateOfBirth attribute SHALL, when present, contain the value
+ of the date of birth of the subject. The manner in which the date
+ of birth is associated with the subject is outside the scope of
+ this document. The date of birth is defined in the
+ GeneralizedTime format and SHOULD specify GMT 12.00.00 (noon) down
+ to the granularity of seconds, in order to prevent accidental
+ change of date due to time zone adjustments. For example, a birth
+ date of September 27, 1959 is encoded as "19590927120000Z".
+ Compliant certificate parsing applications SHOULD ignore any time
+ data and just present the contained date without any time zone
+ adjustments.
+
+ The placeOfBirth attribute SHALL, when present, contain the value
+ of the place of birth of the subject. The manner in which the
+ place of birth is associated with the subject is outside the scope
+ of this document.
+
+ The gender attribute SHALL, when present, contain the value of the
+ gender of the subject. For females the value "F" (or "f"), and
+ for males the value "M" (or "m"), have to be used. The manner in
+ which the gender is associated with the subject is outside the
+ scope of this document.
+
+ The countryOfCitizenship attribute SHALL, when present, contain
+ the identifier of at least one of the subject's claimed countries
+ of citizenship at the time the certificate was issued. If more
+ than one country of citizenship is specified, each country of
+ citizenship SHOULD be specified through a separate, single-valued
+ countryOfCitizenship attribute. Determination of citizenship is a
+ matter of law and is outside the scope of this document.
+
+ The countryOfResidence attribute SHALL, when present, contain the
+ value of at least one country in which the subject is resident.
+ If more than one country of residence is specified, each country
+ of residence SHOULD be specified through a separate, single-valued
+ countryOfResidence attribute. Determination of residence is a
+ matter of law and is outside the scope of this document.
+
+
+
+
+
+
+
+
+
+Santesson, et al. Standards Track [Page 10]
+
+RFC 3739 Qualified Certificates Profile March 2004
+
+
+3.2.3. Certificate Policies
+
+ The certificate policies extension SHALL be present and SHALL contain
+ the identifier of at least one certificate policy which reflects the
+ practices and procedures undertaken by the CA. The certificate
+ policy extension MAY be marked critical.
+
+ Information provided by the issuer stating the purpose of the
+ certificate, as discussed in Section 2.2, SHOULD be evident through
+ indicated policies.
+
+ The certificate policies extension MUST include all policy
+ information needed for certification path validation. If policy
+ related statements are included in the QCStatements extension (see
+ 3.2.6), then these statements SHOULD also be contained in the
+ identified policies.
+
+ Certificate policies MAY be combined with any qualifier defined in
+ RFC 3280.
+
+3.2.4. Key Usage
+
+ The key usage extension SHALL be present. Key usage settings SHALL
+ be set in accordance with RFC 3280 definitions. Further requirements
+ on key usage settings MAY be defined by local policy and/or local
+ legal requirements.
+
+ The key usage extension SHOULD be marked critical.
+
+3.2.5. Biometric Information
+
+ This section defines an OPTIONAL extension for storage of biometric
+ information. Biometric information is stored in the form of a hash
+ of a biometric template.
+
+ The purpose of this extension is to provide a means for the
+ authentication of biometric information. The biometric information
+ that corresponds to the stored hash is not stored in this extension,
+ but the extension MAY include a URI (sourceDataUri) that references a
+ file containing this information.
+
+ If included, the URI MUST use the HTTP scheme (http://) [HTTP/1.1] or
+ the HTTPS scheme (https://) [RFC 2818]. Since the fact that
+ identifying data is being checked may itself be sensitive
+ information, those deploying this mechanism may also wish to consider
+ using URIs which cannot be easily tied by outsiders to the identities
+ of those whose information is being retrieved.
+
+
+
+
+Santesson, et al. Standards Track [Page 11]
+
+RFC 3739 Qualified Certificates Profile March 2004
+
+
+ Use of the URI option presumes that the data encoding format of the
+ file content is determined through means outside the scope of this
+ specification, such as file naming conventions and metadata inside
+ the file. Use of this URI option does not imply that it is the only
+ way to access this information.
+
+ It is RECOMMENDED that biometric information in this extension be
+ limited to information types suitable for human verification, i.e.,
+ where the decision of whether the information is an accurate
+ representation of the subject is naturally performed by a person.
+ This implies a usage where the biometric information is represented
+ by, for example, a graphical image displayed to the relying party,
+ which MAY be used by the relying party to enhance identification of
+ the subject.
+
+ This extension MUST NOT be marked critical.
+
+ biometricInfo EXTENSION ::= {
+ SYNTAX BiometricSyntax
+ IDENTIFIED BY id-pe-biometricInfo }
+
+ id-pe-biometricInfo OBJECT IDENTIFIER ::= {id-pe 2}
+
+ BiometricSyntax ::= SEQUENCE OF BiometricData
+
+ BiometricData ::= SEQUENCE {
+ typeOfBiometricData TypeOfBiometricData,
+ hashAlgorithm AlgorithmIdentifier,
+ biometricDataHash OCTET STRING,
+ sourceDataUri IA5String OPTIONAL }
+
+ TypeOfBiometricData ::= CHOICE {
+ predefinedBiometricType PredefinedBiometricType,
+ biometricDataID OBJECT IDENTIFIER }
+
+ PredefinedBiometricType ::= INTEGER { picture(0),
+ handwritten-signature(1)} (picture|handwritten-signature,...)
+
+ The predefined biometric type picture, when present, SHALL identify
+ that the source picture is in the form of a displayable graphical
+ image of the subject. The hash of the graphical image SHALL be
+ calculated over the whole referenced image file.
+
+ The predefined biometric type handwritten-signature, when present,
+ SHALL identify that the source data is in the form of a displayable
+ graphical image of the subject's handwritten signature. The hash of
+ the graphical image SHALL be calculated over the whole referenced
+ image file.
+
+
+
+Santesson, et al. Standards Track [Page 12]
+
+RFC 3739 Qualified Certificates Profile March 2004
+
+
+3.2.6. Qualified Certificate Statements
+
+ This section defines an OPTIONAL extension for the inclusion of
+ statements defining explicit properties of the certificate.
+
+ Each statement SHALL include an object identifier for the statement
+ and MAY also include optional qualifying data contained in the
+ statementInfo parameter.
+
+ If the statementInfo parameter is included, then the object
+ identifier of the statement SHALL define the syntax and SHOULD define
+ the semantics of this parameter. If the object identifier does not
+ define the semantics, a relying party may have to consult a relevant
+ certificate policy or CPS to determine the exact semantics.
+
+ This extension may be critical or non-critical. If the extension is
+ critical, this means that all statements included in the extension
+ are regarded as critical.
+
+ qcStatements EXTENSION ::= {
+ SYNTAX QCStatements
+ IDENTIFIED BY id-pe-qcStatements }
+
+ -- NOTE: This extension does not allow to mix critical and
+ -- non-critical Qualified Certificate Statements. Either all
+ -- statements must be critical or all statements must be
+ -- non-critical.
+
+ id-pe-qcStatements OBJECT IDENTIFIER ::= { id-pe 3 }
+
+ QCStatements ::= SEQUENCE OF QCStatement
+ QCStatement ::= SEQUENCE {
+ statementId QC-STATEMENT.&Id({SupportedStatements}),
+ statementInfo QC-STATEMENT.&Type
+ ({SupportedStatements}{@statementId}) OPTIONAL }
+
+ SupportedStatements QC-STATEMENT ::= { qcStatement-1,...}
+
+ A statement suitable for inclusion in this extension MAY be a
+ statement by the issuer that the certificate is issued as a Qualified
+ Certificate in accordance with a particular legal system (as
+ discussed in Section 2.2).
+
+ Other statements suitable for inclusion in this extension MAY be
+ statements related to the applicable legal jurisdiction within which
+ the certificate is issued. As an example, this MAY include a maximum
+ reliance limit for the certificate indicating restrictions on CA's
+ liability.
+
+
+
+Santesson, et al. Standards Track [Page 13]
+
+RFC 3739 Qualified Certificates Profile March 2004
+
+
+3.2.6.1. Predefined Statements
+
+ The certificate statement (id-qcs-pkixQCSyntax-v1), identifies
+ conformance with requirements defined in the obsoleted RFC 3039
+ (Version 1). This statement is thus provided for identification of
+ old certificates issued in conformance with RFC 3039. This statement
+ MUST NOT be included in certificates issued in accordance with this
+ profile.
+
+ This profile includes a new qualified certificate statement
+ (identified by the OID id-qcs-pkixQCSyntax-v2), identifying
+ conformance with requirements defined in this profile. This
+ Qualified Certificate profile is referred to as version 2, while RFC
+ 3039 is referred to as version 1.
+
+ qcStatement-1 QC-STATEMENT ::= { SYNTAX SemanticsInformation
+ IDENTIFIED BY id-qcs-pkixQCSyntax-v1 }
+ -- This statement identifies conformance with requirements
+ -- defined in RFC 3039 (Version 1). This statement may
+ -- optionally contain additional semantics information as
+ -- specified below.
+
+ qcStatement-2 QC-STATEMENT ::= { SYNTAX SemanticsInformation
+ IDENTIFIED BY id-qcs-pkixQCSyntax-v2 }
+ -- This statement identifies conformance with requirements
+ -- defined in this Qualified Certificate profile
+ -- (Version 2). This statement may optionally contain
+ -- additional semantics information as specified below.
+
+ SemanticsInformation ::= SEQUENCE {
+ semanticsIdentifier OBJECT IDENTIFIER OPTIONAL,
+ nameRegistrationAuthorities NameRegistrationAuthorities
+ OPTIONAL }
+ (WITH COMPONENTS {..., semanticsIdentifier PRESENT}|
+ WITH COMPONENTS {..., nameRegistrationAuthorities PRESENT})
+
+ NameRegistrationAuthorities ::= SEQUENCE SIZE (1..MAX) OF
+ GeneralName
+
+ 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.
+
+
+
+
+Santesson, et al. Standards Track [Page 14]
+
+RFC 3739 Qualified Certificates Profile March 2004
+
+
+ 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.
+
+ If a value of type SemanticsInformation is present in a QCStatement
+ where the statementID component is set to id-qcs-pkix-QCSyntax-v1 or
+ id-qcs-pkix-QCSyntax-v2, then at least one of the semanticsIdentifier
+ or nameRegistrationAuthorities fields must be present, as indicated.
+ Note that the statementInfo component need not be present in a
+ QCStatement value even if the statementID component is set to id-
+ qcs-pkix-QCSyntax-v1 or id-qcs-pkix-QCSyntax-v2.
+
+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 has 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
+ depending on the context in which the certificate is to be used.
+ Applications validating electronic signatures based on such
+ certificates should determine whether the present key usage
+ combination is appropriate for their use.
+
+
+
+
+
+Santesson, et al. Standards Track [Page 15]
+
+RFC 3739 Qualified Certificates Profile March 2004
+
+
+ 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 3280. The security
+ considerations section of that document applies to this specification
+ as well.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Santesson, et al. Standards Track [Page 16]
+
+RFC 3739 Qualified Certificates Profile March 2004
+
+
+A. ASN.1 Definitions
+
+ As in RFC 3280, 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 3280 which are not completely in the 1988 syntax, the same
+ comments as in RFC 3280 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
+ 3280's 1988 modules.
+
+ Appendix A.2 is in the 1997 syntax.
+
+ In case of discrepancies between these modules, the 1988 module is
+ the normative one.
+
+A.1. 1988 ASN.1 Module (Normative)
+
+ PKIXqualified88 {iso(1) identified-organization(3) dod(6)
+ internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
+ id-mod-qualified-cert(31) }
+
+ 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(19)}
+
+ AlgorithmIdentifier, DirectoryString, AttributeType, id-pkix, id-pe
+ FROM PKIX1Explicit88 {iso(1) identified-organization(3) dod(6)
+ internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
+ id-pkix1-explicit(18)};
+
+ -- Locally defined OIDs
+
+ -- Arc for QC personal data attributes
+ id-pda OBJECT IDENTIFIER ::= { id-pkix 9 }
+
+
+
+
+
+Santesson, et al. Standards Track [Page 17]
+
+RFC 3739 Qualified Certificates Profile March 2004
+
+
+ -- Arc for QC statements
+ id-qcs OBJECT IDENTIFIER ::= { id-pkix 11 }
+
+ -- Personal data attributes
+
+ 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
+
+ -- Certificate extensions
+
+ -- Biometric info extension
+
+ id-pe-biometricInfo OBJECT IDENTIFIER ::= {id-pe 2}
+
+ 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)
+
+
+
+
+
+
+
+Santesson, et al. Standards Track [Page 18]
+
+RFC 3739 Qualified Certificates Profile March 2004
+
+
+ -- QC Statements Extension
+ -- NOTE: This extension does not allow to mix critical and
+ -- non-critical Qualified Certificate Statements. Either all
+ -- statements must be critical or all statements must be
+ -- non-critical.
+
+ 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 requirements
+ -- defined in RFC 3039 (Version 1). This statement may
+ -- optionally contain additional semantics information as specified
+ -- below.
+
+ id-qcs-pkixQCSyntax-v2 OBJECT IDENTIFIER ::= { id-qcs 2 }
+ -- This statement identifies conformance with requirements
+ -- defined in this Qualified Certificate profile
+ -- (Version 2). 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. 1997 ASN.1 Module (Informative)
+
+ PKIXqualified97 {iso(1) identified-organization(3) dod(6)
+ internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
+ id-mod-qualified-cert-97(35) }
+
+ DEFINITIONS EXPLICIT TAGS ::=
+
+ BEGIN
+
+ -- EXPORTS ALL --
+
+
+
+
+Santesson, et al. Standards Track [Page 19]
+
+RFC 3739 Qualified Certificates Profile March 2004
+
+
+ IMPORTS
+
+ informationFramework, certificateExtensions, selectedAttributeTypes,
+ authenticationFramework, upperBounds, id-at
+ FROM UsefulDefinitions {joint-iso-itu-t(2) ds(5) module(1)
+ usefulDefinitions(0) 3 }
+
+ ub-name
+ FROM UpperBounds upperBounds
+
+ GeneralName
+ FROM CertificateExtensions certificateExtensions
+
+ ATTRIBUTE, AttributeType
+ FROM InformationFramework informationFramework
+
+ DirectoryString
+ FROM SelectedAttributeTypes selectedAttributeTypes
+
+ AlgorithmIdentifier, Extension, EXTENSION
+ FROM AuthenticationFramework authenticationFramework
+
+ id-pkix, id-pe
+ FROM PKIX1Explicit88 { iso(1) identified-organization(3) dod(6)
+ internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
+ id-pkix1-explicit(18) };
+
+ -- 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 }
+
+ -- Personal data attributes
+
+ id-pda-dateOfBirth AttributeType ::= { id-pda 1 }
+ id-pda-placeOfBirth AttributeType ::= { id-pda 2 }
+ id-pda-gender AttributeType ::= { id-pda 3 }
+ id-pda-countryOfCitizenship AttributeType ::= { id-pda 4 }
+ id-pda-countryOfResidence AttributeType ::= { id-pda 5 }
+
+ -- Certificate extensions
+
+ id-pe-biometricInfo OBJECT IDENTIFIER ::= { id-pe 2 }
+ id-pe-qcStatements OBJECT IDENTIFIER ::= { id-pe 3 }
+
+
+
+
+Santesson, et al. Standards Track [Page 20]
+
+RFC 3739 Qualified Certificates Profile March 2004
+
+
+ -- QC statements
+
+ id-qcs-pkixQCSyntax-v1 OBJECT IDENTIFIER ::= { id-qcs 1 }
+ id-qcs-pkixQCSyntax-v2 OBJECT IDENTIFIER ::= { id-qcs 2 }
+
+ -- Personal data attributes
+
+ dateOfBirth ATTRIBUTE ::= {
+ WITH SYNTAX GeneralizedTime
+ ID id-pda-dateOfBirth }
+
+ placeOfBirth ATTRIBUTE ::= {
+ WITH SYNTAX DirectoryString {ub-name}
+ ID id-pda-placeOfBirth }
+
+ gender ATTRIBUTE ::= {
+ WITH SYNTAX PrintableString (SIZE(1) ^ FROM("M"|"F"|"m"|"f"))
+ ID id-pda-gender }
+
+ countryOfCitizenship ATTRIBUTE ::= {
+ WITH SYNTAX PrintableString (SIZE (2))
+ (CONSTRAINED BY { -- ISO 3166 codes only -- })
+ ID id-pda-countryOfCitizenship }
+
+ countryOfResidence ATTRIBUTE ::= {
+ WITH SYNTAX PrintableString (SIZE (2))
+ (CONSTRAINED BY { -- ISO 3166 codes only -- })
+ ID id-pda-countryOfResidence }
+
+ -- Certificate extensions
+
+ -- Biometric info extension
+
+ biometricInfo EXTENSION ::= {
+ SYNTAX BiometricSyntax
+ IDENTIFIED BY id-pe-biometricInfo }
+
+ BiometricSyntax ::= SEQUENCE OF BiometricData
+
+ BiometricData ::= SEQUENCE {
+ typeOfBiometricData TypeOfBiometricData,
+ hashAlgorithm AlgorithmIdentifier,
+ biometricDataHash OCTET STRING,
+ sourceDataUri IA5String OPTIONAL,
+ ... -- For future extensions -- }
+
+ TypeOfBiometricData ::= CHOICE {
+ predefinedBiometricType PredefinedBiometricType,
+
+
+
+Santesson, et al. Standards Track [Page 21]
+
+RFC 3739 Qualified Certificates Profile March 2004
+
+
+ biometricDataOid OBJECT IDENTIFIER }
+
+ PredefinedBiometricType ::= INTEGER {
+ picture(0), handwritten-signature(1)}
+ (picture|handwritten-signature,...)
+
+ -- QC Statements Extension
+ -- NOTE: This extension does not allow to mix critical and
+ -- non-critical Qualified Certificate Statements. Either all
+ -- statements must be critical or all statements must be
+ -- non-critical.
+
+ qcStatements EXTENSION ::= {
+ SYNTAX QCStatements
+ IDENTIFIED BY id-pe-qcStatements }
+
+ QCStatements ::= SEQUENCE OF QCStatement
+
+ QCStatement ::= SEQUENCE {
+ statementId QC-STATEMENT.&id({SupportedStatements}),
+ statementInfo QC-STATEMENT.&Type
+ ({SupportedStatements}{@statementId}) OPTIONAL }
+
+ QC-STATEMENT ::= CLASS {
+ &id OBJECT IDENTIFIER UNIQUE,
+ &Type OPTIONAL }
+ WITH SYNTAX {
+ [SYNTAX &Type] IDENTIFIED BY &id }
+
+ qcStatement-1 QC-STATEMENT ::= { SYNTAX SemanticsInformation
+ IDENTIFIED BY id-qcs-pkixQCSyntax-v1}
+ -- This statement identifies conformance with requirements
+ -- defined in RFC 3039 (Version 1). This statement
+ -- may optionally contain additional semantics information
+ -- as specified below.
+
+ qcStatement-2 QC-STATEMENT ::= { SYNTAX SemanticsInformation
+ IDENTIFIED BY id-qcs-pkixQCSyntax-v2}
+ -- This statement identifies conformance with requirements
+ -- defined in this Qualified Certificate profile
+ -- (Version 2). This statement may optionally contain
+ -- additional semantics information as specified below.
+
+ SemanticsInformation ::= SEQUENCE {
+ semanticsIdentifier OBJECT IDENTIFIER OPTIONAL,
+ nameRegistrationAuthorities NameRegistrationAuthorities OPTIONAL
+ }(WITH COMPONENTS {..., semanticsIdentifier PRESENT}|
+ WITH COMPONENTS {..., nameRegistrationAuthorities PRESENT})
+
+
+
+Santesson, et al. Standards Track [Page 22]
+
+RFC 3739 Qualified Certificates Profile March 2004
+
+
+ NameRegistrationAuthorities ::= SEQUENCE SIZE (1..MAX) OF GeneralName
+
+ -- The following information object set is defined to constrain the
+ -- set of attributes applications are required to recognize as QCSs.
+ SupportedStatements QC-STATEMENT ::= {
+ qcStatement-1 |
+ qcStatement-2 , ... -- For future extensions -- }
+
+ END
+
+B. A Note on Attributes
+
+ This document defines several new attributes, both for use in the
+ subject field of issued certificates and in the
+ subjectDirectoryAttributes extension. A complete definition of these
+ new attributes (including matching rules), along with object classes
+ to support them in LDAP-accessible directories, can be found in
+ PKCS 9 [RFC 2985].
+
+C. Example Certificate
+
+ This section contains the ASN.1 structure, an ASN.1 dump, and the
+ DER-encoding of a certificate issued in conformance with this
+ profile. The example has been developed with the help of the OSS
+ ASN.1 compiler. The certificate has the following characteristics:
+
+ 1. The certificate is signed with RSA and the SHA-1 hash
+ algorithm
+
+ 2. The issuer's distinguished name is (using the syntax specified
+ in [RFC 2253]): O=GMD - Forschungszentrum Informationstechnik
+ GmbH, C=DE
+
+ 3. The subject's distinguished name is (using the syntax
+ specified in [RFC 2253]): GN=Petra+SN=Barzin, O=GMD
+ - Forschungszentrum Informationstechnik GmbH, C=DE
+
+ 4. The certificate was issued on 1 February, 2004 and will expire
+ on 1 February, 2008
+
+ 5. The certificate contains a 1024 bit RSA key
+
+ 6. The certificate includes a critical key usage extension
+ exclusively indicating non-repudiation
+
+ 7. The certificate includes a certificate policy identifier
+ extension indicating the practices and procedures undertaken
+ by the issuing CA (object identifier 1.3.36.8.1.1). The
+
+
+
+Santesson, et al. Standards Track [Page 23]
+
+RFC 3739 Qualified Certificates Profile March 2004
+
+
+ certificate policy object identifier is defined by TeleTrust,
+ Germany.
+
+ 8. The certificate includes a subject directory attributes
+ extension containing the following attributes:
+
+ date of birth: October, 14th 1971
+ place of birth: Darmstadt
+ country of citizenship:Germany
+ gender: Female
+
+ 9. The certificate includes a qualified statement certificate
+ extension indicating that the naming registration authority's
+ name is "municipality@darmstadt.de".
+
+ 10. The certificate includes, in conformance with RFC 3280, an
+ authority key identifier extension.
+
+C.1. ASN.1 Structure
+
+C.1.1. Extensions
+
+ Since extensions are DER-encoded already when placed in the structure
+ to be signed, they are, for clarity, shown here in the value notation
+ defined in [X.680].
+
+C.1.1.1. The subjectDirectoryAttributes Extension
+
+ certSubjDirAttrs AttributesSyntax ::= {
+ {
+ type id-pda-countryOfCitizenship,
+ values {
+ PrintableString : "DE"
+ }
+ },
+ {
+ type id-pda-gender,
+ values {
+ PrintableString : "F"
+ }
+ },
+ {
+ type id-pda-dateOfBirth,
+ values {
+ GeneralizedTime : "197110141200Z"
+ }
+ },
+ {
+
+
+
+Santesson, et al. Standards Track [Page 24]
+
+RFC 3739 Qualified Certificates Profile March 2004
+
+
+ type id-pda-placeOfBirth,
+ values {
+ DirectoryString : utf8String : "Darmstadt"
+ }
+ }
+ }
+
+C.1.1.2. The keyUsage Extension
+
+ certKeyUsage KeyUsage ::= {nonRepudiation}
+
+C.1.1.3. The certificatePolicies Extension
+
+ certCertificatePolicies CertificatePoliciesSyntax ::= {
+ {
+ policyIdentifier {1 3 36 8 1 1}
+ }
+ }
+
+C.1.1.4. The qcStatements Extension
+
+ certQCStatement QCStatements ::= {
+ {
+ statementId id-qcs-pkixQCSyntax-v2,
+ statementInfo SemanticsInformation : {
+ nameRegistrationAuthorities {
+ rfc822Name : "municipality@darmstadt.de"
+ }
+ }
+ }
+ }
+
+C.1.1.5. The authorityKeyIdentifier Extension
+
+ certAKI AuthorityKeyIdentifier ::= {
+ keyIdentifier '000102030405060708090A0B0C0D0E0FFEDCBA98'H
+ }
+
+C.1.2. The Certificate
+
+ The signed portion of the certificate is shown here in the value
+ notation defined in [X.680]. Note that extension values are already
+ DER encoded in this structure. Some values have been truncated for
+ readability purposes.
+
+ certCertInfo CertificateInfo ::= {
+ version v3,
+ serialNumber 1234567890,
+
+
+
+Santesson, et al. Standards Track [Page 25]
+
+RFC 3739 Qualified Certificates Profile March 2004
+
+
+ signature
+ {
+ algorithm { 1 2 840 113549 1 1 5 },
+ parameters RSAParams : NULL
+ },
+ issuer rdnSequence :
+ {
+ {
+ {
+ type { 2 5 4 6 },
+ value PrintableString : "DE"
+ }
+ },
+ {
+ {
+ type { 2 5 4 10 },
+ value UTF8String :
+ }
+ }
+ },
+ validity
+ {
+ notBefore utcTime : "040201100000Z",
+ notAfter utcTime : "080201100000Z"
+ },
+ subject rdnSequence :
+ {
+ {
+ {
+ type { 2 5 4 6 },
+ value PrintableString : "DE"
+ }
+ },
+ {
+ {
+ type { 2 5 4 10 },
+ value UTF8String :
+ "GMD Forschungszentrum Informationstechnik GmbH"
+ }
+ },
+ {
+ {
+ type { 2 5 4 4 },
+ value UTF8String : "Barzin"
+ },
+ {
+ type { 2 5 4 42 },
+ value UTF8String : "Petra"
+
+
+
+Santesson, et al. Standards Track [Page 26]
+
+RFC 3739 Qualified Certificates Profile March 2004
+
+
+ }
+ }
+ },
+ subjectPublicKeyInfo
+ {
+ algorithm
+ {
+ algorithm { 1 2 840 113549 1 1 1 },
+ parameters RSAParams : NULL
+ },
+ subjectPublicKey '30818902818100DCE74CD5...0203010001'H
+ },
+ extensions
+ {
+ {
+ extnId { 2 5 29 9 }, -- subjectDirectoryAttributes
+ extnValue '305B301006082B0601050507090...7374616474'H
+ },
+ {
+ extnId { 2 5 29 15 }, -- keyUsage
+ critical TRUE,
+ extnValue '03020640'H
+ },
+ {
+ extnId { 2 5 29 32 }, -- certificatePolicies
+ extnValue '3009300706052B24080101'H
+ },
+ {
+ extnId { 2 5 29 35 }, -- authorityKeyIdentifier
+ extnValue '30168014000102030405060708090A0B0C0D0E0FFEDCBA98'H
+ },
+ {
+ extnId { 1 3 6 1 5 5 7 1 3 }, -- qcStatements
+ extnValue '302B302906082B06010505070B0...4742E6465 'H
+ }
+ }
+ }
+
+C.2. ASN.1 Dump
+
+ This section contains an ASN.1 dump of the signed portion of the
+ certificate. Some values have been truncated for readability
+ purposes.
+
+CertificateInfo SEQUENCE: tag = [UNIVERSAL 16] constructed; length = 633
+ version : tag = [0] constructed; length = 3
+ Version INTEGER: tag = [UNIVERSAL 2] primitive; length = 1
+ 2
+
+
+
+Santesson, et al. Standards Track [Page 27]
+
+RFC 3739 Qualified Certificates Profile March 2004
+
+
+ serialNumber CertificateSerialNumber INTEGER: tag = [UNIVERSAL 2]
+ primitive; length = 4
+ 1234567890
+ signature AlgorithmIdentifier SEQUENCE: tag = [UNIVERSAL 16]
+ constructed; length = 13
+ algorithm OBJECT IDENTIFIER: tag = [UNIVERSAL 6]
+ primitive; length = 9
+ { 1 2 840 113549 1 1 5 }
+ parameters OpenType
+ NULL
+ issuer Name CHOICE
+ rdnSequence RDNSequence SEQUENCE OF: tag = [UNIVERSAL 16]
+ constructed; length = 72
+ RelativeDistinguishedName SET OF: tag = [UNIVERSAL 17]
+ constructed; length = 11
+ AttributeTypeAndValue SEQUENCE: tag = [UNIVERSAL 16]
+ constructed; length = 9
+ type OBJECT IDENTIFIER: tag = [UNIVERSAL 6]
+ primitive; length = 3
+ { 2 5 4 6 } -- id-at-countryName
+ value PrintableString
+ "DE"
+ RelativeDistinguishedName SET OF: tag = [UNIVERSAL 17]
+ constructed; length = 57
+ AttributeTypeAndValue SEQUENCE: tag = [UNIVERSAL 16]
+ constructed; length = 55
+ type OBJECT IDENTIFIER: tag = [UNIVERSAL 6]
+ primitive; length = 3
+ { 2 5 4 10 } -- id-at-organizationName
+ value UTF8String
+ "GMD Forschungszentrum Informationstechnik GmbH"
+ validity Validity SEQUENCE: tag = [UNIVERSAL 16]
+ constructed; length = 30
+ notBefore Time CHOICE
+ utcTime UTCTime: tag = [UNIVERSAL 23] primitive; length = 13
+ 040201100000Z
+ notAfter Time CHOICE
+ utcTime UTCTime: tag = [UNIVERSAL 23] primitive; length = 13
+ 080201100000Z
+ subject Name CHOICE
+ rdnSequence RDNSequence SEQUENCE OF: tag = [UNIVERSAL 16]
+ constructed; length = 101
+ RelativeDistinguishedName SET OF: tag = [UNIVERSAL 17]
+ constructed; length = 11
+ AttributeTypeAndValue SEQUENCE: tag = [UNIVERSAL 16]
+ constructed; length = 9
+ type OBJECT IDENTIFIER: tag = [UNIVERSAL 6]
+ primitive; length = 3
+
+
+
+Santesson, et al. Standards Track [Page 28]
+
+RFC 3739 Qualified Certificates Profile March 2004
+
+
+ { 2 5 4 6 } -- id-at-countryName
+ value PrintableString
+ "DE"
+ RelativeDistinguishedName SET OF: tag = [UNIVERSAL 17]
+ constructed; length = 55
+ AttributeTypeAndValue SEQUENCE: tag = [UNIVERSAL 16]
+ constructed; length = 53
+ type OBJECT IDENTIFIER: tag = [UNIVERSAL 6]
+ primitive; length = 3
+ { 2 5 4 10 } -- id-at-organizationName
+ value UTF8String
+ "GMD Forschungszentrum Informationstechnik GmbH"
+ RelativeDistinguishedName SET OF: tag = [UNIVERSAL 17]
+ constructed; length = 29
+ AttributeTypeAndValue SEQUENCE: tag = [UNIVERSAL 16]
+ constructed; length = 13
+ type OBJECT IDENTIFIER: tag = [UNIVERSAL 6]
+ primitive; length = 3
+ { 2 5 4 4 } -- id-at-surname
+ value UTF8String
+ "Barzin"
+ AttributeTypeAndValue SEQUENCE: tag = [UNIVERSAL 16]
+ constructed; length = 12
+ type OBJECT IDENTIFIER: tag = [UNIVERSAL 6]
+ primitive; length = 3
+ { 2 5 4 42 } -- id-at-givenName
+ value UTF8String
+ "Petra"
+ subjectPublicKeyInfo SubjectPublicKeyInfo SEQUENCE:
+ tag = [UNIVERSAL 16] constructed; length = 159
+ algorithm AlgorithmIdentifier SEQUENCE: tag = [UNIVERSAL 16]
+ constructed; length = 13
+ algorithm OBJECT IDENTIFIER: tag = [UNIVERSAL 6]
+ primitive; length = 9
+ { 1 2 840 113549 1 1 1 } -- rsaEncryption
+ parameters OpenType
+ NULL
+ subjectPublicKey BIT STRING: tag = [UNIVERSAL 3]
+ primitive; length = 141
+ 0x0030818902818100dce74cd5a1d55aeb01cf5ecc20f3c3fca787...
+ extensions : tag = [3] constructed; length = 233
+ Extensions SEQUENCE OF: tag = [UNIVERSAL 16]
+ constructed; length = 230
+ Extension SEQUENCE: tag = [UNIVERSAL 16]
+ constructed; length = 100
+ extnId OBJECT IDENTIFIER: tag = [UNIVERSAL 6]
+ primitive; length = 3
+ { 2 5 29 9 } -- id-ce-subjectDirectoryAttributes
+
+
+
+Santesson, et al. Standards Track [Page 29]
+
+RFC 3739 Qualified Certificates Profile March 2004
+
+
+ extnValue OCTET STRING: tag = [UNIVERSAL 4]
+ primitive; length = 93
+ 0x305b301006082b06010505070904310413024445300f06082...
+ Extension SEQUENCE: tag = [UNIVERSAL 16]
+ constructed; length = 14
+ extnId OBJECT IDENTIFIER: tag = [UNIVERSAL 6]
+ primitive; length = 3
+ { 2 5 29 15 } -- id-ce-keyUsage
+ critical BOOLEAN: tag = [UNIVERSAL 1] primitive; length = 1
+ TRUE
+ extnValue OCTET STRING: tag = [UNIVERSAL 4]
+ primitive; length = 4
+ 0x03020640
+ Extension SEQUENCE: tag = [UNIVERSAL 16]
+ constructed; length = 18
+ extnId OBJECT IDENTIFIER: tag = [UNIVERSAL 6]
+ primitive; length = 3
+ { 2 5 29 32 } -- id-ce-certificatePolicies
+ extnValue OCTET STRING: tag = [UNIVERSAL 4]
+ primitive; length = 11
+ 0x3009300706052b24080101
+ Extension SEQUENCE: tag = [UNIVERSAL 16]
+ constructed; length = 31
+ extnId OBJECT IDENTIFIER: tag = [UNIVERSAL 6]
+ primitive; length = 3
+ { 2 5 29 35 } -- id-ce-authorityKeyIdentifier
+ extnValue OCTET STRING: tag = [UNIVERSAL 4]
+ primitive; length = 24
+ 0x30168014000102030405060708090a0b0c0d0e0ffedcba98
+ Extension SEQUENCE: tag = [UNIVERSAL 16]
+ constructed; length = 57
+ extnId OBJECT IDENTIFIER: tag = [UNIVERSAL 6]
+ primitive; length = 8
+ { 1 3 6 1 5 5 7 1 3 } -- id-pe-qcStatements
+ extnValue OCTET STRING: tag = [UNIVERSAL 4]
+ primitive; length = 45
+ 0x302b302906082b06010505070b02301d301b81196d756e696...
+
+C.3 DER-encoding
+
+ This section contains the full, DER-encoded certificate, in hex.
+
+30820310 30820279 A0030201 02020449 9602D230 0D06092A 864886F7 0D010105
+05003048 310B3009 06035504 06130244 45313930 37060355 040A0C30 474D4420
+2D20466F 72736368 756E6773 7A656E74 72756D20 496E666F 726D6174 696F6E73
+74656368 6E696B20 476D6248 301E170D 30343032 30313130 30303030 5A170D30
+38303230 31313030 3030305A 3065310B 30090603 55040613 02444531 37303506
+0355040A 0C2E474D 4420466F 72736368 756E6773 7A656E74 72756D20 496E666F
+
+
+
+Santesson, et al. Standards Track [Page 30]
+
+RFC 3739 Qualified Certificates Profile March 2004
+
+
+726D6174 696F6E73 74656368 6E696B20 476D6248 311D300C 06035504 2A0C0550
+65747261 300D0603 5504040C 06426172 7A696E30 819F300D 06092A86 4886F70D
+01010105 0003818D 00308189 02818100 DCE74CD5 A1D55AEB 01CF5ECC 20F3C3FC
+A787CFCB 571A21AA 8A20AD5D FF015130 DE724E5E D3F95392 E7BB16C4 A71D0F31
+B3A9926A 8F08EA00 FDC3A8F2 BB016DEC A3B9411B A2599A2A 8CB655C6 DFEA25BF
+EDDC73B5 94FAA0EF E595C612 A6AE5B8C 7F0CA19C EC4FE7AB 60546768 4BB2387D
+5F2F7EBD BC3EF0A6 04F6B404 01176925 02030100 01A381E9 3081E630 64060355
+1D09045D 305B3010 06082B06 01050507 09043104 13024445 300F0608 2B060105
+05070903 31031301 46301D06 082B0601 05050709 01311118 0F313937 31313031
+34313230 3030305A 30170608 2B060105 05070902 310B0C09 4461726D 73746164
+74300E06 03551D0F 0101FF04 04030206 40301206 03551D20 040B3009 30070605
+2B240801 01301F06 03551D23 04183016 80140001 02030405 06070809 0A0B0C0D
+0E0FFEDC BA983039 06082B06 01050507 0103042D 302B3029 06082B06 01050507
+0B02301D 301B8119 6D756E69 63697061 6C697479 40646172 6D737461 64742E64
+65300D06 092A8648 86F70D01 01050500 03818100 8F8C80BB B2D86B75 F4E21F82
+EFE0F20F 6C558890 A6E73118 8359B9C7 8CE71C92 0C66C600 53FBC924 825090F2
+95B08826 EAF3FF1F 5917C80B B4836129 CFE5563E 78592B5B B0F9ACB5 2915F0F2
+BC36991F 21436520 E9064761 D932D871 F71FFEBD AD648FA7 CF3C1BC0 96F112D4
+B882B39F E1A16A90 AE1A80B8 A9676518 B5AA7E97
+
+C.4. CA's Public RSA Key
+
+ This section contains the DER-encoded public RSA key of the CA who
+ signed the example certificate. It is included with the purpose of
+ simplifying verifications of the example certificate.
+
+ 30818902818100c88f4bdb66f713ba3dd7a9069880e888d4321acb53cda7fcdf
+ da89b834e25430b956d46a438baa6798035af30db378424e00a8296b012b1b24
+ f9cf0b3f83be116cd8a36957dc3f54cbd7c58a10c380b3dfa15bd2922ea8660f
+ 96e1603d81357c0442ad607c5161d083d919fd5307c1c3fa6dfead0e6410999e
+ 8b8a8411d525dd0203010001
+
+References
+
+Normative 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 2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
+
+
+
+
+
+
+
+Santesson, et al. Standards Track [Page 31]
+
+RFC 3739 Qualified Certificates Profile March 2004
+
+
+ [RFC 2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object
+ Classes and Attribute Types Version 2.0", RFC 2985,
+ November 2000.
+
+ [RFC 3280] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet
+ X.509 Public Key Infrastructure: Certificate and
+ Certificate Revocation List (CRL) Profile", RFC 3280,
+ April 2002.
+
+ [X.509] ITU-T Recommendation X.509 (2000) | ISO/IEC 9594-8:2001,
+ Information technology - Open Systems Interconnection -
+ The Directory: Public-key and attribute certificate
+ frameworks
+
+ [X.520] ITU-T Recommendation X.520 (2001) | ISO/IEC 9594-6:2001,
+ Information Technology - Open Systems Interconnection -
+ The Directory: Selected Attribute Types, 2001.
+
+ [X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002),
+ Information Technology - Abstract Syntax Notation One,
+ 2002.
+
+ [ISO 3166] ISO 3166-1:1997, Codes for the representation of names of
+ countries, 1997.
+
+ [HTTP/1.1] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
+ Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext
+ Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
+
+Informative References
+
+ [X.501] ITU-T recommendation X.501 (2001) | ISO/IEC 9594-2:2001,
+ Information Technology - Open Systems Interconnection -
+ The Directory: Models, 2001.
+
+ [EU-ESDIR] Directive 1999/93/EC of the European Parliament and of the
+ Council of 13 December 1999 on a Community framework for
+ electronic signatures, 1999.
+
+ [RFC 2253] Wahl, M., Kille, S. and T. Howes, "Lightweight Directory
+ Access Protocol (v3): UTF-8 String Representation of
+ Distinguished Names", RFC 2253, December 1997.
+
+
+
+
+
+
+
+
+
+Santesson, et al. Standards Track [Page 32]
+
+RFC 3739 Qualified Certificates Profile March 2004
+
+
+Authors' Addresses
+
+ Stefan Santesson
+ Microsoft Denmark
+ Tuborg Boulevard 12
+ DK-2900 Hellerup
+ Denmark
+
+ EMail: stefans@microsoft.com
+
+
+ Tim Polk
+ NIST
+ Building 820, Room 426
+ Gaithersburg, MD 20899, USA
+
+ EMail: wpolk@nist.gov
+
+
+ Magnus Nystrom
+ RSA Security
+ Box 10704
+ S-121 29 Stockholm
+ Sweden
+
+ EMail: magnus@rsasecurity.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Santesson, et al. Standards Track [Page 33]
+
+RFC 3739 Qualified Certificates Profile March 2004
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2004). This document is subject
+ to the rights, licenses and restrictions contained in BCP 78 and
+ except as set forth therein, the authors retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
+ REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
+ INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
+ IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+ THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights 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; nor does it
+ represent that it has made any independent effort to identify any
+ such rights. Information on the procedures with respect to
+ rights in RFC documents can be found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository
+ at http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention
+ any copyrights, patents or patent applications, or other
+ proprietary rights that may cover technology that may be required
+ to implement this standard. Please address the information to the
+ IETF at ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+Santesson, et al. Standards Track [Page 34]
+