Subject: AD comments for draft-ietf-pkix-ecc-subpubkeyinfo-09

From: <[email-masked]>
Date: Thu, 13 Nov 2008 15:10:32 +0200

I'm now doing the AD review for draft-ietf-pkix-ecc-subpubkeyinfo-09.
My situation is slightly unusual, since I've never read the draft
before -- usually the AD has followed the draft for some time, and is
at least somewhat familiar with the WG discussions that lead to making
the decisions that were made. So, I might be asking questions that
were discussed already earlier...

In general, the document looks quite good. I've identified couple 
of topics that I'd like to discuss with the WG (plus some minor
clarifications/comments):

Topic #1: implicitCurve

I'd like to better understand the motivation behind this option.
It certainly saves ~10 bytes (one OID) in the certificate, but doesn't
it also mean the end-entity certificate does not any longer contain 
the whole public key? (since the ECPoint value alone is not useful 
without knowing the curve)

If that's the case, it would significantly complicate using the
certificate to "carry public keys" in situations where the recipient
does not necessarily do path validation (and may not have the issuer's
public key).

This situation is of course very common in web browsing (browser asks
you whether you want to accept the certificate anyway), but occurs
also in e.g. DTLS-SRTP and RFC 4572 (where the party receiving the
certificate might do real path validation, or might just check that it
matches the fingerprint received in SIP/SDP), and Syslog-over-TLS
(where small implementations might use fingerprints instead of path
validation, even if the certificate isn't self-signed). And I'm pretty
sure more uses like this will be specified in the future.

Would the spec be missing important functionality if it just said
"implicitCurve MUST NOT be used" (like it says for specifiedCurve)?

Topic #2: scope of Appendix A

For a document that specifies how to carry ECC public keys in
SubjectPublicKeyInfo, I was sort of expecting ASN.1 module(s) to do
so.  When I got to Appendix A, I was very surprised to find ASN.1
modules that contain mostly other things (not related to ECC at all,
or not related to SubjectPublicKeyInfo) -- nothing in the main
document (abstract and Sections 1..8) hinted that this would be
coming. Could you briefly explain why ASN.1 about RSA, DSA, MD5, 
etc. belongs in this document?

Topic #3: "informative" ASN.1

I'm wondering whether calling a section consisting solely of formal
language "informative" makes sense, and if just adding that one word
avoids a normative reference to draft-ietf-pkix-new-asn1 (due to
"IMPORTS" -- a case which is mentioned explicitly in RFC 3967).

It looks like stuff implementors would use, and perhaps more
importantly, something writers of future IETF specifications might
want to use. Can we simultaneously claim it's not really part of the
specification (and thus the reference to new-asn1 is not normative)
and allow future documents to import from it (with a normative
reference)?

The remaining comments are basically questions or suggestions
for minor clarifications:

- Section 2.2: ANSI X9.62 specifies a third point form (that isn't 
in [SEC1]); should this text say "the hybrid form MUST NOT be used"?
Or is the intent something else?

- I'm trying to understand how this ASN.1 fragment (and several
other similar cases) can actually compile:

   sa-rsaWithMD2 SIGNATURE-ALGORITHM ::= { 
     IDENTIFIER md2WithRSAEncryption 
     PARAMS TYPE NULL ARE present 
     HASHES { mda-md2 } 
     PUBLIC KEYS { pk-rsa } 
   } 

I'm puzzled because the string "present" is not one of the values
enumerated in ParamOptions -- but perhaps it's an ASN.1 keyword or
something?  (I have to admit that while I could usually read the old
1988 ASN.1 syntax, I don't really understand how this CLASS stuff
works...)

- A question: for some AlgorithmIdentifiers it's occasionally been
unclear whether the parameters must be NULL, must be omitted, or if
either is allowed. This document looks quite clear about this topic --
but is it 100% consistent with e.g. RFC 3279, PKCS#1 and other
relevant documents? If it's not, it would be important to explicitly
point out the differences.

- Section 2.1.2 says "Algorithms used with elliptic curve cryptography
fall in two different categories: signature and key agreement
algorithms." Do you consider encryption schemes such as ECIES
(specified in IEEE 1363) to be "key agreement"? (it certainly has
similarities to ECDH). This question is also relevant for Section 3,
where keyEncipherment bit is never mentioned.  Or perhaps the text's
intent is that other uses of elliptic curves than ECDSA/ECDH/ECMQV
are beyond the scope?

- The ASN.1 modules in Appendix A have a number of "TBA" values -- 
it would be a good idea to have an explicit note (in the document) 
saying who will fill them and at what point. Also, it's slightly 
difficult to tell which TBAs refer to the same value, and which 
to different values -- using something like "TBA1", "TBA2", etc., 
might help.

- Typos:
Section 2.1.1 "ASNI" 
Appendix A.3, should "FROM PKIXCurves" be "FROM PKIXCurves-2008"?
Appendix A.4, "id-mod-algorithInformation" 

Best regards,
Pasi

---

From: "Turner, Sean P." <[email-masked]>
Date: Thu, 13 Nov 2008 15:24:21 -0500

Pasi,

Thanks for your comments.  Responses inline.

spt

>-----Original Message-----
>From: [email-masked]
>Sent: Thursday, November 13, 2008 8:11 AM
>To: [email-masked]
>Subject: AD comments for draft-ietf-pkix-ecc-subpubkeyinfo-09
>
>
>My situation is slightly unusual, since I've never read the 
>draft before -- usually the AD has followed the draft for some 
>time, and is at least somewhat familiar with the WG 
>discussions that lead to making the decisions that were made. 
>So, I might be asking questions that were discussed already earlier...
>
>In general, the document looks quite good. I've identified 
>couple of topics that I'd like to discuss with the WG (plus some minor

To answer your questions:

1) Using parameter inheritance would mean that the EE certificate would not
contain all of the necessary information that would be required for relying
party to process a certificate.  The relying party might luck in to guessing
the curve because there are only so many "well known" curves for a given key
size, but to be sure the relying party would need to get the curve either
from an issuer's certificate or through some other means.  The last
paragraph of 2.1.1 address these options.

2) The rationale for retaining parameter inheritance 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.

It's PKIX so we generally assume people are doing path validation ;)

>etc. belongs in this document?

One of early comments was that since we're updating RFC 3279, we'd end up
with a Chinese menu for implementers if we didn't update the entire RFC 3279
module.  RFC 3279 includes more than ECC "stuff" so if we update the RFC
3279 module have baggage.

>and allow future documents to import from it (with a normative

The reference to draft-ietf-pkix-new-asn1 is an informative reference.  I
wish the reference could be normative, but we'd be blocked on it.  We could
1) pull the appendix out of the document (we'd have some text tweaking to
do) and put the appendix in a) separate document b) put it in
draft-ietf-pkix-new-asn1 2) leave it in the document and produce an update
after draft-ietf-pkix-asn1 gets published that says the appendices are now
normative 3) indicate that it does not form a normative part of the document
(not sure what we'd do with the reference).  I am willing to be guided on
the best way forward.

>Or is the intent something else?

I do not remember discussing the hybrid form and I don't remember back to
the RFC 3279 discussion wrt to the hybrid form.   I would propose we add a
new second sentence to the seconds paragraph "The hybrid form from [X9.62]
MUST NOT be used."

>1988 ASN.1 syntax, I don't really understand how this CLASS stuff

"present" needs to be replaced by "required" (in 3 places).  I had a module
that I was compiling and I forgot to copy over these changes :(

>point out the differences.

I believe we're consistent.

>intent is that other uses of elliptic curves than ECDSA/ECDH/ECMQV

I definitely wasn't (not sure about the other authors) thinking about ECIES
when working on this ID.  That sentence was meant to be more of an
introductory sentence to explain why we've got three OIDs.  We could do the
following for 2.1.2 (but does this address your comment?):

OLD:

Algorithms used with elliptic curve cryptography fall in two different
categories: signature and key agreement algorithms.  ECDSA uses the pk-ec
identifier described in 2.1.1. Two sets of key agreement algorithms are
identified herein: the Elliptic Curve Diffie-Hellman (ECDH) key agreement
scheme and the Elliptic Curve Menezes-Qu-Vanstone (ECMQV) key agreement
scheme. All algorithms are identified by an object identifier and have
parameters.  The object identifier varies based on the algorithm but the
parameters are always ECParameters and they MUST always be present (see
Section 2.1.1).

NEW:

Two "restricted" algorithms are defined for key agreement algorithms: the
Elliptic Curve Diffie-Hellman (ECDH) key agreement scheme and the Elliptic
Curve Menezes-Qu-Vanstone (ECMQV) key agreement scheme. Both algorithms are
identified by an object identifier and have parameters.  The object
identifier varies based on the algorithm but the parameters are always
ECParameters and they MUST always be present (see Section 2.1.1).

>to different values -- using something like "TBA1", "TBA2", etc., 

I'll add a note in Appendix A to indicate that all the TBAs are going to
filled in during AUTH48.

>Appendix A.4, "id-mod-algorithInformation" 

I'll fix these.

---

From: <[email-masked]>
Date: Mon, 17 Nov 2008 18:02:38 +0200

Sean,

Thanks for a quick reply!

> 1) Using parameter inheritance would mean that the EE certificate
> would not contain all of the necessary information that would be
> required for relying party to process a certificate.  The relying
> party might luck in to guessing the curve because there are only so
> many "well known" curves for a given key size, but to be sure the
> relying party would need to get the curve either from an issuer's
> certificate or through some other means.  The last paragraph of
> 2.1.1 address these options.

Hmm -- guessing the curve sounds like it could be dangerous?
(But I haven't really thought what the attacks could be..)

> 2) The rationale for retaining parameter inheritance 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.

With DSA, inheritance saves hundreds of bytes, so this optimization
makes more sense there. Also, I think ECDSA could get more widely used
than DSA has been (and in more open and non-homogeneous environments),
so there are more opportunities for problems to arise. (But opinions
from other WG members would be welcome, too.)

> It's PKIX so we generally assume people are doing path validation ;)

Well, that's not always what other IETF WGs are doing :) 

> One of early comments was that since we're updating RFC 3279, we'd
> end up with a Chinese menu for implementers if we didn't update the
> entire RFC 3279 module.  RFC 3279 includes more than ECC "stuff" so
> if we update the RFC 3279 module have baggage.

Sounds like a reasonable explanation. Could you add a sentence or two
to the document abstract and introduction explaining this?

<snip>
> The reference to draft-ietf-pkix-new-asn1 is an informative
> reference.  I wish the reference could be normative, but we'd be
> blocked on it.  We could 1) pull the appendix out of the document
> (we'd have some text tweaking to do) and put the appendix in a)
> separate document b) put it in draft-ietf-pkix-new-asn1 2) leave it
> in the document and produce an update after draft-ietf-pkix-asn1
> gets published that says the appendices are now normative 3)
> indicate that it does not form a normative part of the document (not
> sure what we'd do with the reference).  I am willing to be guided on
> the best way forward.

I guess this depends how soon draft-ietf-pkix-new-asn1 is going
to be ready. If we want to publish ecc-subpubkeyinfo first, 
I would suggest moving Appendix A.4 to draft-ietf-pkix-new-asn1.

> I do not remember discussing the hybrid form and I don't remember
> back to the RFC 3279 discussion wrt to the hybrid form.  I would
> propose we add a new second sentence to the seconds paragraph "The
> hybrid form from [X9.62] MUST NOT be used."

Ok with me.

> "present" needs to be replaced by "required" (in 3 places).  I had 
> a module that I was compiling and I forgot to copy over these 
> changes :(

Ok (the spelling of "prefered" vs. "preferred" also needs to be 
checked).

<snip>
> NEW:
> 
> Two "restricted" algorithms are defined for key agreement
> algorithms: the Elliptic Curve Diffie-Hellman (ECDH) key agreement
> scheme and the Elliptic Curve Menezes-Qu-Vanstone (ECMQV) key
> agreement scheme. Both algorithms are identified by an object
> identifier and have parameters.  The object identifier varies based
> on the algorithm but the parameters are always ECParameters and they
> MUST always be present (see Section 2.1.1).

Works for me.

Best regards,
Pasi

---

From: "Turner, Sean P." <[email-masked]>
Date: Tue, 18 Nov 2008 13:41:54 -0600

>From: [email-masked] [mailto:[email-masked]] 
>
>Sean,
>
>With DSA, inheritance saves hundreds of bytes, so this 
>optimization makes more sense there. Also, I think ECDSA could 
>get more widely used than DSA has been (and in more open and 
>non-homogeneous environments), so there are more opportunities 
>for problems to arise. (But opinions from other WG members 
>would be welcome, too.)

I talked to the one advocate (i.e., Russ H.) and he said he was fine taking
it out.  Nobody else has posted anything suggesting that they were
interested in this choice.  I'll comment it out, add some text to the ASN.1
note (the '88 ASN.1 below), and modify the bullet:

ECParameters ::= CHOICE {
  namedCurve         OBJECT IDENTIFIER
  -- implicitCurve   NULL
  -- specifiedCurve  SpecifiedECDomain
}
  -- implicitCurve and specifiedCurve MUST NOT be used in PKIX.
  -- Details for SpecifiedECDomain can be found in [X9.62].
  -- Any future additions to this CHOICE should be coordinated
  -- with ANSI X.9.

o implicitCurve allows the elliptic curve parameters to be inherited.  This
choice MUST NOT be used.

>> >coming. Could you briefly explain why ASN.1 about RSA, DSA, 
>MD5, etc. 
>> >belongs in this document?
>> 
>> One of early comments was that since we're updating RFC 
>3279, we'd end 
>> up with a Chinese menu for implementers if we didn't update 
>the entire 
>> RFC 3279 module.  RFC 3279 includes more than ECC "stuff" so if we 
>> update the RFC 3279 module have baggage.
>
>Sounds like a reasonable explanation. Could you add a sentence 
>or two to the document abstract and introduction explaining this?

Yes.

>reference.  
>> I wish the reference could be normative, but we'd be blocked on it.  
>> We could 1) pull the appendix out of the document (we'd have 
>some text 
>> tweaking to do) and put the appendix in a) separate document 
>b) put it 
>> in draft-ietf-pkix-new-asn1 2) leave it in the document and 
>produce an 
>> update after draft-ietf-pkix-asn1 gets published that says the 
>> appendices are now normative 3) indicate that it does not form a 
>> normative part of the document (not sure what we'd do with the 
>> reference).  I am willing to be guided on the best way forward.
>
>I guess this depends how soon draft-ietf-pkix-new-asn1 is 
>going to be ready. If we want to publish ecc-subpubkeyinfo 
>first, I would suggest moving Appendix A.4 to draft-ietf-pkix-new-asn1.

The time frame we're looking to meet for IEEE is RFC status before they go
to ballot.  I think that time frame is sometime in Jan so to do that I think
it might be best to rip out the '02 ASN.1 module.  Turns out they don't care
which version of the ASN.1 we use.  I talked with Jim and Paul and they're
happy to put the '02 module in their document so the information won't get
lost.  They're looking at going to WG LC in January so it wouldn't be to far
on the heals of draft-ietf-pkix-ecc-subpubkeyinfo.  There's some from matter
text tweaking that will need to be done to remove the '02 syntax but it
shouldn't take too long.  We'll also revert back to one ASN.1 module because
we're not duplicating the OIDs in multiple places in this document.

spt

---

From: Stephen Kent <[email-masked]>
Date: Thu, 20 Nov 2008 10:02:25 -0500

Sean & Pasi,

I am comfortable with these changes.

If anyone in the WG objects, say so now, else we will consider the 
previous WGLC to still be valid.

Steve