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

From: Daniel Brown <[email-masked]>
Date: Fri, 12 Jun 2009 11:35:40 -0400

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:[email-masked]] 
Sent: Thursday, May 28, 2009 4:38 PM
To: Daniel Brown; [email-masked]
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

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 15 Jun 2009 12:28:11 -0700

>SHA-512 when generating certificates, but MAY use SHA-1.

I strongly dislike SHOULDs that don't come with reasons: how is an implementer supposed to know what to do? How about: Conforming CA implementations SHOULD use SHA-224, SHA-256, SHA-384 or SHA-512 when generating certificates, but MAY use SHA-1 if they have a stated policy that requires the use of this weaker algorithm.

>generated in accordance with all the recommendations in [FIPS 186-3].

Here you are  saying "in order to conform with this RFC under the IETF standard track rules, you must conform to that FIPS document under NIST's rules." Of course, you do not list all the requirements from FIPS 186-3 that you mean. For example, some of those rules in fact don't live in FIPS 186-3, but instead in NIST SP 800-89, and others live in other documents, some of which are now under revision.

This kind of requirement is fine for a NIST document because NIST can make their own rules and enforce them as they see fit. This kind of requirement is also fine for an Informational RFC, but is completely inappropriate for a standards-track RFC. The requirement should be removed, or the intended status of this document should be Informational RFC. I would prefer the former, but others may prefer the latter.

>be generated in accordance with all the recommendations in [X9.62].

Ditto, except that now it's s/NIST/ANSI/.

>security considerations may be used as a guide.

This is very good wording for the security considerations.

--Paul Hoffman, Director
--VPN Consortium

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 16 Jun 2009 19:26:59 +0200

In general I agree with Paul here. Regardless of what we define, it should
be said in a way that is clear and unambiguous. We should also be clear
about what requirements we state. A simple open reference to all
requirements of another standard is not a good way to specify IETF
requirements. 

I personally dislike standards stating requirements on algorithm support for
any reason other than to increase interoperability. The choices of adequate
and secure algorithms is a constantly moving target and is ideally better
stated in BCP documents if the rationale is purely security driven.

We have to remember that our protocols may be used under vastly different
security policies. Without knowing them, it is almost impossible to define
what is appropriate, unless when something is completely broken.

/Stefan

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

> I strongly dislike SHOULDs that don't come with reasons: how is an implementer
> supposed to know what to do? How about: Conforming CA implementations SHOULD
> use SHA-224, SHA-256, SHA-384 or SHA-512 when generating certificates, but MAY
> use SHA-1 if they have a stated policy that requires the use of this weaker
> algorithm.
> 
> 
>> ***
> Here you are  saying "in order to conform with this RFC under the IETF
> standard track rules, you must conform to that FIPS document under NIST's
> rules." Of course, you do not list all the requirements from FIPS 186-3 that
> you mean. For example, some of those rules in fact don't live in FIPS 186-3,
> but instead in NIST SP 800-89, and others live in other documents, some of
> which are now under revision.
> 
> This kind of requirement is fine for a NIST document because NIST can make
> their own rules and enforce them as they see fit. This kind of requirement is
> also fine for an Informational RFC, but is completely inappropriate for a
> standards-track RFC. The requirement should be removed, or the intended status
> of this document should be Informational RFC. I would prefer the former, but
> others may prefer the latter.
> 
>> ***

---

From: Michael StJohns <[email-masked]>
Date: Tue, 16 Jun 2009 14:04:22 -0400

Yes and no.

The policy for the IETF has always been to specify a minimum set of interoperable algorithms as MUSTs and those generally get specified in the standard or amendments to the standard.  Over time, we recognize that older algorithms no longer meet the minimum security needs and they should first be deprecated and then obsoleted.  

BCPs are not standards documents per se - they are not generally controlling on the implementors, but are targeted for the operators/users who may be quite removed from the implementors.  As such, BCPs may not be (IMHO are not) the right place for specifying the minimums for algorithm support.

So - mostly no.

Mike

At 01:26 PM 6/16/2009, Stefan Santesson wrote:
>The choices of adequate

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 16 Jun 2009 21:43:56 +0200

Mike,

I agree and I think we are saying the same thing in slightly different ways.

What I said before your cut was:

 "I personally dislike standards stating requirements on algorithm support
for any reason other than to increase interoperability."

The key is that we list algorithms in standards more to support
interoperability than to state what security level that is adequate for
certain usages of a protocol.

/Stefan

On 09-06-16 8:04 PM, "Michael StJohns" <[email-masked]> wrote:

> 
> Yes and no.
> 
> The policy for the IETF has always been to specify a minimum set of
> interoperable algorithms as MUSTs and those generally get specified in the
> standard or amendments to the standard.  Over time, we recognize that older
> algorithms no longer meet the minimum security needs and they should first be
> deprecated and then obsoleted.
> 
> BCPs are not standards documents per se - they are not generally controlling
> on the implementors, but are targeted for the operators/users who may be quite
> removed from the implementors.  As such, BCPs may not be (IMHO are not) the
> right place for specifying the minimums for algorithm support.
> 
> So - mostly no.
> 
> Mike
> 
>

---

From: Daniel Brown <[email-masked]>
Date: Tue, 16 Jun 2009 16:19:46 -0400

> Conforming CA implementations SHOULD

Great.

For ideal interoperability and security, this draft should be as a
well-defined as possible.  In particular, it could specify what is meant by
DSA, SHA-2, etc., which can be done by normative reference to other
specifications, such as ANSI/NIST documents.  (Perhaps, past PKIX practice
has been to cite a crypto algorithm by informative reference, but wouldn't
it be better to use a normative reference?)

This draft can explicitly exempt any requirements in the normative
references that PKIX deems unsuitable, or only require certain parts of the
normative references, whichever is clearer.  Please suggest a solution along
these lines if you have one.

If these approaches are too impractical, I suggest a compromise: apply a
blanket SHOULD to all the requirements (not recommendations) in the
corresponding NIST/ANSI documents either with a few explicit exceptions for
the requirements PKIX deems unsuitable - I again ask for a suggested list of
exceptions - or with a blanket exemption MAY with reasons similar to the
reason above for continuing to use SHA-1.

Best regards,

	Dan

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]] 
Sent: Tuesday, June 16, 2009 1:27 PM
To: Paul Hoffman; Daniel Brown; [email-masked]
Subject: Re: WGLC for draft-ietf-pkix-sha2-dsa-ecdsa-06.txt

/Stefan

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 16 Jun 2009 14:57:34 -0700

At 4:19 PM -0400 6/16/09, Daniel Brown wrote:
>specifications, such as ANSI/NIST documents.

Fully agree.

>  (Perhaps, past PKIX practice

There is no practical difference unless someone eventually tries to move this forwards on the standards ladder, which basically never happens.

>these lines if you have one.

FIPS 186-3 has literally dozens of requirements. It is inappropriate to have to list all of the ones we do not want. For example, this list could debate forever about how needed things such as those in section 4.3.2 are. There are, again, literally dozens of similar examples.

>reason above for continuing to use SHA-1.

<sigh> As discussed earlier, every SHOULD without an explicit explanation of when an implementer can ignore leads to lack of interop or, in many cases worse, lack of security.

If you cannot do the work of picking which of the requirements of FIPS 186-3 and X9.62 you actually want to be mandatory in the IETF sense, it would be better to simply make this an Informational RFC.

--Paul Hoffman, Director
--VPN Consortium

---

From: Tom Gindin <[email-masked]>
Date: Wed, 17 Jun 2009 21:14:01 -0400

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 <[email-masked]> 
Sent by: [email-masked]
06/12/2009 11:35 AM

To
Paul Hoffman <[email-masked]>, "[email-masked]" 
<[email-masked]>
cc

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

Paul,

non-at-issue parts are left out, marked as "...".  I based the text on 
text

Best regards,

                 Dan

...

Abstract
specification applies to the Internet X.509 Public Key infrastructure 
(PKI)

1.                  Introduction
[FIPS 180-3], "Public Key Cryptography for the Financial Services 
Industry:
 
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.

Conforming CA implementations that generate DSA signatures for 
certificates
requirements in [FIPS 186-3].  Similarly, such DSA signatures SHOULD also 
be

ecdsa-with-SHA512 algorithm identifier appears in the algorithm field as 
an
Conforming client implementations that process ECDSA signatures with any 
of
Conforming CA implementations that generate ECDSA signatures in 
certificates
requirements specified in [X9.62].  Similarly, such ECDSA signatures 
SHOULD

4.    ASN.1 Module 

...

***

6.    References

...

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

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

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.

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.

pointing to them would be good as well (I'm not aware of any such 
competing

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, 18 Jun 2009 08:43:04 -0700

>referencing multiple long documents and expecting implementors to read

That definitely works for me, assuming that you mean "replace the SHOULDs and MUSTs" with the above wording.

--Paul Hoffman, Director
--VPN Consortium

---

From: Tom Gindin <[email-masked]>
Date: Fri, 19 Jun 2009 01:19:40 -0400

I'm not in charge of this draft, of course, but my draft paragraph 
is more a citation of others' reasonably informed opinion than an explicit 
recommendation.  It doesn't need either a SHOULD or a MUST.  If we need to 
give firmer guidance, I myself would suggest a pair of SHOULD's, but no 
MUST's.
        The first appropriate SHOULD implied is "An implementor in an 
environment where a symmetric key of length L bits is often used SHOULD 
NOT use a hash algorithm with an output length of less than 2L bits for 
digital signatures".  That's an implication of NIST's analysis, and I see 
no reason not to use it.  The other is "Signatures expected to be verified 
more than a few weeks after they are produced SHOULD NOT use any hash 
algorithm with an output length of 160 bits or less".  Long-term 
verification naturally calls for a margin of safety above other 
signatures, and I would not want to present a signature for long-term 
verification that NIST has already declared too short (as they will do to 
SHA-1 at the end of 2009), unless I had concrete reasons for doubting 
their judgement.

                Tom Gindin

Paul Hoffman <[email-masked]> 
06/18/2009 11:43 AM

To
Tom Gindin/Watson/IBM@IBMUS, Daniel Brown <[email-masked]>
cc
"[email-masked]" <[email-masked]>
Subject
RE: WGLC for draft-ietf-pkix-sha2-dsa-ecdsa-06.txt

>referencing multiple long documents and expecting implementors to read

That definitely works for me, assuming that you mean "replace the SHOULDs 
and MUSTs" with the above wording.

--Paul Hoffman, Director
--VPN Consortium