RE: WGLC for draft-ietf-pkix-sha2-dsa-ecdsa-06.txt

[Tom Gindin <tgindin@xxxxxxxxxx>]

        Would it be simple enough to just say that NIST SP 800-57 part 1 
table 3 implies that its authors consider the use of a given hash 
algorithm of the SHA family in digital signatures with an output length of 
2L bits to have roughly comparable strength (presumably against known 
cryptographic attacks) to the use of a symmetric key of L bits?  We can 
also say that NIST has given its own summaries of appropriate key lengths 
for use after a given date in table 4 of that same document, instead of 
referencing multiple long documents and expecting implementors to read 
them.

                Tom Gindin




Daniel Brown <dbrown@xxxxxxxxxxxx> 
Sent by: owner-ietf-pkix@xxxxxxxxxxxx
06/12/2009 11:35 AM

To
Paul Hoffman <paul.hoffman@xxxxxxxx>, "ietf-pkix@xxxxxxx" 
<ietf-pkix@xxxxxxx>
cc

Subject
RE: WGLC for draft-ietf-pkix-sha2-dsa-ecdsa-06.txt






Paul,

I propose the following text (sorry for the poor formatting).  A few
non-at-issue parts are left out, marked as "...".  I based the text on 
text
Quynh Dang prepared that was based on your shortened text.  I added some
SHOULDs and MUSTs based on my previous emails, and have below highlighted
these additions with *** above and below, as these are probably the
most-at-issue parts.

Best regards,

                 Dan

...

Abstract
This document updates RFC 3279 [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 [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.
***
Conforming CA implementations SHOULD use SHA-224, SHA-256, SHA-384 or
SHA-512 when generating certificates, but MAY use SHA-1.
***
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-citt(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]. 
***
Conforming CA implementations that generate DSA signatures for 
certificates
or CRLs MUST generate such DSA signature in accordance with all the
requirements in [FIPS 186-3].  Similarly, such DSA signatures SHOULD also 
be
generated in accordance with all the recommendations in [FIPS 186-3].
***
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 SHA2 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].
***
Conforming CA implementations that generate ECDSA signatures in 
certificates
or CRLs MUST generate such ECDSA signatures in accordance with all the
requirements specified in [X9.62].  Similarly, such ECDSA signatures 
SHOULD
be generated in accordance with all the recommendations in [X9.62].
***

4.    ASN.1 Module 

...

5.    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.

***
ANSI also provides security considerations for ECDSA in [X9.62]. These
security considerations may be used as a guide.
*** 

 
6.    References

...





-----Original Message-----
From: Paul Hoffman [mailto:paul.hoffman@xxxxxxxx] 
Sent: Thursday, May 28, 2009 4:38 PM
To: Daniel Brown; ietf-pkix@xxxxxxx
Subject: RE: WGLC for draft-ietf-pkix-sha2-dsa-ecdsa-06.txt

At 1:59 PM -0400 5/28/09, Daniel Brown wrote:
>Paul,
>
>Regarding your comment 3) below about validation requirements, I suggest
that this RFC 3279 update mandate SHA2 as a "SHOULD" (rather than a MUST 
as
it is in the WGLC draft). 
>
>Not making it a MUST avoids making existing implementations 
non-conformant.
Making it a SHOULD alerts implementers to the security issues and to the
NIST compliance/interoperability issues.

Please be more specific. What exact wording are you proposing? If you were
simply going to replace "MUST" with "SHOULD" in the last paragraph of
section 3, how would an implementer know when it is OK not to follow the
mandate?

As you can tell, this whole train of thought still bothers me. It is fine
for us to list the issues and to make recommendations about them; that is
quite different than invoking RFC 2119 language, particularly in a vague
fashion.

>Regarding your comment 2) below about key sizes and lifetimes, I suggest
this RFC 3279 update make the associated NIST recommendations a SHOULD.
Again, this is for security reasons and better NIST
compliance/interoperability issues. 

And I fully disagree for the same reasons. NIST makes it clear that their
recommendations are for one particular market, not the entire world. If we
want to make them world-wide, then we should help NIST come up with more
consistent and readable recommendations that match the new mandate; so 
far,
NIST has not asked for that type of help, and I would not expect them to 
do
so in the future.

>Generally, the DSA/ECDSA and SHA-1/2 algorithms come from NIST and ANSI,
and have some normative security requirements about key sizes.  Completely
dropping some of the normative security requirements should require strong
justification.

The IETF attempts to create standards that implementers can understand.
Mandating the NIST logic, which conflates different sizes and strengths 
for
reasons that make sense for NIST but not for us, does not lead to such
standards.

Again, it is a good idea to point to the NIST documents as guidance for
implementers. If there were competing documents with different guidance,
pointing to them would be good as well (I'm not aware of any such 
competing
documents). That's quite different than mandating compliance with the NIST
specs that were written for different purposes than we have.

I would still like comment on my greatly-shortened version of this 
document,
as well as on the other concerns expressed on this thread.


--Paul Hoffman, Director
--VPN Consortium