Subject: I-D ACTION:draft-ietf-pkix-ecc-subpubkeyinfo-08.txt

From: [email-masked]
Date: Mon, 22 Sep 2008 16:15:01 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: Elliptic Curve Cryptography Subject Public Key Information
	Author(s)	: S. Turner, K. Yiu, D. Brown, R. Housley, W. Polk
	Filename	: draft-ietf-pkix-ecc-subpubkeyinfo-08.txt
	Pages		: 35
	Date		: 2008-9-22
	
This document specifies the syntax and semantics for the Subject 
   Public Key Information field in certificates that support Elliptic 
   Curve Cryptography.  This document updates Sections 2.3.5, 3, and 5 
   of RFC 3279.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ecc-subpubkeyinfo-08.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 23 Sep 2008 11:30:22 -0400

What consideration was given for the ability to specify different
Generator Point for named curves (such as P-256) in order to provide
cryptographic separation for communities of interest?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of [email-masked]
Sent: Monday, September 22, 2008 7:15 PM
To: [email-masked]
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-ecc-subpubkeyinfo-08.txt 

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Public-Key Infrastructure (X.509)
Working Group of the IETF.

	Title		: Elliptic Curve Cryptography Subject Public Key
Information
	Author(s)	: S. Turner, K. Yiu, D. Brown, R. Housley, W.
Polk
	Filename	: draft-ietf-pkix-ecc-subpubkeyinfo-08.txt
	Pages		: 35
	Date		: 2008-9-22

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ecc-subpubkeyinfo-08
.txt

---

From: Russ Housley <[email-masked]>
Date: Tue, 23 Sep 2008 14:17:25 -0400

First, secp256r1and secp384r1are also known as P-256 and P-384, 
respectively.  I guess this could be highlighted.

Second, during the discussion on this list it was suggested that a 
very reasonable way to handle such a situation was to name the new 
curve.  That is, assign an OID.

Russ

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 23 Sep 2008 11:29:12 -0700

>cryptographic separation for communities of interest?

There are much more secure ways to gain cryptographic separation for 
communities of interest than to put parseable parameters in 
certificates. For example, using specified-curve OIDs from a private 
registry is much more effective because a validator cannot determine 
the curve parameters and use them when validating the certificate.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 23 Sep 2008 14:37:36 -0400

Russ,

Thanks.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Russ Housley
Sent: Tuesday, September 23, 2008 2:17 PM
To: Santosh Chokhani; [email-masked]
Subject: RE: I-D ACTION:draft-ietf-pkix-ecc-subpubkeyinfo-08.txt 

Russ

---

From: "Turner, Sean P." <[email-masked]>
Date: Tue, 23 Sep 2008 15:06:16 -0400

The document contains the following note:

  -- Note that [FIPS186-3] refers to secp192r1 as P-192, secp224r1 as
  -- P-224, secp384r1 as P-384, and secp521r1 as P-521. 

P-256 is missing so I'll add it.

spt

>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Russ Housley
>First, secp256r1and secp384r1are also known as P-256 and 
>P-384, respectively.  I guess this could be highlighted.
>
>Second, during the discussion on this list it was suggested 
>that a very reasonable way to handle such a situation was to 
>name the new curve.  That is, assign an OID.
>
>Russ
>
>
>>http://www.ietf.org/internet-drafts/draft-ietf-pkix-ecc-subpub
>keyinfo-0
>>8
>>.txt
>>

---

From: Michael StJohns <[email-masked]>
Date: Tue, 23 Sep 2008 17:11:37 -0400

Hi Paul 

It may actually make sense to do this for one specific reason:  Most of the standard curves are "chosen" in a manner to make them efficient to implement.  As near as I can tell from the reading I've been doing lately, you can change the base point without losing this property. And the code delta for doing a namedCurve vs a namedCurveWithG is simply a matter of where you pull G from (the algorithmIdentifier or the internal definition) and is the same for all curves which use the same base curve parameters (e.g. everything constant except G).

I've been trying to re-find the discussion about why you might want to do multiple Gs for a curve - I read it a few months back, but trying to sieve it out of google again is failing.

One possible encoding for the algorithm parameters (new CHOICE)

namedCurveWithG ::= SEQUENCE {
        OBJECT IDENTIFIER curve,
        Point g  OPTIONAL }

Point ::= SEQUENCE {
        INTEGER x,
        INTEGER y }

for example.  If g is omitted, its taken from the published definition for the curve.

And by the way - I *didn't* hear you suggest "security through obscurity" did I???? :-) 

Mike

At 02:29 PM 9/23/2008, Paul Hoffman wrote:

>There are much more secure ways to gain cryptographic separation for communities of interest than to put parseable parameters in certificates. For example, using specified-curve OIDs from a private registry is much more effective because a validator cannot determine the curve parameters and use them when validating the certificate.
>
>
>--Paul Hoffman, Director
>--VPN Consortium