1、 ETSI TS 102 280 V1.1.1 (2004-03)Technical Specification X.509 V.3 Certificate Profile forCertificates Issued to Natural PersonsETSI ETSI TS 102 280 V1.1.1 (2004-03) 2 Reference DTS/ESI-000018 Keywords electronic signature, IP, profile, security ETSI 650 Route des Lucioles F-06921 Sophia Antipolis C
2、edex - FRANCE Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 Siret N 348 623 562 00017 - NAF 742 C Association but non lucratif enregistre la Sous-Prfecture de Grasse (06) N 7803/88 Important notice Individual copies of the present document can be downloaded from: http:/www.etsi.org The present docu
3、ment may be made available in more than one electronic version or in print. In any case of existing or perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF). In case of dispute, the reference shall be the printing on ETSI printers of the
4、PDF version kept on a specific network drive within ETSI Secretariat. Users of the present document should be aware that the document may be subject to revision or change of status. Information on the current status of this and other ETSI documents is available at http:/portal.etsi.org/tb/status/sta
5、tus.asp If you find errors in the present document, send your comment to: editoretsi.org Copyright Notification No part may be reproduced except as authorized by written permission. The copyright and the foregoing restriction extend to reproduction in all media. European Telecommunications Standards
6、 Institute 2004. All rights reserved. DECTTM, PLUGTESTSTM and UMTSTM are Trade Marks of ETSI registered for the benefit of its Members. TIPHONTMand the TIPHON logo are Trade Marks currently being registered by ETSI for the benefit of its Members. 3GPPTM is a Trade Mark of ETSI registered for the ben
7、efit of its Members and of the 3GPP Organizational Partners. ETSI ETSI TS 102 280 V1.1.1 (2004-03) 3 Contents Intellectual Property Rights5 Foreword.5 Introduction 5 1 Scope 6 2 References 6 3 Abbreviations .7 4 Document structure and terminology .7 4.1 Document structure 7 4.2 Terminology.7 5 Profi
8、le requirements .7 5.1 Generic requirements .7 5.2 Basic certificate fields 8 5.2.1 Version8 5.2.2 Serial number8 5.2.3 Signature.8 5.2.4 Issuer.8 5.2.5 Validity .8 5.2.6 Subject 8 5.2.7 Subject public key info .9 5.3 X.509 version 2 certificate fields9 5.4 Standard certificate extensions .9 5.4.1 A
9、uthority key identifier 9 5.4.2 Subject key identifier9 5.4.3 Key usage9 5.4.4 Private key usage period.10 5.4.5 Certificate policies 10 5.4.6 Policy mappings10 5.4.7 Subject alternative name.10 5.4.8 Issuer alternative name .10 5.4.9 Subject directory attributes .10 5.4.10 Basic constraints .10 5.4
10、.11 Name constraints 11 5.4.12 Policy constraints11 5.4.13 Extended key usage 11 5.4.14 CRL distribution points 11 5.4.15 Inhibit any-policy11 5.4.16 Freshest CRL 11 5.5 RFC 3280 internet certificate extensions11 5.5.1 Authority Information Access.11 5.5.2 Subject information access .11 5.6 RFC 3739
11、 certificate extensions.11 5.6.1 Biometric information.11 5.6.2 Qualified certificate statement 12 Annex A (informative): Important requirements from referenced standards .13 A.1 Scope and structure 13 A.2 Basic certificate fields 13 A.2.1 Version .13 A.2.2 Serial number .13 A.2.3 Signature.13 A.2.4
12、 Issuer 13 A.2.5 Validity.14 ETSI ETSI TS 102 280 V1.1.1 (2004-03) 4 A.2.6 Subject14 A.2.7 Subject public key info.14 A.3 X.509 version 2 certificate fields .14 A.4 Standard certificate extensions.14 A.4.1 Authority key identifier 14 A.4.2 Subject key identifier15 A.4.3 KeyUsage .15 A.4.4 Private ke
13、y usage period.15 A.4.5 Certificate policies15 A.4.6 Policy mappings .15 A.4.7 Subject alternative name 16 A.4.8 Issuer alternative name.16 A.4.9 Subject directory attributes.16 A.4.10 Basic constraints.16 A.4.11 Name constraints 16 A.4.12 Policy constraints .16 A.4.13 Extended key usage 16 A.4.14 C
14、RL distribution points 16 A.4.15 Inhibit any-policy .17 A.4.16 Freshest CRL17 A.5 RFC 3280 internet certificate extensions .17 A.5.1 Authority information access .17 A.5.2 Subject information access.17 A.6 RFC 3739 certificate extensions.17 A.6.1 Biometric information 17 A.6.2 Qualified certificate
15、statement18 History 19 ETSI ETSI TS 102 280 V1.1.1 (2004-03) 5 Intellectual Property Rights IPRs essential or potentially essential to the present document may have been declared to ETSI. The information pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-membe
16、rs, and can be found in ETSI SR 000 314: “Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respect of ETSI standards“, which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web server (http:/webapp.etsi.org/IPR/home.a
17、sp). Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become, essential to the pr
18、esent document. Foreword This Technical Specification (TS) has been produced by ETSI Technical Committee Electronic Signatures and Infrastructures (ESI). Introduction The present document defines a common profile for X.509 based certificates issued to natural persons. The Directive of the European P
19、arliament and of the Council on a Community framework for electronic signatures (1999/93/EC 1) defines requirements on a specific type of certificates named “Qualified Certificates“. Implementation of the Directive 1999/93/EC 1 and deployment of certificate infrastructures throughout Europe as well
20、as in countries outside of Europe, have resulted in a variety of certificate implementations for use in public and closed environments, where some are declared as Qualified Certificates while others are not. Applications need support from standardized identity certificates profiles, in particular wh
21、en applications are used for electronic signatures, authentication and secure electronic exchange in open environments and international trust scenarios, but also when certificates are used in local application contexts. ETSI ETSI TS 102 280 V1.1.1 (2004-03) 6 1 Scope The present document defines a
22、common profile for ITU-T Recommendation X.509 2 based certificates issued to natural persons. The scope of the present document is to provide a certificate profile, which will allow actual interoperability of certificates issued for the purposes of qualified electronic signatures, peer entity authen
23、tication and data authentication. This profile depends on the Internet standards RFC 3280 3 and RFC 3739 4 for generic profiling of ITU-T Recommendation X.509 2, and depends on the ETSI standard TS 101 862 5 to define implementation of requirements defined by the Electronic Signature Directive 1999/
24、93/EC 1 Annexes I and II. The scope of the present document is primary limited to facilitate interoperable processing and display of certificate information in existing deployments of ITU-T Recommendation X.509 2. It is thus important to note that this profile deliberately has excluded support for s
25、ome certificate information content options, which may be perfectly valid in a local context but which are not regarded as relevant or suitable for use in widely deployed applications. The present document focuses on requirements on certificate content. Requirements on decoding and processing rules
26、are limited to aspects required to process certificate content defined in the present document. Further processing requirements are only specified for cases where it adds information that is necessary for the sake of interoperability. Guidance for implementers is provided for cases in which near ter
27、m developments are affected. This certificate profile recognizes the natural need for reasonable variations of implementation which does not negatively affect generic interoperability. This is e.g. valid for different ways to encode a certificate holders identity. Certain applications or protocols i
28、mpose specific requirements on certificate content such as IP-sec, Network logon, S/MIME, IEEE 802.1x 12 EAP. The present document is based on the assumption that these requirements are adequately defined by the respective application or protocol. It is therefore outside the scope of the present doc
29、ument to specify such application or protocol specific certificate content. 2 References The following documents contain provisions which, through reference in this text, constitute provisions of the present document. References are either specific (identified by date of publication and/or edition n
30、umber or version number) or non-specific. For a specific reference, subsequent revisions do not apply. For a non-specific reference, the latest version applies. Referenced documents which are not found to be publicly available in the expected location might be found at http:/docbox.etsi.org/Referenc
31、e. 1 Directive 1999/93/EC of the European Parliament and of the Council of 13 December 1999 on a Community framework for electronic signatures. 2 ITU-T Recommendation X.509/ISO/IEC 9594-8: “Information technology - Open Systems Interconnection - The Directory: Public-key and attribute certificate fr
32、ameworks“. 3 IETF RFC 3280: “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile“. 4 IETF RFC 3739: “Internet X.509 Public Key Infrastructure: Qualified Certificates Profile“. 5 ETSI TS 101 862: “Qualified Certificate profile“. 6 IETF RFC 2119: “Key wor
33、ds for use in RFCs to Indicate Requirement Levels“. 7 IETF RFC 3279: “Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile“. ETSI ETSI TS 102 280 V1.1.1 (2004-03) 7 8 ETSI SR 002 176: “Electronic Signatures and Infrastr
34、uctures (ESI); Algorithms and Parameters for Secure Electronic Signatures“. 9 IETF RFC 2616: “Hypertext Transfer Protocol - HTTP/1.1“. 10 IETF RFC 2255: “The LDAP URL Format“. 11 IETF RFC 2560: “X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP“. 12 IEEE 802.1x: “IEE
35、E Standard for Port Based Network Access Control“. 13 RFC 2459: “Internet X.509 Public Key Infrastructure Certificate and CRL Profile“. 3 Abbreviations For the purposes of the present document, the following abbreviations apply: CA Certification Authority CRL Certificate Revocation ListDS Digital Si
36、gnature KEA Key Encipherment or Agreement NR Non-Repudiation OCSP Online Certificate Status Protocol OID Object Identifier 4 Document structure and terminology 4.1 Document structure The present document profiles the use of other standards. Clause 4 contains the profiling requirements defined by the
37、 present document. This clause does not repeat the base requirements of the referenced standards. Annex A is an informative annex which, for convenience purposes only, lists some important requirements from referenced standards that are relevant for the understanding of the present document. 4.2 Ter
38、minology The key words “MUST“, “MUST NOT“, “REQUIRED“, “SHALL“, “SHALL NOT“, “SHOULD“, “SHOULD NOT“, “RECOMMENDED“, “MAY“, and “OPTIONAL“ in the present document are to be interpreted as described in RFC 2119 6. 5 Profile requirements 5.1 Generic requirements All certificate fields and extensions SH
39、ALL, where applicable, comply with RFC 3280 3, RFC 3739 4 and TS 101 862 5 with the amendments specified in the present document. When “No specific requirements“ is stated for a particular field or extension, this means that no specific requirements apply except for those stated by RFC 3280 3, RFC 3
40、739 4 and TS 101 862 5. In case of discrepancies between the present specification and the named standards above, the present document is the normative one. ETSI ETSI TS 102 280 V1.1.1 (2004-03) 8 5.2 Basic certificate fields 5.2.1 Version Certificates compliant with the present document SHALL be IT
41、U-T Recommendation X.509 2 version 3 certificates. 5.2.2 Serial number No specific requirements. 5.2.3 Signature Signature algorithm SHALL be specified according to RFC 3279 7 and SR 002 176 8. It is strongly RECOMMENDED to use sha1WithRSAEncryption when maximum interoperability with open environmen
42、t deployments is a requirement. 5.2.4 Issuer The identity of the issuer SHALL be specified using an appropriate subset of the following attributes: countryName, organizationName, organizationalUnitName, (multiple instances may be present) stateOrProvinceName, localityName, commonName, serialNumber,
43、and domainComponent. Additional attributes MAY be present but they SHOULD NOT be necessary to identify the issuing organization. The attributes countryName and organizationName SHALL be present. The organizationName attribute SHALL contain the full registered name of the certificate issuing organiza
44、tion and countryName SHALL contain the country within which the issuing organization is registered. If any value of the domainComponent attributes contain information associated with a country, then this has no meaning beyond describing the issuers internet domain. If a domainComponent attribute val
45、ue indicates a different country than the countryName attribute value, then determination of the country of registration of the issuing organization SHALL exclusively be determined though the countryName attribute, disregarding any domainComponent attribute values. NOTE: Use of domainComponent attri
46、butes in addition to the mandatory attributes countryName and organizationName is possible but it may cause conflict if the issuer name is used as distinguished name for directory entries. Implementing CAs should carefully select their issuing name in compliance with any directory infrastructure the
47、y operate within. 5.2.5 Validity No specific requirements. 5.2.6 Subject The subject field SHALL contain an appropriate subset of the following attributes: domainComponent, countryName, commonName, surname, givenName, serialNumber, title, ETSI ETSI TS 102 280 V1.1.1 (2004-03) 9 organizationName, org
48、anizationalUnitName, stateOrProvinceName, and localityName. Other attributes may be present but SHALL NOT be necessary to distinguish the subject name from other subject names within the issuer domain. The subject field SHALL include at least one of the following choice of attributes: Choice I: comm
49、onName Choice II: givenName and surname NOTE: The use of domainComponent attributes is often used as alternative to the subject attributes countryName and organizationName. Use of domainComponent attributes in addition to these attributes is not invalid but may cause conflict if the subject name is used as distinguished name for directory entries. Implementing CAs should carefully select their subject naming in compliance with any directory infrastructure they operate within. 5.2.7 Subject public key info
