1、 I n t e r n a t i o n a l T e l e c o m m u n i c a t i o n U n i o n ITU-T X.509 TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU Corrigendum 1 (05/2015) SERIES X: DATA NETWORKS, OPEN SYSTEM COMMUNICATIONS AND SECURITY Directory Information technology Open Systems Interconnection The Directory: Pub
2、lic-key and attribute certificate frameworks Technical Corrigendum 1 Recommendation ITU-T X.509 (2012) Technical Corrigendum 1 ITU-T X-SERIES RECOMMENDATIONS DATA NETWORKS, OPEN SYSTEM COMMUNICATIONS AND SECURITY PUBLIC DATA NETWORKS Services and facilities X.1X.19 Interfaces X.20X.49 Transmission,
3、signalling and switching X.50X.89 Network aspects X.90X.149 Maintenance X.150X.179 Administrative arrangements X.180X.199 OPEN SYSTEMS INTERCONNECTION Model and notation X.200X.209 Service definitions X.210X.219 Connection-mode protocol specifications X.220X.229 Connectionless-mode protocol specific
4、ations X.230X.239 PICS proformas X.240X.259 Protocol Identification X.260X.269 Security Protocols X.270X.279 Layer Managed Objects X.280X.289 Conformance testing X.290X.299 INTERWORKING BETWEEN NETWORKS General X.300X.349 Satellite data transmission systems X.350X.369 IP-based networks X.370X.379 ME
5、SSAGE HANDLING SYSTEMS X.400X.499 DIRECTORY X.500X.599 OSI NETWORKING AND SYSTEM ASPECTS Networking X.600X.629 Efficiency X.630X.639 Quality of service X.640X.649 Naming, Addressing and Registration X.650X.679 Abstract Syntax Notation One (ASN.1) X.680X.699 OSI MANAGEMENT Systems management framewor
6、k and architecture X.700X.709 Management communication service and protocol X.710X.719 Structure of management information X.720X.729 Management functions and ODMA functions X.730X.799 SECURITY X.800X.849 OSI APPLICATIONS Commitment, concurrency and recovery X.850X.859 Transaction processing X.860X.
7、879 Remote operations X.880X.889 Generic applications of ASN.1 X.890X.899 OPEN DISTRIBUTED PROCESSING X.900X.999 INFORMATION AND NETWORK SECURITY X.1000X.1099 SECURE APPLICATIONS AND SERVICES X.1100X.1199 CYBERSPACE SECURITY X.1200X.1299 SECURE APPLICATIONS AND SERVICES X.1300X.1399 CYBERSECURITY IN
8、FORMATION EXCHANGE X.1500X.1599 CLOUD COMPUTING SECURITY X.1600X.1699 For further details, please refer to the list of ITU-T Recommendations. Rec. ITU-T X.509 (2012)/Cor.1 (05/2015) i INTERNATIONAL STANDARD ISO/IEC 9594-8 RECOMMENDATION ITU-T X.509 Information technology Open Systems Interconnection
9、 The Directory: Public-key and attribute certificate frameworks Technical Corrigendum 1 Summary Technical Corrigendum 1 to Rec. ITU-T X.509 | ISO/IEC 9594-8 covers the following: Resolution to defect reports 389, 390,393, 394, 395, 397, 398, 399, 400, 401, 402, 403, 404 and 405). History Edition Rec
10、ommendation Approval Study Group Unique ID* 1.0 ITU-T X.509 1988-11-25 11.1002/1000/2999 2.0 ITU-T X.509 1993-11-16 7 11.1002/1000/3000 3.0 ITU-T X.509 1997-08-09 7 11.1002/1000/4123 3.1 ITU-T X.509 (1997) Technical Cor. 1 2000-03-31 7 11.1002/1000/5033 3.2 ITU-T X.509 (1997) Technical Cor. 2 2001-0
11、2-02 7 11.1002/1000/5311 3.3 ITU-T X.509 (1997) Technical Cor. 3 2001-10-29 7 11.1002/1000/5559 3.4 ITU-T X.509 (1997) Technical Cor. 4 2002-04-13 17 11.1002/1000/6025 3.5 ITU-T X.509 (1997) Technical Cor. 5 2003-02-13 17 11.1002/1000/6236 3.6 ITU-T X.509 (1997) Technical Cor. 6 2004-04-29 17 11.100
12、2/1000/7285 4.0 ITU-T X.509 2000-03-31 7 11.1002/1000/5034 4.1 ITU-T X.509 (2000) Technical Cor. 1 2001-10-29 7 11.1002/1000/5560 4.2 ITU-T X.509 (2000) Technical Cor. 2 2002-04-13 17 11.1002/1000/6026 4.3 ITU-T X.509 (2000) Technical Cor. 3 2004-04-29 17 11.1002/1000/7284 4.4 ITU-T X.509 (2000) Tec
13、hnical Cor. 4 2007-01-13 17 11.1002/1000/8637 5.0 ITU-T X.509 2005-08-29 17 11.1002/1000/8501 5.1 ITU-T X.509 (2005) Cor. 1 2007-01-13 17 11.1002/1000/9051 5.2 ITU-T X.509 (2005) Cor. 2 2008-11-13 17 11.1002/1000/9591 5.3 ITU-T X.509 (2005) Cor. 3 2011-02-13 17 11.1002/1000/11042 5.4 ITU-T X.509 (20
14、05) Cor. 4 2012-04-13 17 11.1002/1000/11577 6.0 ITU-T X.509 2008-11-13 17 11.1002/1000/9590 6.1 ITU-T X.509 (2008) Cor. 1 2011-02-13 17 11.1002/1000/11043 6.2 ITU-T X.509 (2008) Cor. 2 2012-04-13 17 11.1002/1000/11578 6.3 ITU-T X.509 (2008) Cor. 3 2012-10-14 17 11.1002/1000/11736 7.0 ITU-T X.509 201
15、2-10-14 17 11.1002/1000/11735 7.1 ITU-T X.509 (2012) Cor. 1 2015-05-29 17 11.1002/1000/12474 _ * To access the Recommendation, type the URL http:/handle.itu.int/ in the address field of your web browser, followed by the Recommendations unique ID. For example, http:/handle.itu.int/11.1002/1000/11830-
16、en. ii Rec. ITU-T X.509 (2012)/Cor.1 (05/2015) FOREWORD The International Telecommunication Union (ITU) is the United Nations specialized agency in the field of telecommunications, information and communication technologies (ICTs). The ITU Telecommunication Standardization Sector (ITU-T) is a perman
17、ent organ of ITU. ITU-T is responsible for studying technical, operating and tariff questions and issuing Recommendations on them with a view to standardizing telecommunications on a worldwide basis. The World Telecommunication Standardization Assembly (WTSA), which meets every four years, establish
18、es the topics for study by the ITU-T study groups which, in turn, produce Recommendations on these topics. The approval of ITU-T Recommendations is covered by the procedure laid down in WTSA Resolution 1. In some areas of information technology which fall within ITU-Ts purview, the necessary standar
19、ds are prepared on a collaborative basis with ISO and IEC. NOTE In this Recommendation, the expression “Administration“ is used for conciseness to indicate both a telecommunication administration and a recognized operating agency. Compliance with this Recommendation is voluntary. However, the Recomm
20、endation may contain certain mandatory provisions (to ensure, e.g., interoperability or applicability) and compliance with the Recommendation is achieved when all of these mandatory provisions are met. The words “shall“ or some other obligatory language such as “must“ and the negative equivalents ar
21、e used to express requirements. The use of such words does not suggest that compliance with the Recommendation is required of any party. INTELLECTUAL PROPERTY RIGHTSITU draws attention to the possibility that the practice or implementation of this Recommendation may involve the use of a claimed Inte
22、llectual Property Right. ITU takes no position concerning the evidence, validity or applicability of claimed Intellectual Property Rights, whether asserted by ITU members or others outside of the Recommendation development process. As of the date of approval of this Recommendation, ITU had received
23、notice of intellectual property, protected by patents, which may be required to implement this Recommendation. However, implementers are cautioned that this may not represent the latest information and are therefore strongly urged to consult the TSB patent database at http:/www.itu.int/ITU-T/ipr/. I
24、TU 2015 All rights reserved. No part of this publication may be reproduced, by any means whatsoever, without the prior written permission of ITU. ISO/IEC 9594-8:2014/Cor.1:2015 (E) Rec. ITU-T X.509 (2012)/Cor.1 (05/2015) 1 INTERNATIONAL STANDARD ITU-T RECOMMENDATION Information technology Open Syste
25、ms Interconnection The Directory: Public-key and attribute certificate frameworks Technical Corrigendum 1 (Covering resolution to defect reports 389, 390,393, 394, 395, 397, 398, 399, 400, 401, 402, 403, 404 and 405) 1) Correction of the defects reported in defect report 389 Replace clause 3.5.61 wi
26、th the following: 3.5.61 self-issued attribute certificate: An attribute certificate where the issuer and the holder are the same attribute authority. An attribute authority might use a self-issued attribute certificate, for example, to publish policy information. 2) Correction of the defects report
27、ed in defect report 390 Delete the last paragraph of clause 8.6.2. 3) Correction of the defects reported in defect report 393 Replace the last paragraph of clause 8.5.2.9 with: The scope of a CRL containing this extension is extended to include the revocation status of revoked certificates that expi
28、red after the date specified in ExpiredCertsOnCRL or at that date. The revocation status of a certificate shall not be updated once the certificate has expired. 4) Correction of the defects reported in defect report 394 Add the following references to clause 2.4 IETF RFC 5914 (2010), Trust Anchor Fo
29、rmat. Add a new definition to clause 3.5: 3.5.68 trust anchor store: A trust anchor information collection at a relying party for one or more trust anchors. Replace clause 7.5 with: 7.5 Trust anchor An entity is a trust anchor for a particular relying party for one or more purposes, typically includ
30、ing certificate validation. A trust anchor is identified by trust anchor information. Trust anchor information includes a public key and some associated data. This trust anchor information is configured into the relying party in a trust anchor store. A relying party may have configured information a
31、bout multiple trust anchors into one or more trust anchor stores. A trust anchor may be a CA that issues public-key certificates and certificate revocation lists (CRLs) (see clause 7.10). The relying party may then use the trust anchor information for public-key certificate and CRL validation. A tru
32、st anchor may also function as an end entity by signing other types of information such as software packages, time stamps, responses to online certificate status protocol (OCSP) requests (see IETF RFC 6960), etc. A CA may be a trust anchor for some entities with respect to particular public-key cert
33、ificates, but may otherwise be an ordinary CA. NOTE 1 As an example, entities within a company may trust all the public-key certificates issued by the company CA. This CA is then the trust anchor for these local relying parties with respect to locally issued public-key certificates. However, by use
34、of name constraints, it might not be a trust anchor with respect to public-key certificates issued outside the company. Likewise, relying parties outside the company may not consider the company CA as the trust anchor for any public-key certificates. NOTE 2 The term trust anchor is seen as synonymou
35、s with the term root-CA. In a strict hierarchy, the CA at the top of the hierarchy may be the root CA and it may also be a trust anchor. However, in more complex environments, it may not be possible ISO/IEC 9594-8:2014/Cor.1:2015 (E) 2 Rec. ITU-T X.509 (2012)/Cor.1 (05/2015) to identify a root CA. E
36、ven when it is possible to identify a root CA, a relying party may not necessarily consider it a trust anchor. An intermediate CA may instead take that role. IETF RFC 5914 defines trust anchor information as a choice between three alternatives: TrustAnchorChoice := CHOICE certificate Certificate, tb
37、sCert 1 EXPLICIT TBSCertificate, taInfo 2 EXPLICIT TrustAnchorInfo The certificate alternative specifies a public-key certificate that can be either a self-signed certificate or a public-key certificate. The tbsCert alternative specifies an unsigned public-key certificate as defined in clause 7.2. N
38、OTE 3 This alternative is deprecated by this Specification and therefore not considered further. The taInfo alternative specify a special trust anchor information format defined by IETF RFC 5914. In case the trust anchor information is not used for signing public-key certificates, it shall be an end
39、-entity public-key certificate. 5) Correction of the defects reported in defect report 395 Add the following to the references in clause 2.4: IETF RFC 3492 (2003), Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA). IETF RFC 5890 (2010), Internationa
40、lized Domain Names for Applications (IDNA): Definitions and Document Framework. Add the following abbreviations to clause 4: FQDN Fully-Qualified Domain Name IDN Internationalized Domain Name LDH Letters, Digits, Hyphen Replace the text for the dNSName in clause 8.3.2.1 with: the dNSName alternative
41、 shall be a fully-qualified domain name (FQDN). The domain name shall be in the syntax as specified by section 2.3.1 of IETF RFC 5890 meaning that a domain name is a sequence of labels in the letters, digits, hyphen (LDH) format separated by dots. A label may be in one of two formats: a) All charact
42、ers in the label are from the Basic Latin collection as defined by ISO/IEC 10646 (i.e., having code points in the ranges 002D, 0030-0039, 0041-005A and 0061-007A) and it does not start with “xn-“. The maximum length is 63 octets. b) It is an A-label as defined in IETF RFC 5890, i.e., it starts with
43、the “xn-“ and is a U-label converted to valid ASCII characters as in item a) using the Punycode algorithm defined by IETF RFC 3492. The converted string shall be maximum 59 octets. To be valid, it shall be possible for an A-label to be converted to a valid U-label. The U-label is as also defined in
44、IETF RFC 5890. NOTE 1 An A-label is normally not human-readable. 6) Correction of the defects reported in defect report 397 In clause 7.10, replace the explanatory text for the version component with: The version field shall indicate the version of the encoded revocation list. If the extensions comp
45、onent is present in the revocation list, the version shall be v2. If the extensions component is not present, the version shall either be absent or present as v2. NOTE 1 In the first and the second editions of this specification, the version component was always absent. In the third, fourth, fifth a
46、nd sixth editions of this specification, the version shall be v2, if the extensions component flagged as critical is present in the revocation list. Or the version may either be absent or present as v2, if no extensions component flagged as critical is present in the revocation list. Delete current
47、Note 4. ISO/IEC 9594-8:2014/Cor.1:2015 (E) Rec. ITU-T X.509 (2012)/Cor.1 (05/2015) 3 Renumber the remaining notes from clause 7.10. 7) Correction of the defects reported in defect report 398 Update the ASN.1 in clause 8.6.2.2 as shown: IssuingDistPointSyntax := SEQUENCE - If onlyContainsUserPublicKe
48、yCerts and onlyContainsCACerts are both FALSE, - the CRL covers both public-key certificate types distributionPoint 0 DistributionPointName OPTIONAL, onlyContainsUserPublicKeyCerts 1 BOOLEAN DEFAULT FALSE, onlyContainsCACerts 2 BOOLEAN DEFAULT FALSE, onlySomeReasons 3 ReasonFlags OPTIONAL, indirectC
49、RL 4 BOOLEAN DEFAULT FALSE, onlyContainsAttributeCerts 5 BOOLEAN OPTIONAL, - Use is strongly deprecated . After the first paragraph after the ASN.1, add a new paragraph: If onlyContainsAttributeCerts is TRUE, the CRL only contains revocations for attribute certificates. This component is deprecated and should not be included. Instead, the aAissuingDistributionPoint extension should be used. NOTE 1 This component was intro
