idnits 2.17.1 draft-ietf-ipsec-dss-cert-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 193 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 30 instances of too long lines in the document, the longest one being 29 characters in excess of 72. ** There are 35 instances of lines with control characters in the document. ** The abstract seems to contain references ([2], [3], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 57: '... issuerUniqueIdentifier [1] IMPLICIT UniqueIdentifier OPTIONAL,...' RFC 2119 keyword, line 59: '... subjectUniqueIdentifer [2] IMPLICIT UniqueIdentifier OPTIONAL,...' RFC 2119 keyword, line 61: '... extensions [3] Extensions OPTIONAL...' RFC 2119 keyword, line 70: '...edAlgorithms}{ @algorithm}) OPTIONAL }...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 21, 1996) is 10285 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '0' is mentioned on line 50, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' Summary: 12 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IPSEC Working Group 2 Internet Engineering Task John Kennedy 3 INTERNET-DRAFT Cylink Corporation 4 Expires in six months John Marchioni 5 Cylink Corporation 6 February 21, 1996 8 DSS Profile for X.509 Certificates 9 11 Status of this Memo 13 This document is a submission to the IETF Internet Protocol Security (IPSEC) 14 Working Group. Comments are solicited and should be addressed to the working 15 group mailing list (ipsec@ans.net) or to the authors. 17 This document is an Internet-Draft. Internet-Drafts are working documents of 18 the Internet Engineering Task Force (IETF), its areas, and its working groups. 19 Note that other groups may also distribute working documents as Internet-Drafts. 20 Comments should be sent to the IP Security WG mailing list 21 (ipsec@ans.net). 23 Internet-Drafts are draft documents valid for a maximum of six months and 24 may be updated, replaced, or obsoleted by other documents at any time. It 25 is inappropriate to use Internet-Drafts as reference material or to cite 26 them other than as ``work in progress.'' 28 To learn the current status of any Internet-Draft, please check the 29 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 30 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au 31 (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 33 Distribution of this memo is unlimited. 35 Abstract 37 This document describes the ASN.1 [1] encoding for an CCITT 1988 38 X.509 [2] certificate profiled for use with the NIST Digital Signature 39 Standard (DSS) [3]. 41 For details not covered in this document the reader should refer to its 42 base references: X.509 (1993) | ISO/IEC 9594-8 and Amendment 1 to ITU 43 Rec. X.509 (1993) | ISO/IEC 9594-8 : 1995. 45 1. ASN.1 Definition of Certificate 47 The abstract definition of the certificate is as follows: 49 Certificate ::= SIGNED { SEQUENCE { 50 version [0] Version DEFAULT v1, 51 serialNumber CertificateSerialNumber, 52 signature AlgorithmIdentifier, 53 issuer Name, 54 validity Validity, 55 subject Name, 56 subjectPublicKeyInfo SubjectPublicKeyInfo, 57 issuerUniqueIdentifier [1] IMPLICIT UniqueIdentifier OPTIONAL, 58 -- if present, must be v2 or v3 59 subjectUniqueIdentifer [2] IMPLICIT UniqueIdentifier OPTIONAL, 60 -- if present, must be v2 or v3 61 extensions [3] Extensions OPTIONAL 62 }} 64 Version ::= INTEGER { 1(0), v2(1), v3(2) } 66 CertificateSerialNumber ::= INTEGER 68 AlgorithmIdentifier ::= SEQUENCE { 69 algorithm ALGORITHM.&id ({SupportedAlgorithms}), 70 parameters ALGORITHM.&id ({SupportedAlgorithms}{ @algorithm}) OPTIONAL } 72 -- SupportedAlgorithms ALGORITHM ::= {...|...} 74 -- DSA Signature Algorithm 76 -- The Digital Signature Algorithm (DSA) is also called the Digital Signature 77 -- Standard (DSS). DSA 78 -- was developed by the U.S. Government, and DSA is used in conjunction with the SHA-1 one 79 -- way hash function (SHA-1 is described in FIPS 180-1). DSA is described in FIPS 186. 80 -- The ASN.1 object identifier used to identify this signature algorithm is: 82 dsaWithSHA-1 OBJECT IDENTIFIER ::= { 83 joint-iso-ccitt(2) country(16) US(840) organization(1) us-government(101) dod(2) 84 infosec(1) algorithms(1) dsa-sha1 (2) } 86 -- DSA Parameters 88 - When this object identifier is used with the ASN.1 type AlgorithmIdentifier, the parameters 89 - component of that type is optional. If it is absent, the DSA parameters p, q, and g are assumed to 90 - be known, otherwise the parameters are included using the following ASN.1 structure: 92 Dss-Parms ::= SEQUENCE { 93 p OCTET STRING, 94 q OCTET STRING, 95 g OCTET STRING } 97 -- DSA Signature Block 99 -- Prior to the bitstring encoding of the certificate issuers DSA signature the signature block must 100 -- be encoded using the distinguished rules as follows: 102 Dss-sig ::= SEQUENCE { 103 r OCTET STRING, 104 s OCTET STRING } 106 Validity ::= SEQUENCE { 107 notBefore UTCTime, 108 notAfter UTCTime } 110 SubjectPublicKeyInfo ::= SEQUENCE { 111 algorithm AlgorithmIdentifier, 112 subjectPublicKey BIT STRING } 114 2. Certificate Extensions 116 The standard extensions are described in Amendment 1 to ITU Rec. X.509 (1993) 117 | ISO/IEC 9594-8 : 1995. A subset of extension will need to be chosen 118 for this profile. The extensions field allows addition of new fields 119 to the certificate structure without modification to the ASN.1 definition. 120 An extension field consists of an extension object identifier, 121 a criticality flag, and a canonical encoding of a data value of an 122 ASN.1 type associated with the object identifier already specified. 124 When a system processes a certificate but does not recognize an 125 extension, if the criticality flag is FALSE, the extension may be 126 ignored and the remainder of the certificate information may be 127 processed as valid. If the criticality flag is TRUE, an unrecognized 128 extension shall cause the system to consider the entire certificate invalid. 130 3. An overview of the use of the Distinguished Encoding Rules (DER) in 131 Certificate Signature Operations. 133 (1) Sign; The signing application converts the abstract value 134 (or internal representation) of the certificate information into a bit 135 representation using the DER and signs that bit representation. 136 The signature is then appended onto the abstract value, and both values 137 are then BER 138 (Basic Encoding Rules) encoded to provide a transfer syntax. The same 139 encoder used to apply the DER may be used to apply the transfer 140 syntax, so the transfer syntax can also follow the DER. 142 (2) Authenticate; The authenticating application will decode the received 143 certificate (containing the certificate information and issuer signature). 144 This application will then have an abstract value for both the 145 certificate information and a signature. The application will then take the 146 resulting abstract value of the certificate information and re-encode it 147 using the DER to produce the same bit representation that was signed. 148 The received signature can now be authenticated using the exact bitstring 149 representation used in the signing operation. 151 When the DER are applied to information, before that information is signed, 152 the authentication operation (also applying the DER) will always detect if 153 that information has been modified and the incidence of false 154 authentication failures is greatly reduced. 156 4. Security Considerations 158 Security issues are not discussed in this document 160 5. References 162 [1] CCITT Recommendation X.208 (1992), "Abstract Syntax Notation One" 164 [2] CCITT Recommendation X.509 (1988), "The Directory - Authentication 165 Framework" 167 [3] FIPS 186 Digital Signature Standard 169 Author's Address(es) 171 Questions about this can be directed to: 173 John Kennedy 174 CYLINK Corporation 175 jkennedy@cylink.com 176 408-735-5885 178 John Marchioni 179 CYLINK Corporation 180 johnmarc@cylink.com 181 408-735-5800