Subject: Comments on draft-ietf-pkix-ecc-subpubkeyinfo-08

From: "Carl Wallace" <[email-masked]>
Date: Tue, 23 Sep 2008 16:07:23 -0400

Below are a few comments, nits and questions regarding
draft-ietf-pkix-ecc-subpubkeyinfo-08:

- In section 2.1.1, why is implicitCurve not deprecated along with
specifiedCurve?  The text states that implicitCurve is only supported
when namedCurve is not used and there is no option other than namedCurve
available.
- Why is A.2 the informative module?  Most sections in the spec
reference definitions from A.2.  
- Given the amount of repetition between the ASN.1 modules, it may make
more sense to define all of the structures and OIDs once and import them
into one module that uses information objects and one that doesn't.  I
think ECParameters is the only structure that would need to go in the
module that doesn't use information objects.

- Expand EC in third paragraph of section 1
- "algorithms" should be singular in the first sentence of section 2.1
- Provide a reference to 5280 where SubjectPublicKeyInfo is defined in
Section 2
- In 2.1.2, change "fall in to different" to "fall in two different" or
"fall into different"
- Rewrite last sentence of section 3 to remove the condition since the
certificate MUST assert keyAgreement or make the statement about
asserting encipherOnly or decipherOnly one time instead of once per
certificate type.
- In Security Considerations, change "desired have value" to "desired
hash value"
- In second paragraph of section 5, "implementations" should be
singular.
- Where there are references to X9.62, the names of the structures
should be the same.  ECParameters and SpecifiedCurve appear as
ECDomainParameters and SpecifiedECDomain in X9.62.

---

From: "Turner, Sean P." <[email-masked]>
Date: Tue, 23 Sep 2008 18:56:52 -0400

Carl,

Thanks for taking the time to review the draft.  Responses in-line.

spt 

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Carl Wallace
>Sent: Tuesday, September 23, 2008 4:07 PM
>To: [email-masked]
>Subject: Comments on draft-ietf-pkix-ecc-subpubkeyinfo-08

snip

>- In section 2.1.1, why is implicitCurve not deprecated along 
>with specifiedCurve?  The text states that implicitCurve is 
>only supported when namedCurve is not used and there is no 
>option other than namedCurve available.

It does seem like this choice ought to be deprecated too because it says you
always use namedCurve.

>- Why is A.2 the informative module?  Most sections in the 
>spec reference definitions from A.2.  

I figured this was a style thing. I like the class definition way of
defining the keys and curves because I think it's clearer.  BUT, we do have
this problem of a dependancy on draft-ietf-pkix-new-asn1.  If we used the
"old" way of defining the structures in the main body of the document, I'd
recommend blowing away the all of the new ASN.1 and putting it in Jim/Paul's
draft-ietf-pkix-new-asn1 ID or some other ID to not slow down completion.

ALL: Should we only use the "old" ASN.1 in the document and move all the
"new" ASN.1 to another document?  

>- Given the amount of repetition between the ASN.1 modules, it 
>may make more sense to define all of the structures and OIDs 
>once and import them into one module that uses information 
>objects and one that doesn't.  I think ECParameters is the 
>only structure that would need to go in the module that 
>doesn't use information objects.

I made one for curves and one for algorithm IDs, key format, and parameter
structures.  Then imported the curves, IDs, formats, and structures in the
information object module and the curves in to the ECParameters module. I
think it took off 2 pages, but there ought to be less chances of me copying
things incorrectly.

>- Provide a reference to 5280 where SubjectPublicKeyInfo is 
>defined in Section 2
>- In 2.1.2, change "fall in to different" to "fall in two 
>different" or "fall into different"
>- Rewrite last sentence of section 3 to remove the condition 
>since the certificate MUST assert keyAgreement or make the 
>statement about asserting encipherOnly or decipherOnly one 
>time instead of once per certificate type.
>- In Security Considerations, change "desired have value" to 
>"desired hash value"
>- In second paragraph of section 5, "implementations" should 
>be singular.

Fixed

>- Where there are references to X9.62, the names of the 
>structures should be the same.  ECParameters and 
>SpecifiedCurve appear as ECDomainParameters and 
>SpecifiedECDomain in X9.62.

There's been lots of name changes to these four fields. We point to both
SEC1 and ANSI X9 and we also have RFC 3279.  
What we're calling ECParameters:
  RFC3279 called them EcpkParameters
  SEC1 v1 called them Parameters
  ANSI X9.62:2005 called them ECDomainParameters
What we're calling namedCurve:
  RFC3279 called them namedCurve
  SEC1 v1 called them namedCurve
  ANSI X9.62:2005 called them named
What we're calling specifiedCurve:
  RFC3279 called them ecParameters
  SEC1 called them ecParameters
  ANSI X9.62:2005 called them specified
What we're calling SpecifiedCurve:
  RFC3279 called them ECParameters
  SEC1 called them ECParameters
  ANSI X9.62:2005 called them SpecifiedECDomain
What we're calling implicitCurve:
  RFC3279 called them implicitlyCA
  SEC1 called them implicitCA
  ANSI X9.62:2005 called them implicitCA

Seemed like we could do our own thing here.  ECParameters makes sense as a
name for the top level because it's the parameters for the EC.  I aligned
the names to namedCurve, specifiedCurve, and implicitCurve because they're
all variations on a theme: OID, full specification, and implied (can come
from places other than the CA's cert).  I changed the name of SpecifedCurve
to SpecifiedECDomain parameters but left the other field names as is.

---

From: Russ Housley <[email-masked]>
Date: Wed, 24 Sep 2008 09:05:49 -0400

Two points.

My initial reaction to implicitCurve is that many people that support 
DSA already deal with parameter inheritance in that context.  So, it 
may not be a burden to keep this capability in the 
specification.  Are implementors finding this to be a problem?

It is probably a good idea to avoid the down reference at this 
point.  There are several ways to resolve this concern.  One simple 
way is to include two ASN.1 modules in the this document.

Russ

---

From: "Turner, Sean P." <[email-masked]>
Date: Mon, 29 Sep 2008 11:34:53 -0400

On implicitCurve, the text was written when specifiedCurve was an option.
Now that it's gone, I'd suggest a change from:

o implicitCurve allows the elliptic curve parameters to be inherited.  This
choice MAY be supported, but if subordinate certificates use the same
namedCurve as their superior, then the subordinate certificate MUST use the
namedCurve option. That is, implicitCurve is only supported if the superior
doesn't use the namedCurve option.  

To:

o implicitCurve allows the elliptic curve parameters to be inherited.  This
choice MAY be supported.

spt

>[mailto:[email-masked]] On Behalf Of Russ Housley
>Sent: Wednesday, September 24, 2008 9:06 AM
>To: [email-masked]
>Subject: RE: Comments on draft-ietf-pkix-ecc-subpubkeyinfo-08
>
>
>Two points.
>
>My initial reaction to implicitCurve is that many people that 
>support DSA already deal with parameter inheritance in that 
>context.  So, it may not be a burden to keep this capability 
>in the specification.  Are implementors finding this to be a problem?
>
>point.  There are several ways to resolve this concern.  One 
>simple way is to include two ASN.1 modules in the this document.
>
>Russ
>
>> >when namedCurve is not used and there is no option other than 
>> >namedCurve available.
>>
>>It does seem like this choice ought to be deprecated too because it 
>>says you always use namedCurve.
>>
>>defining the keys and curves because I think it's clearer.  
>BUT, we do 
>>have this problem of a dependancy on draft-ietf-pkix-new-asn1.  If we 
>>used the "old" way of defining the structures in the main body of the 
>>document, I'd recommend blowing away the all of the new ASN.1 and 
>>putting it in Jim/Paul's
>>ALL: Should we only use the "old" ASN.1 in the document and move all 
>>the "new" ASN.1 to another document?
>>
>> >- Given the amount of repetition between the ASN.1 modules, it may 
>> >make more sense to define all of the structures and OIDs once and 
>> >import them into one module that uses information objects and one 
>> >that doesn't.  I think ECParameters is the only structure 
>that would 
>> >need to go in the module that doesn't use information objects.
>>
>>I made one for curves and one for algorithm IDs, key format, and 
>>parameter structures.  Then imported the curves, IDs, formats, and 
>>structures in the information object module and the curves in to the 
>>ECParameters module. I think it took off 2 pages, but there 
>ought to be 
>>less chances of me copying things incorrectly.
>>
>> >- Provide a reference to 5280 where SubjectPublicKeyInfo is defined 
>> >in Section 2
>> >- Rewrite last sentence of section 3 to remove the condition since 
>> >the certificate MUST assert keyAgreement or make the 
>statement about 
>>   ANSI X9.62:2005 called them ECDomainParameters What we're calling 
>>namedCurve:
>>   ANSI X9.62:2005 called them specified What we're calling 
>>SpecifiedCurve:
>>   ANSI X9.62:2005 called them SpecifiedECDomain What we're calling 
>>implicitCurve:
>>Seemed like we could do our own thing here.  ECParameters makes sense 
>>as a name for the top level because it's the parameters for 
>the EC.  I 
>>aligned the names to namedCurve, specifiedCurve, and implicitCurve 
>>because they're all variations on a theme: OID, full 
>specification, and 
>>implied (can come from places other than the CA's cert).  I 
>changed the 
>>name of SpecifedCurve to SpecifiedECDomain parameters but 
>left the other field names as is.
>

---

From: "Kemp, David P." <[email-masked]>
Date: Mon, 29 Sep 2008 14:26:40 -0400

This is a significant change in logic, from implicitCurve MUST NOT be
used (because specifiedCurve is no longer an option) to implicitCurve
MAY be used.

Because DSA certificates don't have an equivalent "namedParameters"
construct, the ability to inherit specified parameters enables some
space savings.  But a namedCurve OID isn't very large so the potential
benefits of implicitCurve aren't very large either.  I'd suggest a
strict/liberal requirement, which in the absence of specifiedCurve may
be simplified to:

o implicitCurve allows the elliptic curve parameters to be inherited.
Certificates MUST use the namedCurve option.  Relying-party applications
MAY support the implicitCurve choice in order to accept certificates
that do not use the namedCurve option.  

Do any implementers who are comfortable with parameter inheritance in
DSA feel that there is any reason to generate ecc certificates using
implicitCurve?
 
Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Turner, Sean P.
Sent: Monday, September 29, 2008 11:35 AM
To: [email-masked]
Subject: RE: Comments on draft-ietf-pkix-ecc-subpubkeyinfo-08

On implicitCurve, the text was written when specifiedCurve was an
option.
Now that it's gone, I'd suggest a change from:

o implicitCurve allows the elliptic curve parameters to be inherited.
This
choice MAY be supported, but if subordinate certificates use the same
namedCurve as their superior, then the subordinate certificate MUST use
the
namedCurve option. That is, implicitCurve is only supported if the
superior
doesn't use the namedCurve option.  

To:

o implicitCurve allows the elliptic curve parameters to be inherited.
This
choice MAY be supported.

spt