Subject: work item approval request

From: Stephen Kent <[email-masked]>
Date: Mon, 3 Dec 2007 17:02:17 -0500

Folks,

The ECC design team has proposed a solution to the (long standing) 
problem of what info re use of ECC algs is to be represented in a 
cert, and how to represent the info.  Via this message I am asking 
that WG members submit comments on adopting this as PKIX WG item.

See the PKIX WG slides posted for this IETF meeting for the 
background. The PKIX WG minutes relevant to this topic are reproduced 
below.

Subject public key info resolution for ECC - Tim Polk (NIST)
  The design team has been addressing the question of how to represent 
algorithm info for ECCs, not just curve info but also ways to 
restrict use of the key, e.g., for Elliptic Curve Diffie-Hellman vs. 
ECMQV. The proposal (second pass) is to be able to express only a 
very basic constraint, i.e., whether a key is to be restricted to 
ONLY Elliptic Curve Diffie-Hellman or ONLY ECMQV. Thus, the existing 
ecPublicKey OID will be interpreted as allowing the pubic key to be 
used with either of these algorithms, and two new OIDs will be 
assigned to represent these other two cases. This is consistent with 
the RSA-context solution adopted in RFC 4055. It is also compliant 
with a subset of the X9.62 standards. Also, a suggested change to RFC 
4055, to say that KDF restrictions MUST NOT (vs. SHOULD NOT) appear 
in certificates, i.e., these restrictions are the provenance of 
applications. The outcome is that the design team will submit a new 
I-D that will update 3279 and obsolete 4055, but will not adversely 
affect extant implementations, based on the data gathered by the 
team. Steve Kent will formally ask the WG to confirm that there is no 
objection to adopting this as a PKIX work item. (Slides)

---

From: Russ Housley <[email-masked]>
Date: Mon, 03 Dec 2007 18:59:32 -0500

As a member of the design team, I support the way forward, and I'm 
willing to help write the document that is needed to implement the 
proposed solution.

Russ

At 05:02 PM 12/3/2007, Stephen Kent wrote:
>background. The PKIX WG minutes relevant to this topic are reproduced below.
>
>  The design team has been addressing the question of how to 
> represent algorithm info for ECCs, not just curve info but also 
> ways to restrict use of the key, e.g., for Elliptic Curve 
> Diffie-Hellman vs. ECMQV. The proposal (second pass) is to be able 
> to express only a very basic constraint, i.e., whether a key is to 
> be restricted to ONLY Elliptic Curve Diffie-Hellman or ONLY ECMQV. 
> Thus, the existing ecPublicKey OID will be interpreted as allowing 
> the pubic key to be used with either of these algorithms, and two 
> new OIDs will be assigned to represent these other two cases. This 
> is consistent with the RSA-context solution adopted in RFC 4055. It 
> is also compliant with a subset of the X9.62 standards. Also, a 
> suggested change to RFC 4055, to say that KDF restrictions MUST NOT 
> (vs. SHOULD NOT) appear in certificates, i.e., these restrictions 
> are the provenance of applications. The outcome is that the design 
> team will submit a new I-D that will update 3279 and obsolete 4055, 
> but will not adversely affect extant implementations, based on the 
> data gathered by the team. Steve Kent will formally ask the WG to 
> confirm that there is no objection to adopting this as a PKIX work 
> item. (Slides)

---

From: "Kemp, David P." <[email-masked]>
Date: Tue, 4 Dec 2007 09:49:13 -0500

As an interested observer of the design team, I fully support
this K.I.S.S. approach.

I also support saying that KDF restrictions (for ECDH/ECMQV)
and by extension hash algorithm restrictions (for ECDSA) MUST NOT
appear in PKIX-compliant certificates, as opposed to the
weaker SHOULD NOT.  This does not prohibit applications from
recognizing such restrictions profiled elsewhere, nor does it
prohibit CAs from following non-PKIX profiles with such
restrictions.  It also does not inhibit use of external
algorithm definitions that specify a specific KDF or hash
algorithm to be used with specific public key sizes.

Dave Kemp

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Russ Housley
Sent: Monday, December 03, 2007 7:00 PM
To: Stephen Kent; [email-masked]
Subject: Re: work item approval request

Russ

below.

---

From: Sam Hartman <[email-masked]>
Date: Tue, 04 Dec 2007 11:25:45 -0500

>>>>> "Kemp," == Kemp, David P <[email-masked]> writes:

    Kemp,> As an interested observer of the design team, I fully
    Kemp,> support this K.I.S.S. approach.

The design team proposal seemed reasonable to me.  I have not read the
document though.

---

From: "Kemp, David P." <[email-masked]>
Date: Tue, 4 Dec 2007 14:10:05 -0500

As far as I know, the design team never produced a concrete syntax for
the extension proposed on slide 23 of:
http://www3.ietf.org/proceedings/06nov/slides/pkix-7/sld1.htm.  But
http://www3.ietf.org/proceedings/06nov/IDs/draft-ietf-pkix-ecc-pkalgs-03
.txt is quite complex, and one would assume that an extension derived
from it would inherit at least some of that complexity.

In contrast, the new proposal for 3 OIDs (one existing plus two new) and
no extension is refreshingly simple.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Sam Hartman
Sent: Tuesday, December 04, 2007 11:26 AM
To: [email-masked]
Subject: Re: work item approval request