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

From: Stephen Kent <[email-masked]>
Date: Wed, 6 May 2009 11:21:31 -0400

The authors of this I-D have requested that I initiate WGLC.

The last call will run for two weeks, closing on May 20th.

Steve

---

From: Russ Housley <[email-masked]>
Date: Fri, 08 May 2009 13:04:08 -0400

I think the document is ready to go.

MINOR

Much of the information from the RFC 3279  is repeated here, like the 
signature value being a sequence or r and s. However, the parameter 
stuff is not repeated (p, q, g).  The decision of what stuff to 
duplicate (or not) should be all or nothing, I think.

EDITORIAL

The OIDs are not formatted for easy reading.  I liked the layout in 
RFC 4055 better.  For example:

       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 }

Russ

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 9 May 2009 09:50:48 -0700

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.

---

From: Stefan Santesson <[email-masked]>
Date: Sun, 10 May 2009 10:49:14 +0200

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" <[email-masked]> wrote:

> 
> Greetings again. This document is *not* ready for advancement. It has many
> fundamental flaws that prevent it from being an understandable standard.
> 
> 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.
> 
> 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.
> 
> 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.
>

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 10 May 2009 09:19:58 -0700

>For the most part I think your change proposals are fine.

Thanks.

>additional OIDs for the ECDSA signature algorithm.".

I thought about that one, but it seems like a throw-away. Lots of people have defined "additional OIDS". We don't want to say "...and they MUST / SHOULD not be used by conforming systems" because relying parties might want to be able to handle those OIDs. So, I'm not sure of the value of saying that the other spec defined them.

> It may also be useful

No, absolutely not. Let the NIST documents explanations stand on their own. It is not the place of the IETF to try to explain other people's logic, particularly when the other people are not clear in their own documents. This is not a criticism of the documents; I say this as someone who has read and re-read SP 800-57 probably more than almost anyone other than its authors.

Think of it this way: if some association using PKIX required OCSP, and their specification document said "the reason that the IETF made the response codes in OCSP they way they are is...", many of us would first laugh out loud, then probably disagree with what they wrote.

--Paul Hoffman, Director
--VPN Consortium

---

From: Stefan Santesson <[email-masked]>
Date: Sun, 10 May 2009 19:25:49 +0200

On 09-05-10 6:19 PM, "Paul Hoffman" <[email-masked]> wrote:

> I thought about that one, but it seems like a throw-away. Lots of people have
> defined "additional OIDS". We don't want to say "...and they MUST / SHOULD not
> be used by conforming systems" because relying parties might want to be able
> to handle those OIDs. So, I'm not sure of the value of saying that the other
> spec defined them.
> 

I just thought these ones were of particular relevance as x9.62 is a
normative ref.

And we might want to say MUST/SHOULD NOT be used.

But I also see your point. Unless we want to say MUST/SHOULD NOT be used,
then we probably should not mention them.

> No, absolutely not. Let the NIST documents explanations stand on their own. It
> is not the place of the IETF to try to explain other people's logic,
> particularly when the other people are not clear in their own documents. This
> is not a criticism of the documents; I say this as someone who has read and
> re-read SP 800-57 probably more than almost anyone other than its authors.
> 
> Think of it this way: if some association using PKIX required OCSP, and their
> specification document said "the reason that the IETF made the response codes
> in OCSP they way they are is...", many of us would first laugh out loud, then
> probably disagree with what they wrote.
> 
> --Paul Hoffman, Director
> --VPN Consortium

I think it is OK to make it shorter, maybe even down to your suggestion.
I just thought some information you left out could be relevant. For example:

       FIPS 186-3 fully specifies the DSA digital
       signature algorithm and defines security
       requirements for the DSA and ECDSA digital
       signature algorithms; details can be found in
       [FIPS 186-3]. ECDSA is fully specified in [X9.62].
       [FIPS 186-3] also specifies three types of
       elliptic curves for use in conjunction with one of
       the described hash functions: curves over prime
       fields, curves over binary fields, and Koblitz
       curves (anomalous binary curves). FIPS 186-3
       provides a table listing the uses and time periods
       for each algorithm and key size combinations for
       various applications.

Your security considerations section does not mention FIPS 183-3 or X9.62 at
all.

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 10 May 2009 12:28:34 -0700

>       [FIPS 186-3]. ECDSA is fully specified in [X9.62].

These are not security considerations

>       curves (anomalous binary curves).

Nor are these.

>       FIPS 186-3

That is a security consideration, but not a useful one, because FIPS 186-3 just points to SP 800-57, which I already put in there.

>Your security considerations section does not mention FIPS 183-3 or X9.62 at

Correct. If you see some security considerations in either of those two documentst that aren't in SP 800-57, I'm fine with mentioning them in the Security Considerations section; I didn't see them.

--Paul Hoffman, Director
--VPN Consortium

---

From: Stefan Santesson <[email-masked]>
Date: Sun, 10 May 2009 23:25:09 +0200

Paul,

I can live with your text.

/Stefan

On 09-05-10 9:28 PM, "Paul Hoffman" <[email-masked]> wrote:

> That is a security consideration, but not a useful one, because FIPS 186-3
> just points to SP 800-57, which I already put in there.
> 
> Correct. If you see some security considerations in either of those two
> documentst that aren't in SP 800-57, I'm fine with mentioning them in the
> Security Considerations section; I didn't see them.
> 
> --Paul Hoffman, Director
> --VPN Consortium
>

---

From: Daniel Brown <[email-masked]>
Date: Thu, 28 May 2009 13:59:57 -0400

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.

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.  

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. 

Best regards,

Dan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Hoffman
Sent: Saturday, May 09, 2009 12:51 PM
To: [email-masked]
Subject: Re: WGLC for draft-ietf-pkix-sha2-dsa-ecdsa-06.txt

...

---

From: Daniel Brown <[email-masked]>
Date: Thu, 28 May 2009 14:03:19 -0400

Paul,

X9.62-2005, Annex K, Security Considerations does cover topics that I have not seen SP 800-57. 

Therefore, I think X9.62 would be worth mentioning in the security considerations of this RFC 3279 update.

Best regards,

Dan

-----Original Message-----
From: Paul Hoffman
Sent: Sunday, May 10, 2009 3:29 PM
To: Stefan Santesson; [email-masked]
Subject: Re: WGLC for draft-ietf-pkix-sha2-dsa-ecdsa-06.txt

...

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 28 May 2009 13:38:17 -0700

>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…

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 requiremen…

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

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 28 May 2009 13:44:10 -0700

>X9.62-2005, Annex K, Security Considerations does cover topics that I have not seen SP 800-57.

The most relevant ones from X9.62 seem to be covered somewhere in either SP 800-57 or FIPS 186-3. Sure, the crypto geekiness in the earlier part of the appendix is interesting, but probably not relevant to this draft.

>Therefore, I think X9.62 would be worth mentioning in the security considerations of this RFC 3279 update.

It is worth mentioning, sure.

--Paul Hoffman, Director
--VPN Consortium