Subject: WGLC for draft-ietf-pkix-ecc-subpubkeyinfo-08.txt

From: Stephen Kent <[email-masked]>
Date: Wed, 1 Oct 2008 16:16:38 -0400

I have been told that the IEEE 801.1 AR folks are hoping to refer to 
cite draft-ietf-pkix-ecc-subpubkeyinfo as an RFC in their work, so it 
behooves us to move ahead as soon as possible.  It also appears that 
discussion has settled down on this draft, so I am initiating WGLC on 
it as well, effective today, and continuing until 10/15.

Thanks,

Steve

---

From: Russ Housley <[email-masked]>
Date: Thu, 02 Oct 2008 09:51:37 -0400

I have read this document, and I believe that it is ready for the 
PKIX WG to send to the IESG.

I can confirm that a reference for IEEE 802.1AR is desired.

Russ

At 04:16 PM 10/1/2008, Stephen Kent wrote:

>cite draft-ietf-pkix-ecc-subpubkeyinfo as an RFC in their work, so 
>it behooves us to move ahead as soon as possible.  It also appears 
>that discussion has settled down on this draft, so I am initiating 
>WGLC on it as well, effective today, and continuing until 10/15.
>
>Thanks,
>
>Steve

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 07 Oct 2008 15:46:10 +0100

The draft says:

      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.

"MAY be supported" seems wrong, ought it be "MAY be used"?

And could we RECOMMEND that it not be used? I find it hard to see
how a programmer can make the right choice, and easy to see that
a CA operator could make the wrong choice. And its generally a
confusing bit of text.

Otherwise this seems fine as far as I can tell (which isn't far
in the case of EC related stuff:-)

Stephen.

Stephen Kent wrote:
> discussion has settled down on this draft, so I am initiating WGLC on it
> as well, effective today, and continuing until 10/15.
> 
> Thanks,
> 
> Steve
> 
>

---

From: "Turner, Sean P." <[email-masked]>
Date: Wed, 15 Oct 2008 11:42:58 -0400

Stephen,

Carl and Dave also raised a similar comment, but Russ was concerned that
people that do DSA already supported inheritance. Can you live with:

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

spt

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Stephen Farrell
>Sent: Tuesday, October 07, 2008 10:46 AM
>To: [email-masked]
>Subject: Re: WGLC for draft-ietf-pkix-ecc-subpubkeyinfo-08.txt
>
>
>
>The draft says:
>
>And could we RECOMMEND that it not be used? I find it hard to 
>see how a programmer can make the right choice, and easy to 
>see that a CA operator could make the wrong choice. And its 
>generally a confusing bit of text.
>
>Otherwise this seems fine as far as I can tell (which isn't 
>far in the case of EC related stuff:-)
>
>Stephen.
>
>
>
>
>
>Stephen Kent wrote:
>>

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 15 Oct 2008 17:16:35 +0100

> o implicitCurve allows the elliptic curve parameters to be inherited. This

That's clear enough for me, so long as the behaviour of a non-supporting
RP when faced with a cert using this is clear - is it? (I can re-read
the thing but you probably know already:-)

S.

---

From: "Turner, Sean P." <[email-masked]>
Date: Wed, 15 Oct 2008 12:52:58 -0400

>From: Stephen Farrell [mailto:[email-masked]] 
>Sent: Wednesday, October 15, 2008 12:17 PM
>To: Turner, Sean P.
>Cc: [email-masked]
>> Carl and Dave also raised a similar comment, but Russ was concerned 
>> that people that do DSA already supported inheritance. Can 
>you live with:
>> 
>inherited. 
>> This choice MAY be supported.
>
>That's clear enough for me, so long as the behaviour of a 
>non-supporting RP when faced with a cert using this is clear - 
>is it? (I can re-read the thing but you probably know already:-)
>
>S.

If I didn't know how DSA inheritance works, then I'd say they weren't
addressed in the ID.  RFC 3279 says they're inherited but leaves it to the
reader to figure out that it's like DSA.  We should adapt some text from
2.3.2 of RFC 3279 for 2.1.1 of draft-ietf-pkix-ecc-subpubkeyinfo-09 to fully
explain what we mean by "inherited":

The AlgorithmIdentifier within subjectPublicKeyInfo is the only place within
a certificate where the domain parameters may be used.  If the ECDSA, ECMQV,
or ECDH algorithm parameters are omitted from the subjectPublicKeyInfo
AlgorithmIdentifier and the CA signed the subject certificate using ECDSA,
then the certificate issuer's ECDSA parameters apply to the subject's ECDSA,
ECMQV, or ECDH key.  If the ECDSA, ECMQV, or ECDH domain parameters are
omitted from the subjectPublicKeyInfo AlgorithmIdentifier and the CA signed
the subject certificate using a signature algorithm other than ECDSA, then
the subject's ECDSA, ECMQV, and ECDH domain parameters are distributed by
other means. If the subjectPublicKeyInfo AlgorithmIdentifier field omits the
parameters component, the CA signed the subject with a signature algorithm
other than ECDSA, and the subject's ECDSA, ECMQV, and ECDH parameters are
not available through other means, then clients MUST reject the certificate.

spt

>>> And could we RECOMMEND that it not be used? I find it hard 
>to see how 
>>> a programmer can make the right choice, and easy to see that a CA 
>>> operator could make the wrong choice. And its generally a confusing 
>>> bit of text.
>>>
>>> Otherwise this seems fine as far as I can tell (which isn't far in 
>>> the case of EC related stuff:-)
>>>
>>> Stephen.
>>>
>>>
>>>
>>>
>>>
>>> Stephen Kent wrote:

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 15 Oct 2008 13:44:02 -0400

Sean,

Is it worth making the recursive nature of inheritance explicit? 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Turner, Sean P.
Sent: Wednesday, October 15, 2008 12:53 PM
To: 'Stephen Farrell'
Cc: [email-masked]
Subject: RE: WGLC for draft-ietf-pkix-ecc-subpubkeyinfo-08.txt

If I didn't know how DSA inheritance works, then I'd say they weren't
addressed in the ID.  RFC 3279 says they're inherited but leaves it to
the
reader to figure out that it's like DSA.  We should adapt some text from
2.3.2 of RFC 3279 for 2.1.1 of draft-ietf-pkix-ecc-subpubkeyinfo-09 to
fully
explain what we mean by "inherited":

The AlgorithmIdentifier within subjectPublicKeyInfo is the only place
within
a certificate where the domain parameters may be used.  If the ECDSA,
ECMQV,
or ECDH algorithm parameters are omitted from the subjectPublicKeyInfo
AlgorithmIdentifier and the CA signed the subject certificate using
ECDSA,
then the certificate issuer's ECDSA parameters apply to the subject's
ECDSA,
ECMQV, or ECDH key.  If the ECDSA, ECMQV, or ECDH domain parameters are
omitted from the subjectPublicKeyInfo AlgorithmIdentifier and the CA
signed
the subject certificate using a signature algorithm other than ECDSA,
then
the subject's ECDSA, ECMQV, and ECDH domain parameters are distributed
by
other means. If the subjectPublicKeyInfo AlgorithmIdentifier field omits
the
parameters component, the CA signed the subject with a signature
algorithm
other than ECDSA, and the subject's ECDSA, ECMQV, and ECDH parameters
are
not available through other means, then clients MUST reject the
certificate.

spt