Subject: [pkix] Two Comments on draft-ietf-pkix-pubkey-caps-05

From: Russ Housley <[email-masked]>
Date: Wed, 25 Apr 2012 08:36:12 -0400

I am raising two non-blocking comments on draft-ietf-pkix-pubkey-caps-05.

(1) First comment:

My comment:
>>  Should the capabilities in section 3.1 provide an optional way to
>>  specify sizes of P, Q, and G that are supported?
>> 
>>  Similarly, should the capabilities in section 3.2 provide an optional
>>  way to specify sizes of P and G that are supported?

Jim's initial response:
> I wish that you had brought this issue up when the document was still in the working group.  Please post a message to this effect to the working group with a rational for why you believe that this is something that should be done.  My first blush impression is that for 3.1 the response would be no as these sizes are generally fixed by the NIST documents that cover the different sizes of DSA.
> 
> It might be useful for 3.2, but in general I don't believe that it would generally be used.  Do you have a situation where you think it might be of importance?

My reply to Jim's initial response:
I am aware of hardware implementation that have limitations on the size of these parameters.  So, the reason for sizes here is the same as the reason for RSA key sizes.

(2) Second comment:

My comment:
>>  In Section 4.1 and 4.2 and 4.3, I suggest a list of named curves
>>  instead of the very rich structure that is currently specified.
>>  Several other documents have taken this approach.  Any popular curve
>>  can be assigned an object identifier to name it.

Jim's initial response:
> The current text effectively does this in the same way that PKIX certificates do this.  The text states that only the namedCurve option of the ECParameters structure is going to be used.  Do believe that this is not sufficient?

My reply to Jim's initial response:
I do not think the current text does this.  It says:
|
| ...  As specified in [RFC3279], for PKIX compliant
| certificates only the namedCurve choice of ECParameters is
| expected to be used.
|
This does not say that only namedCurve is permitted.  This says to me that is the normal case, but be prepared to receive the others.

Russ

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 25 Apr 2012 23:05:13 -0700

Russ has requested a change during IESG review of this document for the
Diffie-Helman S/MIME Capability fields so that the lengths of P, Q and G can
optionally be specified as well.

Unless I hear objections from the working group, I plan to make this change
over the week-end and re-post the draft.

If the chairs believe that this change would require a new WGLC, please
speak up.

Jim

> -----Original Message-----
> From: Russ Housley [mailto:[email-masked]]
> Sent: Wednesday, April 25, 2012 5:36 AM
> To: IETF PKIX
> Cc: Jim Schaad
> Subject: Two Comments on draft-ietf-pkix-pubkey-caps-05
> 
> >>  Similarly, should the capabilities in section 3.2 provide an
> >> optional  way to specify sizes of P and G that are supported?
> 
> Jim's initial response:
> > I wish that you had brought this issue up when the document was still in
> the working group.  Please post a message to this effect to the working
> group with a rational for why you believe that this is something that
should
> be done.  My first blush impression is that for 3.1 the response would be
no
> as these sizes are generally fixed by the NIST documents that cover the
> different sizes of DSA.
> >
> > It might be useful for 3.2, but in general I don't believe that it would
> generally be used.  Do you have a situation where you think it might be of
> importance?
> 
> I am aware of hardware implementation that have limitations on the size of
> these parameters.  So, the reason for sizes here is the same as the reason
for
> RSA key sizes.
> > The current text effectively does this in the same way that PKIX
certificates
> do this.  The text states that only the namedCurve option of the
> ECParameters structure is going to be used.  Do believe that this is not
> sufficient?
> 
> | ...  As specified in [RFC3279], for PKIX compliant certificates only
> | the namedCurve choice of ECParameters is expected to be used.
> |
> This does not say that only namedCurve is permitted.  This says to me that
is
> the normal case, but be prepared to receive the others.
> 
> Russ=