diff options
Diffstat (limited to 'doc/protocol/rfc3039.txt')
| -rw-r--r-- | doc/protocol/rfc3039.txt | 1963 |
1 files changed, 0 insertions, 1963 deletions
diff --git a/doc/protocol/rfc3039.txt b/doc/protocol/rfc3039.txt deleted file mode 100644 index 983dc156c3..0000000000 --- a/doc/protocol/rfc3039.txt +++ /dev/null @@ -1,1963 +0,0 @@ - - - - - - -Network Working Group S. Santesson -Request for Comments: 3039 AddTrust -Category: Standards Track W. Polk - NIST - P. Barzin - SECUDE - M. Nystrom - RSA Security - January 2001 - - - 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 (2001). All Rights Reserved. - -Abstract - - This document forms a certificate profile for Qualified Certificates, - based on RFC 2459, for use in the Internet. The term Qualified - Certificate is used to describe a certificate with a certain - qualified status within applicable governing law. Further, Qualified - Certificates are issued exclusively to physical persons. - - The goal of this document is to define a general syntax independent - of local legal requirements. The profile is however designed to - allow further profiling in order to meet specific local needs. - - It is important to note that the profile does not define any legal - requirements for Qualified Certificates. - - 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 RFC 2119. - - - - - - - -Santesson, et al. Standards Track [Page 1] - -RFC 3039 Qualified Certificates Profile January 2001 - - -Table of Contents - - 1 Introduction ................................................ 2 - 2 Requirements and Assumptions ................................ 3 - 2.1 Properties ................................................ 4 - 2.2 Statement of Purpose ...................................... 5 - 2.3 Policy Issues ............................................. 5 - 2.4 Uniqueness of names ....................................... 5 - 3 Certificate and Certificate Extensions Profile .............. 6 - 3.1 Basic Certificate Fields .................................. 6 - 3.1.1 Issuer .................................................. 6 - 3.1.2 Subject ................................................. 6 - 3.2 Certificate Extensions .................................... 9 - 3.2.1 Subject Directory Attributes ............................ 9 - 3.2.2 Certificate Policies .................................... 10 - 3.2.3 Key Usage ............................................... 10 - 3.2.4 Biometric Information ................................... 11 - 3.2.5 Qualified Certificate Statements ........................ 12 - 4 Security Considerations ..................................... 14 - 5 References .................................................. 15 - 6 Intellectual Property Rights ................................ 16 - A ASN.1 definitions ........................................... 17 - A.1 1988 ASN.1 Module ......................................... 17 - A.2 1993 ASN.1 Module ......................................... 19 - B A Note on Attributes ........................................ 24 - C. Example Certificate ........................................ 24 - C.1 ASN.1 Structure ........................................... 25 - C.1.1 Extensions ............................................... 25 - C.1.2 The certificate .......................................... 27 - C.2 ASN.1 Dump ................................................ 29 - C.3 DER-encoding .............................................. 32 - C.4 CA's public key ........................................... 33 - Authors' Addresses ............................................. 34 - Full Copyright Statement ....................................... 35 - -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 RFC - 2459, which defines underlying certificate formats and semantics - needed for a full implementation of this standard. - - The standard profiles the format for a specific type of certificates - named Qualified Certificates. The term Qualified Certificates and - the assumptions that affects the scope of this document are discussed - in Section 2. - - - - - -Santesson, et al. Standards Track [Page 2] - -RFC 3039 Qualified Certificates Profile January 2001 - - - Section 3 defines requirements on information content in Qualified - Certificates. This profile addresses two fields in the basic - certificate as well as five certificate extensions. The certificate - fields are the subject and issuer fields. The certificate extensions - are subject directory attributes, certificate policies, key usage, a - private extension for storage of biometric data and a private - extension for storage of statements related to Qualified - Certificates. The private extensions are presented in the 1993 - Abstract Syntax Notation One (ASN.1), but in conformance with RFC - 2459 the 1988 ASN.1 module in Appendix A contains all normative - definitions (the 1993 module in Appendix A is informative). - - In Section 4, some security considerations are discussed in order to - clarify the security context in which Qualified Certificates are - assumed to be utilized. Section 5 contains the references. - - Appendix A contains all relevant ASN.1 [X.680] structures that are - not already defined in RFC 2459. Appendix B contains a note on - attributes. Appendix C contains an example certificate. Appendix D - contains authors' addresses and Appendix E contains the IETF - Copyright Statement. - - It should be noted that this specification does not define the - specific semantics of Qualified Certificates, and does not define the - policies that should be used with them. That is, this document - defines what information should go into Qualified Certificates, but - not what that information means. A system that uses Qualified - Certificates must define its own semantics for the information in - Qualified Certificates. It is expected that laws and corporate - policies will make these definitions. - -2 Requirements and Assumptions - - The term "Qualified Certificate" has been used by the European - Commission to describe a certain type of certificates with specific - relevance for European 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 more - generally, describing the format for a certificate whose primary - purpose is identifying a person with high level of assurance in - public non-repudiation services. The actual mechanisms that will - decide whether a certificate should or should not be considered to be - a "Qualified Certificate" in regard to any legislation are outside - the scope of this standard. - - - - - -Santesson, et al. Standards Track [Page 3] - -RFC 3039 Qualified Certificates Profile January 2001 - - - Harmonization in the field of Qualified Certificates is essential - within several aspects that fall outside the scope of RFC 2459. 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. - -2.1 Properties - - A Qualified Certificate as defined in this standard is assumed to - have the following properties: - - - The certificate is issued by a CA that makes a public statement - that the certificate serves the purpose of a Qualified - Certificate, as discussed in Section 2.2 - - - The certificate indicates a certificate policy consistent with - liabilities, practices and procedures undertaken by the CA, as - discussed in 2.3 - - - The certificate is issued to a natural person (living human - being). - - - The certificate contains an identity based on a pseudonym or a - real name of the subject. - - - - - - - - - - -Santesson, et al. Standards Track [Page 4] - -RFC 3039 Qualified Certificates Profile January 2001 - - -2.2 Statement of Purpose - - For a certificate to serve the purpose of being a Qualified - Certificate, this profile assumes that the CA will have to include in - the certificate information that explicitly defines this intent. - - The function of this information 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 complementary 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 assumed that the issuing CA will undertake to follow a - publicly available certificate policy that is consistent with its - liabilities, practices and procedures. - -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 the set of all objects. An - object can be assigned a distinguished name without being represented - by an entry in the Directory, but this name is then the name its - object entry could have had if it were represented in the Directory. - In the context of qualified certificates, a distinguished name - denotes a set of attribute values [X.501] which forms a name that is - unambiguous within a certain domain that forms either a real or a - virtual DIT (Directory Information Tree)[X.501]. In the case of - subject names the domain is assumed to be at least the issuing domain - of the CA. The distinguished name MUST be unique for each subject - entity certified by the one CA as defined by the issuer name field, - during the whole life time of the CA. - - - - -Santesson, et al. Standards Track [Page 5] - -RFC 3039 Qualified Certificates Profile January 2001 - - -3 Certificate and Certificate Extensions Profile - - This section defines a profile for Qualified Certificates. The - profile is based on the Internet certificate profile RFC 2459 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 2459. - - ASN.1 definitions relevant for this section that are not supplied by - RFC 2459 are supplied in Appendix A. - -3.1 Basic Certificate Fields - - This specification 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 identity of the issuer SHALL be specified using an appropriate - subset of the following attributes: - - domainComponent; - countryName; - stateOrProvinceName; - organizationName; - localityName; and - serialNumber. - - Additional attributes MAY be present but they SHOULD NOT be necessary - to identify the issuing organization. - - Attributes present in the issuer field SHOULD be consistent with the - laws under which the issuer operates. - - 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 and the laws under which the issuer operates. - -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). - - - -Santesson, et al. Standards Track [Page 6] - -RFC 3039 Qualified Certificates Profile January 2001 - - - The subject field SHALL contain an appropriate subset of the - following attributes: - - countryName; - commonName; - surname; - givenName; - pseudonym; - serialNumber; - organizationName; - organizationalUnitName; - stateOrProvinceName - localityName and - postalAddress. - - Other attributes may be present but MUST NOT be necessary to - distinguish the subject name from other subject names within the - issuer domain. - - 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. - - 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. - - - - - - -Santesson, et al. Standards Track [Page 7] - -RFC 3039 Qualified Certificates Profile January 2001 - - - 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, if present, contain - the registered name of the subject, in accordance with the laws under - which the CA prepares the certificate. These attributes SHALL be - used in the subject field if the commonName attribute is not present. - In cases where the subject only has a single name registered, the - givenName attribute SHALL be used and 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 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 associated. - The type of association between the organization and the subject is - beyond the scope of this document. - - The postalAddress, the stateOrProvinceName and the localityName - attribute types SHALL, when present, be used to store address and - geographical information with which the subject is associated. If an - organizationName value also is present then the postalAddress, - stateOrProvinceName and localityName attribute values SHALL be - associated with the specified organization. The type of association - between the postalAddress, 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. - - - - - - - - -Santesson, et al. Standards Track [Page 8] - -RFC 3039 Qualified Certificates Profile January 2001 - - -3.2 Certificate Extensions - - This specification provides additional details regarding the contents - of five certificate extensions. These extensions are the subject - directory attributes, certificate policies, key usage, private - extension for biometric information and private extension for - Qualified Certificate statements. - -3.2.1 Subject Directory Attributes - - The subjectDirectoryAttributes extension MAY contain additional - attributes, associated with the subject, as 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: - - title; - dateOfBirth; - placeOfBirth; - gender; - countryOfCitizenship; and - countryOfResidence. - - Other attributes MAY be included according to local definitions. - - 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 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 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. - - - -Santesson, et al. Standards Track [Page 9] - -RFC 3039 Qualified Certificates Profile January 2001 - - - 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 that the certificate was issued. If the - subject is a citizen of more than one country, more than one country - MAY be present. 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 - the subject is a resident of more than one country, more than one - country MAY be present. Determination of residence is a matter of - law and is outside the scope of this document. - -3.2.2 Certificate Policies - - The certificate policies extension 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 SHOULD include all policy - information needed for validation of the certificate. If policy - information is included in the QCStatements extension (see 3.2.5), - then this information SHOULD also be defined by indicated policies. - - Certificate policies MAY be combined with any qualifier defined in - RFC 2459. - -3.2.3 Key Usage - - The key usage extension SHALL be present. If the key usage - nonRepudiation bit is asserted then it SHOULD NOT be combined with - any other key usage , i.e., if set, the key usage non-repudiation - SHOULD be set exclusively. - - The key usage extension MAY be marked critical. - - - - - -Santesson, et al. Standards Track [Page 10] - -RFC 3039 Qualified Certificates Profile January 2001 - - -3.2.4 Biometric Information - - This section defines an 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 means for authentication - of biometric information. The biometric information that corresponds - to the stored hash is not stored in this extension, but the extension - MAY include an URI pointing to a location where this information can - be obtained. If included, this URI does not imply that this is the - only way to access this information. - - It is RECOMMENDED that biometric information in this extension is - 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,...) - - - - - - - -Santesson, et al. Standards Track [Page 11] - -RFC 3039 Qualified Certificates Profile January 2001 - - - 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 only be - calculated over the image data excluding any labels defining the - image type. - - 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 only be calculated over the image data - excluding any labels defining the image type. - -3.2.5 Qualified Certificate Statements - - This section defines an extension for inclusion of defined statements - related to Qualified Certificates. - - A typical 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. - - 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 } - - id-pe-qcStatements OBJECT IDENTIFIER ::= { id-pe 3 } - - - - -Santesson, et al. Standards Track [Page 12] - -RFC 3039 Qualified Certificates Profile January 2001 - - - QCStatements ::= SEQUENCE OF QCStatement - - QCStatement ::= SEQUENCE { - statementId QC-STATEMENT.&Id({SupportedStatements}), - statementInfo QC-STATEMENT.&Type - ({SupportedStatements}{@statementId}) OPTIONAL } - - SupportedStatements QC-STATEMENT ::= { qcStatement-1,...} - -3.2.5.1 Predefined Statements - - This profile includes one predefined object identifier (id-qcs- - pkixQCSyntax-v1), identifying conformance with syntax and semantics - defined in this profile. This Qualified Certificate profile is - referred to as version 1. - - qcStatement-1 QC-STATEMENT ::= { SYNTAX SemanticsInformation - IDENTIFIED BY id-qcs-pkixQCSyntax-v1 } - -- This statement identifies conformance with syntax and - -- semantics defined in this Qualified Certificate profile - -- (Version 1). The SemanticsInformation may optionally contain - -- additional semantics information as specified. - - 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. - - 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) } - - - -Santesson, et al. Standards Track [Page 19] - -RFC 3039 Qualified Certificates Profile January 2001 - - -DEFINITIONS EXPLICIT TAGS ::= - -BEGIN - --- EXPORTS ALL -- - -IMPORTS - -authorityKeyIdentifier, subjectKeyIdentifier, keyUsage, - extendedKeyUsage, privateKeyUsagePeriod, certificatePolicies, - policyMappings, subjectAltName, issuerAltName, basicConstraints, - nameConstraints, policyConstraints, cRLDistributionPoints, - subjectDirectoryAttributes, authorityInfoAccess, GeneralName, - OTHER-NAME - FROM PKIX1Implicit93 {iso(1) identified-organization(3) dod(6) - internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) - id-pkix1-implicit-93(4)} - -id-pkix, AlgorithmIdentifier, ATTRIBUTE, Extension, EXTENSION, - DirectoryString{}, ub-name, id-pe, id-at, id-at-commonName, - id-at-surname, id-at-countryName, id-at-localityName, - id-at-stateOrProvinceName, id-at-organizationName, - id-at-organizationalUnitName, id-at-givenName, id-at-dnQualifier, - pkcs9email, title, organizationName, organizationalUnitName, - stateOrProvinceName, localityName, countryName, - generationQualifier, dnQualifier, initials, givenName, surname, - commonName, name - FROM PKIX1Explicit93 {iso(1) identified-organization(3) dod(6) - internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) - id-pkix1-explicit-93(3)}; - --- Object Identifiers - --- Externally defined OIDs -id-at-serialNumber OBJECT IDENTIFIER ::= { id-at 5} -id-at-postalAddress OBJECT IDENTIFIER ::= { id-at 16 } -id-at-pseudonym OBJECT IDENTIFIER ::= { id-at 65 } -id-domainComponent OBJECT IDENTIFIER ::= { 0 9 2342 19200300 100 1 25 } - --- 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 } - --- Private extensions - - - -Santesson, et al. Standards Track [Page 20] - -RFC 3039 Qualified Certificates Profile January 2001 - - -id-pe-biometricInfo OBJECT IDENTIFIER ::= { id-pe 2 } -id-pe-qcStatements OBJECT IDENTIFIER ::= { id-pe 3 } - --- Personal data attributes -id-pda-dateOfBirth OBJECT IDENTIFIER ::= { id-pda 1 } -id-pda-placeOfBirth OBJECT IDENTIFIER ::= { id-pda 2 } -id-pda-gender OBJECT IDENTIFIER ::= { id-pda 3 } -id-pda-countryOfCitizenship OBJECT IDENTIFIER ::= { id-pda 4 } -id-pda-countryOfResidence OBJECT IDENTIFIER ::= { id-pda 5 } - --- QC statements -id-qcs-pkixQCSyntax-v1 OBJECT IDENTIFIER ::= { id-qcs 1 } - --- Object Sets - --- The following information object set is defined to constrain the --- set of legal certificate extensions. Note that this set is an --- extension of the ExtensionSet defined in RFC 2459. -ExtensionSet EXTENSION ::= { - authorityKeyIdentifier | - subjectKeyIdentifier | - keyUsage | - extendedKeyUsage | - privateKeyUsagePeriod | - certificatePolicies | - policyMappings | - subjectAltName | - issuerAltName | - basicConstraints | - nameConstraints | - policyConstraints | - cRLDistributionPoints | - subjectDirectoryAttributes | - authorityInfoAccess | - biometricInfo | - qcStatements, ... } - --- The following information object set is defined to constrain the --- set of attributes applications are required to recognize in --- distinguished names. The set may of course be augmented to meet --- local requirements. Note that deleting members of the set may --- prevent interoperability with conforming implementations, and that --- this set is an extension of the SupportedAttributes set in RFC 2459. - -SupportedAttributes ATTRIBUTE ::= { - countryName | commonName | surname | givenName | pseudonym | - serialNumber | organizationName | organizationalUnitName | - stateOrProvinceName | localityName | postalAddress | - - - -Santesson, et al. Standards Track [Page 21] - -RFC 3039 Qualified Certificates Profile January 2001 - - - pkcs9email | domainComponent | dnQualifier, - ... -- For future extensions -- } - --- The following information object set is defined to constrain the --- set of attributes applications are required to recognize in --- subjectDirectoryAttribute extensions. The set may be augmented to --- meet local requirements. Note that deleting members of the set --- may prevent interoperability with conforming implementations. -PersonalDataAttributeSet ATTRIBUTE ::= { - title | dateOfBirth | placeOfBirth | gender | countryOfCitizenship | - countryOfResidence, ... } - --- Attributes - --- serialNumber from X.520 -serialNumber ATTRIBUTE ::= { - WITH SYNTAX PrintableString (SIZE(1..64)) - ID id-at-serialNumber } - --- postalAddress from X.520 -postalAddress ATTRIBUTE ::= { - WITH SYNTAX SEQUENCE SIZE (1..6) OF DirectoryString { 30 } - ID id-at-postalAddress } - --- pseudonym from (forthcoming) X.520) -pseudonym ATTRIBUTE ::= { - WITH SYNTAX DirectoryString { ub-name } - ID id-at-pseudonym } - --- domainComponent from RFC 2247 -domainComponent ATTRIBUTE ::= { - WITH SYNTAX IA5String - ID id-domainComponent } - -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)) - - - -Santesson, et al. Standards Track [Page 22] - -RFC 3039 Qualified Certificates Profile January 2001 - - - (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 } - --- Private 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, - biometricDataOid OBJECT IDENTIFIER } - -PredefinedBiometricType ::= INTEGER { picture(0), - handwritten-signature(1)} (picture|handwritten-signature,...) - --- QC Statements Extension - -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 } - - - -Santesson, et al. Standards Track [Page 23] - -RFC 3039 Qualified Certificates Profile January 2001 - - -WITH SYNTAX { - [SYNTAX &Type] IDENTIFIED BY &id } - -qcStatement-1 QC-STATEMENT ::= { SYNTAX SemanticsInformation - IDENTIFIED BY id-qcs-pkixQCSyntax-v1} - -- This statement identifies conformance with syntax and - -- semantics defined in this Qualified Certificate profile - -- (Version 1). The SemanticsInformation may optionally contain - -- additional semantics information as specified. - -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 following information object set is defined to constrain the --- set of attributes applications are required to recognize as QCSs. -SupportedStatements QC-STATEMENT ::= { - qcStatement-1, ... -- 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. In the interest of conformity, - they have been defined here using the ASN.1 ATTRIBUTE definition from - RFC 2459, which is sufficient for the purposes of this document, but - greatly simplified in comparison with ISO/ITU's definition. 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]. - -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 O=GMD - Forschungszentrum - Informationstechnik GmbH; C=DE - - - -Santesson, et al. Standards Track [Page 24] - -RFC 3039 Qualified Certificates Profile January 2001 - - - 3. The subject's distinguished name is CN=Petra M. Barzin, O=GMD - - Forschungszentrum Informationstechnik GmbH, C=DE - 4. The certificate was issued on May 1, 2000 and will expire on - November 1, 2000 - 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 - certificate policy object identifier is defined by TeleTrust, - Germany. It is required to be set in a certificate conformant - to the German digital signature law. - 8. The certificate includes a subject directory attributes - extension containing the following attributes: - - surname: Barzin - given name: Petra - date of birth: October, 14th 1971 - place of birth: Darmstadt - country of citizenship:Germany - gender: Female - - 9. The certificate includes a qualified statement private - extension indicating that the naming registration authority's - name as "municipality@darmstadt.de". - 10. The certificate includes, in conformance with RFC 2459, 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 - - petrasSubjDirAttrs AttributesSyntax ::= { - { - type id-pda-countryOfCitizenship, - values { - PrintableString : "DE" - } - }, - { - type id-pda-gender, - - - -Santesson, et al. Standards Track [Page 25] - -RFC 3039 Qualified Certificates Profile January 2001 - - - values { - PrintableString : "F" - } - }, - { - type id-pda-dateOfBirth, - values { - GeneralizedTime : "197110140000Z" - } - }, - { - type id-pda-placeOfBirth, - values { - DirectoryString : utf8String : "Darmstadt" - } - } - } - -C.1.1.2 The keyUsage extension - - petrasKeyUsage KeyUsage ::= {nonRepudiation} - -C.1.1.3 The certificatePolicies extension - - petrasCertificatePolicies CertificatePoliciesSyntax ::= { - { - policyIdentifier {1 3 36 8 1 1} - } - } - -C.1.1.4 The qcStatements extension - - petrasQCStatement QCStatements ::= { - { - statementId id-qcs-pkixQCSyntax-v1, - statementInfo SemanticsInformation : { - nameRegistrationAuthorities { - rfc822Name : "municipality@darmstadt.de" - } - } - } - } - -C.1.1.5 The authorityKeyIdentifier extension - - petrasAKI AuthorityKeyIdentifier ::= { - keyIdentifier '000102030405060708090A0B0C0D0E0FFEDCBA98'H - } - - - -Santesson, et al. Standards Track [Page 26] - -RFC 3039 Qualified Certificates Profile January 2001 - - -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 has been truncated for - readability purposes. - - { - version v3, - serialNumber 1234567890, - 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 : - "GMD - Forschungszentrum Informationstechnik GmbH" - } - } - }, - validity - { - notBefore utcTime : "000501100000Z", - notAfter utcTime : "001101100000Z" - }, - subject rdnSequence : - { - { - { - type { 2 5 4 6 }, - value PrintableString : "DE" - } - }, - { - { - type { 2 5 4 10 }, - value UTF8String : - - - -Santesson, et al. Standards Track [Page 27] - -RFC 3039 Qualified Certificates Profile January 2001 - - - "GMD Forschungszentrum Informationstechnik GmbH" - } - }, - { - { - type { 2 5 4 4 }, - value UTF8String : "Barzin" - }, - { - type { 2 5 4 42 }, - value UTF8String : "Petra" - } - } - }, - subjectPublicKeyInfo - { - algorithm - { - algorithm { 1 2 840 113549 1 1 1 }, - parameters RSAParams : NULL - }, - subjectPublicKey '00110000 10000001 10000111 00000010 1000 ...'B - }, - extensions - { - { - extnId { 2 5 29 9 }, -- subjectDirectoryAttributes - extnValue '305B301006082B06010505070904310413024445300F0 ...'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 '302B302906082B06010505070B01301D301B81196D756 ...'H - } - } - } - - - -Santesson, et al. Standards Track [Page 28] - -RFC 3039 Qualified Certificates Profile January 2001 - - -C.2 ASN.1 dump - - This section contains an ASN.1 dump of the signed portion of the - certificate. Some values has been truncated for readability - purposes. - - TBSCertificate SEQUENCE: tag = [UNIVERSAL 16] constructed; - length = 631 - version : tag = [0] constructed; length = 3 - Version INTEGER: tag = [UNIVERSAL 2] primitive; length = 1 - 2 - 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: tag = [UNIVERSAL 5] primitive; - length = 0 - 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 } - value OpenType: PrintableString: tag = [UNIVERSAL 19] - primitive; length = 2 - "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 } - value OpenType : UTF8String: tag = [UNIVERSAL 12] - primitive; length = 48 - 0x474d44202d20466f72736368756e67737a656e7472756d2049... - validity Validity SEQUENCE: tag = [UNIVERSAL 16] constructed; - length = 30 - notBefore Time CHOICE - - - -Santesson, et al. Standards Track [Page 29] - -RFC 3039 Qualified Certificates Profile January 2001 - - - utcTime UTCTime: tag = [UNIVERSAL 23] primitive; length = 13 - 000501100000Z - notAfter Time CHOICE - utcTime UTCTime: tag = [UNIVERSAL 23] primitive; length = 13 - 001101100000Z - 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 - { 2 5 4 6 } - value OpenType: PrintableString: tag = [UNIVERSAL 19] - primitive; length = 2 - "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 } - value OpenType: UTF8String: tag = [UNIVERSAL 12] - primitive; length = 46 - 0x474d4420466f72736368756e67737a656e7472756d20496e66... - 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 } - value OpenType: UTF8String: tag = [UNIVERSAL 12] - primitive; length = 6 - 0x4261727a696e - AttributeTypeAndValue SEQUENCE: tag = [UNIVERSAL 16] - constructed; length = 12 - type OBJECT IDENTIFIER: tag = [UNIVERSAL 6] primitive; - length = 3 - { 2 5 4 42 } - value OpenType: UTF8String: tag = [UNIVERSAL 12] - primitive; length = 5 - 0x5065747261 - subjectPublicKeyInfo SubjectPublicKeyInfo SEQUENCE: tag = - [UNIVERSAL 16] constructed; length = 157 - - - -Santesson, et al. Standards Track [Page 30] - -RFC 3039 Qualified Certificates Profile January 2001 - - - 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 } - parameters OpenType: NULL: tag = [UNIVERSAL 5] primitive; - length = 0 - NULL - subjectPublicKey BIT STRING: tag = [UNIVERSAL 3] primitive; - length = 139 - 0x0030818702818100b8488400d4b6088be48ead459ca19ec717aaf3d1d... - 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 } - extnValue OCTET STRING: tag = [UNIVERSAL 4] primitive; - length = 93 - 0x305b301006082b06010505070904310413024445300f06082b060... - Extension SEQUENCE: tag = [UNIVERSAL 16] constructed; - length = 14 - extnId OBJECT IDENTIFIER: tag = [UNIVERSAL 6] primitive; - length = 3 - { 2 5 29 15 } - 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 } - 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 } - extnValue OCTET STRING: tag = [UNIVERSAL 4] primitive; - length = 24 - 0x30168014000102030405060708090a0b0c0d0e0ffedcba98 - - - -Santesson, et al. Standards Track [Page 31] - -RFC 3039 Qualified Certificates Profile January 2001 - - - 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 } - extnValue OCTET STRING: tag = [UNIVERSAL 4] primitive; - length = 45 - 0x302b302906082b06010505070b01301d301b81196d756e6963697... - -C.3 DER-encoding - - This section contains the full, DER-encoded certificate, in hex. - - 3082030E30820277A0030201020204499602D2300D06092A864886F70D010105 - 05003048310B300906035504061302444531393037060355040A0C30474D4420 - 2D20466F72736368756E67737A656E7472756D20496E666F726D6174696F6E73 - 746563686E696B20476D6248301E170D3030303530313130303030305A170D30 - 30313130313130303030305A3065310B30090603550406130244453137303506 - 0355040A0C2E474D4420466F72736368756E67737A656E7472756D20496E666F - 726D6174696F6E73746563686E696B20476D6248311D300C060355042A0C0550 - 65747261300D06035504040C064261727A696E30819D300D06092A864886F70D - 010101050003818B0030818702818100B8488400D4B6088BE48EAD459CA19EC7 - 17AAF3D1D4EE3ECCA496128A13597D16CC8B85EB37EFCE110C63B01E684E5CF6 - 32291EAC60FD153C266EAAC36AD4CEA92319F9BFDD261AD2BFE41EAB4E17FE67 - 8341EE52D9A0A8B4DEC07B7ACC76762514045CEE9994E0CF37BAE05F8DE33B35 - FF98BCE77742CE4B12273BD122137FE9020105A381E93081E630640603551D09 - 045D305B301006082B06010505070904310413024445300F06082B0601050507 - 09033103130146301D06082B060105050709013111180F313937313130313430 - 30303030305A301706082B06010505070902310B0C094461726D737461647430 - 0E0603551D0F0101FF04040302064030120603551D20040B3009300706052B24 - 080101301F0603551D23041830168014000102030405060708090A0B0C0D0E0F - FEDCBA98303906082B06010505070103042D302B302906082B06010505070B01 - 301D301B81196D756E69636970616C697479406461726D73746164742E646530 - 0D06092A864886F70D01010505000381810048FD14D9AFE961E4321D9AA40CC0 - 1C12893550CF76FBECBDE448926B0AE6F904AB89E7B5F808666FB007218AC18D - 28CE1E2D40FBF8C16B275CBA0547D7885B74059DEC736223368FC1602A510BC1 - EB31E39F3967BE6B413D48BC743A0AB19C57FD20F3B393E8FEBD8B05CAA5007D - AD36F9D789AEF636A0AC0F93BCB3711B5907 - - - - - - - - - - - - - -Santesson, et al. Standards Track [Page 32] - -RFC 3039 Qualified Certificates Profile January 2001 - - -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. - - 30818902818100ad1f35964b3674c807b9f8a645d2c8174e514b69a4b46a7382 - 915abbc44eccede914dae8fcc023abcea9c53380e641795cb0dda664b872fc10 - 9f9bbb852bf42d994f634c681608e388dce240b558513e5b60027bd1a07cef9c - 9b6db37c7e1f1abd238eed96e4b669056b260f55e83f14e6027127c9deb3ad18 - afcd3f8a5f5bf50203010001 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Santesson, et al. Standards Track [Page 33] - -RFC 3039 Qualified Certificates Profile January 2001 - - -Authors' Addresses - - Stefan Santesson - AddTrust AB - P.O. Box 465 - S-201 24 Malmo - Sweden - - EMail: stefan@addtrust.com - - - Tim Polk - NIST - Building 820, Room 426 - Gaithersburg, MD 20899, USA - - EMail: wpolk@nist.gov - - - Petra Barzin - SECUDE - Sicherheitstechnologie Informationssysteme GmbH - Landwehrstrasse 50a - D-64293 Darmstadt - Germany - - EMail: barzin@secude.com - - - Magnus Nystrom - RSA Security AB - Box 10704 - S-121 29 Stockholm - Sweden - - EMail: magnus@rsasecurity.com - - - - - - - - - - - - - - - - -Santesson, et al. Standards Track [Page 34] - -RFC 3039 Qualified Certificates Profile January 2001 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2001). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS 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. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Santesson, et al. Standards Track [Page 35] - |