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

[<Pasi.Eronen@xxxxxxxxx>]

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