Subject: draft-ietf-pkix-sha2-dsa-ecdsa-04.txt: ecdsa-with-Specified and ecdsa-with-Recommended

From: "Turner, Sean P." <[email-masked]>
Date: Thu, 11 Sep 2008 22:48:31 -0700

In RFC3279, the object identifier that goes in the signatureAlgorithm and
signature fields represents both the hash algorithm and the signature
algorithm (e.g., ecdsa-with-SHA1).  draft-ietf-pkix-sha2-dsa-ecdsa-04.txt
contains text for two algorithm identifiers that don't follow this rule:
ecdsa-with-Recommended (use the SHS algorithm that has the largest bit size
that does not require bit truncation during signing) and
ecdsa-with-Specified (uses the parameters field to indicate the hash
algorithm's object identifier).  I think we should take these two OIDs (and
the accompanying text) out of the ID.  A simple note indicating that ANSI
X.9 has defined additional object identifiers for these two fields is all
that is needed.

spt

---

From: Russ Housley <[email-masked]>
Date: Fri, 12 Sep 2008 08:52:13 -0400

I do not see any reason to support ecdsa-with-Recommended or 
ecdsa-with-Specified.  Has any implementor found these more 
advantageous than the approach that we have been using since the PKIX 
WG was formed?  If so, please explain to everyone.

Russ

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 12 Sep 2008 08:22:09 -0700

>X.9 has defined additional object identifiers for these two fields is all

That works for me.

FWIW, I think I'm seeing a healthy trend lately here and in the 
S/MIME WG. Instead of "ANSI has defined this so we have to duplicate 
their definition in our work", we are tending more towards "leave 
other people's definitions out but point to them if developers want 
to look". That leads to better specs.

--Paul Hoffman, Director
--VPN Consortium