Subject: RE: Last Call Comments on ecc-subpubkeyinf-08

From: "Turner, Sean P." <[email-masked]>
Date: Thu, 2 Oct 2008 12:13:49 -0400

Jim,

Thanks for taking the time to review the draft.  Responses are inline.

spt 

>-----Original Message-----
>  1.  Is ECParameters considered to be extensible?  The 
>following text says yes, but the ASN.1 does not make this explicit.
>
>   The addition of any new choices in ECParameters ought to be 
>   coordinated with ANSI X9.

I'll change it to:

ECParameters ::= CHOICE {
  namedCurve      CURVE.&id({NamedCurve}),
  implicitCurve   NULL,
  -- specifiedCurve  SpecifiedECDomain
  ... -- Extensible
}
  -- 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 ASNI X.9.

>2.  The text in section 2.1 is a bit odd.  It says that ECDH 
>is defined as... and then what follows is the definition of an 
>ECDH specific Public Key, not the key agreement algorithm.  
>This text should be clarified about what is being identified 
>at this point.

How about:

o pk-ecDH indicates that the algorithm that can be used with the subject
public key is restricted to the Elliptic Curve Diffie-Hellman algorithm.
See Section 2.1.2.  This choice MAY be supported.

o pk-ecMQV indicates that the algorithm that can be used with the subject
public key is restricted to the Elliptic Curve Menezes-Qu-Vanstone key
agreement algorithm.  See Section 2.1.2.    This choice MAY be supported.

>3.  Section 3 is not consistent in nomenclature.  It specifies 
>id-ecPublicKey, but then specifies ecDH not id-ecDH.  This 
>usage needs to be consistent to either the object or the OID.

See #4

>4.  Section 3 - it would be nice if the last paragraph was 
>formatted the same as the preceding paragraphs so that the 
>bits set are simple to understand.

How about:

If the keyUsage extension is present in a certificate that indicates id-ecDH
or id-ecMQV in subjectPublicKeyInfo, then the following MUST be present

  keyAgreement;

the following MUST NOT be present:

  digitalSignature;
  nonRepudiation;
  keyTransport;
  keyCertSign; and,
  and cRLSign

the following MAY be present:

 encipherOnly; or,
 decipherOnly.

>5.  Is there a reason why a pk-ecDSA public key is not defined 
>that can only be used with for the purposes of signing?  I 
>realize this is somewhat duplicated by the signing only bit, 
>however there might be a new ECC signing algorithm that comes 
>into existence in the future.

The design team felt that ECDSA was already in the wild and implemented with
id-ecPublicKey so we didn't want to disturb the installed base.  The design
team felt constraints (if needed) would only need to be applied to ECC key
agreement algorithms.  If the new algorithm can't be represented by
id-ecPublicKey the same way ECDSA, ECDH, and ECMQV can all be represented by
id-ecPublicKey, then a new OID will need to be assigned for the future
signature algorithm.