[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: WGLC for draft-ietf-pkix-sha2-dsa-ecdsa-06.txt
Thanks Paul for your extensive review.
I agree in principle with your three points here. I personally like keeping
standards as short and clear as possible.
For the most part I think your change proposals are fine.
Some informational notes could be worth keeping such as "[X9.62] has defined
additional OIDs for the ECDSA signature algorithm.". It may also be useful
to keep some more text in the security considerations section, explaining
the guidance provided by the NIST publications.
/Stefan
On 09-05-09 6:50 PM, "Paul Hoffman" <paul.hoffman@xxxxxxxx> wrote:
>
> Greetings again. This document is *not* ready for advancement. It has many
> fundamental flaws that prevent it from being an understandable standard.
>
> 1) Update status is unclear
>
> As Russ pointed out, much of the information from the RFC 3279 is repeated
> here. Unlike Russ, I do not consider this to be "minor". This document is
> intended to be on standards track and presumably is an update to RFC 3279
> (even though the header on the first page does not say so). Thus, the
> repetition is quite bad when it is not exact or, worse, when it is incomplete.
>
> The only way to clear up the update status is to keep the status as updating
> RFC 3279 and strip the document of everything except the updates to RFC 3279,
> plus some pointers to recommendations of appropriate use. The good news is
> that this will turn the document into about two pages, mostly OIDs.
>
> 2) Mandating key sizes and lifetimes is inappropriate in this document
>
> RFC 3279 does not mandate key sizes; this draft does. Worse, this draft relies
> on the tortured logic in NIST SP 800-57 Part 1 that conflates multiple
> effective key strengths onto a single hash algorithm. The logic that NIST used
> in making that decision had to do with the difficulty of upgrading a disparate
> US government infrastructure over a long period of time. That's fine for NIST,
> but an IETF standard should not make such compromises. It is just wrong to
> update an existing algorithm RFC by adding a new set of restrictions, but only
> for some of the algorithms, namely the new ones being added.
>
> The key strength matching and lifetime mandates should be ripped out. It is
> fine to have a non-normative reference to NIST SP 800-57 Part 1 and NIST SP
> 800-78-1 in the Security Considerations to help people find the documents.
>
> 3) Adding new validation requirements at this late date is wrong
>
> RFC 3279 specified DSA only with SHA-1; this document adds DSA with SHA-2.
> However, this document now makes all implementations of RFC 3279 that could
> validate DSA non-conformant. It is wrong to add new algorithms and then punish
> existing implementations by labelling them non-conformant to a
> long-established standard.
>
> Following the three guidelines above, the meat of the document is reduced to
> that below.
>
> --Paul Hoffman
>
> Abstract
>
> This document updates RFC 3279 to specify algorithm identifiers
> and ASN.1 encoding rules for the Digital Signature Algorithm (DSA)
> and Elliptic Curve Digital Signature Algorithm (ECDSA) digital
> signatures when using SHA-224, SHA-256, SHA-384 or SHA-512 as
> hashing algorithm. This specification applies to the Internet
> X.509 Public Key Infrastructure (PKI) when digital signatures are
> used to sign certificates and certificate revocation lists (CRLs).
>
> 1. Introduction
>
> This specification defines the contents of the signatureAlgorithm,
> signatureValue and signature fields within Internet X.509
> certificates and CRLs when these objects are signed using DSA or
> ECDSA with a SHA2 hash algorithm. These fields are more fully
> described in [RFC 5280].
>
> This document profiles material presented in the "Secure Hash
> Standard" [FIPS 180-3], "Public Key Cryptography for the Financial
> Services Industry: The Elliptic Curve Digital Signature Standard
> (ECDSA)" [X9.62], and the "Digital Signature Standard" [FIPS
> 186-3].
>
> 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].
>
> 2. One-way Hash Functions
>
> This section identifies four additional hash algorithms for use
> with DSA and ECDSA in the Internet X.509 certificate and CRL
> profile [RFC 5280]. SHA-224, SHA-256, SHA-384, and SHA-512
> produce a 224-bit, 256-bit, 384-bit and 512-bit "hash" of the
> input respectively and are fully described in the Federal
> Information Processing Standard 180-3 [FIPS 180-3].
>
> The listed one-way hash functions are identified by the following
> object identifiers (OIDs):
>
> id-sha224 OBJECT IDENTIFIER ::= { joint- iso-itu-t(2)
> country(16) us(840) organization(1) gov(101) csor(3)
> nistalgorithm(4) hashalgs(2) 4 }
>
> id-sha256 OBJECT IDENTIFIER ::= { joint- iso-itu-t(2)
> country(16) us(840) organization(1) gov(101) csor(3)
> nistalgorithm(4) hashalgs(2) 1 }
>
> id-sha384 OBJECT IDENTIFIER ::= { joint- iso-itu-t(2)
> country(16) us(840) organization(1) gov(101) csor(3)
> nistalgorithm(4) hashalgs(2) 2 }
>
> id-sha512 OBJECT IDENTIFIER ::= { joint- iso-itu-t(2)
> country(16) us(840) organization(1) gov(101) csor(3)
> nistalgorithm(4) hashalgs(2) 3 }
>
> When one of these OIDs appears in an AlgorithmIdentifier, all
> implementations MUST accept both NULL and absent parameters as
> legal and equivalent encodings.
>
> 3. Signature Algorithms
>
> This section identifies OIDs for DSA and ECDSA with SHA-224,
> SHA-256, SHA-384, and SHA-512. The contents of the parameters
> component for each signature algorithm vary; details are provided
> for each algorithm.
>
> 3.1 DSA Signature Algorithm
>
> The DSA is defined in the Digital Signature Standard (DSS) [FIPS
> 186-3]. DSA was developed by the U.S. Government, and can be used
> in conjunction with a SHA2 one-way hash function such as SHA-224
> or SHA-256. DSA is fully described in [FIPS 186-3].
>
> When SHA-224 is used, the OID is:
>
> id-dsa-with-sha224 OBJECT IDENTIFIER ::= { joint-iso-ccitt(2)
> country(16) us(840) organization(1) gov(101) csor(3)
> algorithms(4) id-dsa-with-sha2(3) 1 }
>
> When SHA-256 is used, the OID is:
>
> id-dsa-with-sha256 OBJECT IDENTIFIER ::= { joint-iso-ccitt(2)
> country(16) us(840) organization(1) gov(101) csor(3)
> algorithms(4) id-dsa-with-sha2(3) 2 }
>
> When the id-dsa-with-sha224 or id-dsa-with-sha256 algorithm
> identifier appears in the algorithm field as an
> AlgorithmIdentifier, the encoding SHALL omit the parameters field.
> That is, the AlgorithmIdentifier SHALL be a SEQUENCE of one
> component, the OID id-dsa-with-sha224 or id-dsa- with-sha256.
>
> Encoding rules for DSA signature values are specified in [RFC
> 3279].
>
> 3.2 ECDSA Signature Algorithm
>
> The Elliptic Curve Digital Signature Algorithm (ECDSA) is defined
> in, "Public Key Cryptography for the Financial Services Industry:
> The Elliptic Curve Digital Signature Standard (ECDSA)" [X9.62].
> The ASN.1 OIDs used to specify that an ECDSA signature was
> generated using SHA-224, SHA-256, SHA-384 or SHA-512 are
> respectively:
>
> ecdsa-with-SHA224 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
> us(840) ansi-X9- 62(10045) signatures(4) ecdsa-with-SHA2(3)
> 1 }
>
> ecdsa-with-SHA256 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
> us(840) ansi-X9- 62(10045) signatures(4) ecdsa-with-SHA2(3)
> 2 }
>
> ecdsa-with-SHA384 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
> us(840) ansi-X9- 62(10045) signatures(4) ecdsa-with-SHA2(3)
> 3 }
>
> ecdsa-with-SHA512 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
> us(840) ansi-X9- 62(10045) signatures(4) ecdsa-with-SHA2(3)
> 4 }
>
> When the ecdsa-with-SHA224, ecdsa-with-SHA256, ecdsa-with-SHA384
> or ecdsa-with-SHA512 algorithm identifier appears in the algorithm
> field as an AlgorithmIdentifier, the encoding MUST omit the
> parameters field. That is, the AlgorithmIdentifier SHALL be a
> SEQUENCE of one component, the OID ecdsa-with-SHA224,
> ecdsa-with-SHA256, ecdsa-with- SHA384 or ecdsa-with-SHA512.
>
> Conforming CA implementations MUST specify the hash algorithm
> explicitly, using the OIDs specified above, when encoding
> ECDSA/SHA2 signatures in certificates and CRLs.
>
> Conforming client implementations that process ECDSA signatures
> with any of the SHA-2 hash algorithms when processing certificates
> and CRLs MUST recognize the corresponding OIDs specified above.
>
> Encoding rules for ECDSA signature values are specified in [RFC
> 3279].
>
> 4. Security Considerations
>
> NIST has defined appropriate use of the hash functions in terms of
> the algorithm strengths and expected time frames for secure use in
> Special Publications (SPs) 800-78-1 [SP 800-78-1], 800-57 [SP
> 800-57] and 800-107 [SP 800-107]. These documents can be used as
> guides to choose appropriate key sizes for various security
> scenarios.
>