Subject: Removing specifiedCurve

From: "Turner, Sean P." <[email-masked]>
Date: Wed, 20 Aug 2008 18:22:55 -0400

Should we remove the specifiedCurve option from ECParameters (section
2.1.1)?  It would leave us with the namedCurve and implicitCurve choices and
a document that is roughly 10 pages shorter.

The specifiedCurve option is very complicated compared to the other choices.
Further, folks seem to be registering OIDs for their curves as opposed to
carrying all the parameters necessary to the specifiedCurve choice work.

spt

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 20 Aug 2008 17:23:56 -0700

Just to be clear, you are talking about 
draft-ietf-pkix-ecc-subpubkeyinfo-06.txt, yes?

>a document that is roughly 10 pages shorter.

There could be some people who want to specify a curve that does not 
have an OID that is known by all relying parties. However, in such a 
case, there is also an assumption that the relying party is going to 
want to trust all the parameters and then rely on the certificate.

This is certainly a case where the flexibility seems outweighed by 
the likelihood of misimplementation.

>carrying all the parameters necessary to the specifiedCurve choice work.

One doesn't need to "register" an OID for a particular curve, just 
get all relying parties to agree on what a particular OID means.

Removing specifiedCurve would definitely make the spec less 
complicated and more implementable; it seems like a good idea.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Turner, Sean P." <[email-masked]>
Date: Wed, 20 Aug 2008 22:18:22 -0400

Yes I am talking about the draft-ietf-pkix-ecc-subpubkeyinfo-06.txt.

spt

>-----Original Message-----
>From: Paul Hoffman [mailto:[email-masked]] 
>Sent: Wednesday, August 20, 2008 8:24 PM
>To: Turner, Sean P.; [email-masked]
>Subject: Re: Removing specifiedCurve
>
>>2.1.1)?  It would leave us with the namedCurve and implicitCurve 
>>choices and a document that is roughly 10 pages shorter.
>
>There could be some people who want to specify a curve that 
>does not have an OID that is known by all relying parties. 
>However, in such a case, there is also an assumption that the 
>relying party is going to want to trust all the parameters and 
>then rely on the certificate.
>
>This is certainly a case where the flexibility seems 
>outweighed by the likelihood of misimplementation.
>
>>Further, folks seem to be registering OIDs for their curves 
>as opposed 
>>to carrying all the parameters necessary to the 
>specifiedCurve choice work.
>
>One doesn't need to "register" an OID for a particular curve, 
>just get all relying parties to agree on what a particular OID means.
>

---

From: Russ Housley <[email-masked]>
Date: Thu, 21 Aug 2008 09:13:07 -0400

Back when I had time to do consulting in this area, I developed a 
certificate profile that accommodated ECC. The profile I developed 
did not include specifiedCurve.  As Sean says, it is very 
complex.  More importantly, it was not needed.  All of the curves 
with the slightest interest were easily handled by namedCurve.

I would suggest leaving the specifiedCurve definition in the ASN.1 
module.  This lets an implementation parse it correctly if it show 
up.  I also suggest adding language that specifiedCurve is beyond the 
scope by this specification and implementation is not required.  This 
way, anyone that already supports specifiedCurve continues to conform 
to the PKIX specification.

Russ

---

From: Tim Polk <[email-masked]>
Date: Thu, 21 Aug 2008 19:09:02 -0400

While the NIST specification (FIPS 186-2) permits selecting your own  
curve, I have found no customers for that feature.  Using a namedCurve
is a better choice in almost every scenario I can imagine.  Make that  
every scenario, although that could be a failure of imagination...   
Implementers
would like to face less curves (so they can optimize), not more, and  
certainly not an unbounded set.

Russ's compromise (leave it in the ASN.1, but note that it is out of  
scope) seems sensible to me.  I actually would suggest adding some  
text to the
security considerations section about the risks faced when you accept  
keys that are not associated with a well known/widely reviewed  
curve.  For
example, if my recollection of the NIST key management specs is  
correct, they expect the relying party to perform some operations to  
confirm the
validity of the parameters.  This step is not required for a well  
known curve (in this case, one of NIST's recommended curves).

Tim

On Aug 21, 2008, at 9:13 AM, Russ Housley wrote:

> did not include specifiedCurve.  As Sean says, it is very complex.   
> More importantly, it was not needed.  All of the curves with the  
> slightest interest were easily handled by namedCurve.
>
> up.  I also suggest adding language that specifiedCurve is beyond  
> the scope by this specification and implementation is not  
> required.  This way, anyone that already supports specifiedCurve  
> continues to conform to the PKIX specification.
>
> Russ
>
>> choices and

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 22 Aug 2008 17:31:58 -0700

At 9:13 AM -0400 8/21/08, Russ Housley wrote:
>the scope by this specification and implementation is not required. 
>This way, anyone that already supports specifiedCurve continues to 
>conform to the PKIX specification.

This seems particularly dangerous. Leaving in a name with no 
semantics seems begging for interoperability problems and possibly 
security problems as well.

If people want to leave this element of the CHOICE in, we should 
instead define it as an octet hole and note why we did so. That 
leaves any interpretation completely up to both sides.

--Paul Hoffman, Director
--VPN Consortium

---

From: Russ Housley <[email-masked]>
Date: Mon, 25 Aug 2008 09:27:40 -0400

>leaves any interpretation completely up to both sides.

The definition is not an octet hole.  And, if that branch in the 
choice is taken by implementation of RFC 3279, we do not want to 
cause trouble.  Rather, we want to say that use of that branch in the 
choice is deprecated going forward.

Russ

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 25 Aug 2008 08:10:09 -0700

At 9:27 AM -0400 8/25/08, Russ Housley wrote:
>The definition is not an octet hole.

Right. I am proposing that it *become* an octet hole if we leave it 
as a choice. That way, we are not specifying any semantics on the 
field; we leave them up to consenting implementers.

Our choices seem to be under-specify by giving hints, under-specify 
by saying "we're not telling you anything", or remove completely. I'm 
arguing in favor of the second.

>And, if that branch in the choice is taken by implementation of RFC 
>3279, we do not want to cause trouble.

Fully agree. I think your proposal (give hints but not a full 
specification) is more likely to cause trouble than mine (give a 
placeholder and nothing more).

>Rather, we want to say that use of that branch in the choice is 
>deprecated going forward.

How well has that worked historically in IETF specs?

--Paul Hoffman, Director
--VPN Consortium

---

From: Russ Housley <[email-masked]>
Date: Mon, 25 Aug 2008 16:02:59 -0400

Paul:

>>>>I would suggest leaving the specifiedCurve definition in the 
>>>>ASN.1 module.  This lets an implementation parse it correctly if 
>>>>it show up.  I also suggest adding language that specifiedCurve 
>>>>is beyond the scope by this specification and implementation is 
>>>>not required. This way, anyone that already supports 
>>>>specifiedCurve continues to conform to the PKIX specification.
>>>
>by saying "we're not telling you anything", or remove completely. 
>I'm arguing in favor of the second.

But, I do not believe that deviating from the syntax already in use 
from ANSI X9 is the right answer.

>placeholder and nothing more).

But, your proposal breaks compatibility with the ANSI X9 
specification, which would force the assignment of a different 
OID.  I belive that would even more trouble.

>How well has that worked historically in IETF specs?

In the progression from Proposed Standard toward higher maturity 
levels, we are supposed to drop unimplemented options.  That's how I 
see this.  We need to tell people to use the branches in the choice 
that are finding use.

Russ

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 25 Aug 2008 15:11:26 -0700

At 4:02 PM -0400 8/25/08, Russ Housley wrote:
>>>>semantics seems begging for interoperability problems and 
>>>>possibly security problems as well.
>>>>

My apologies. There was nothing in the Internet Draft that said that 
this field already had syntax defined by ANSI X9 (although the last 
sentence in 2.1.1.2 vaguely hints at it). Had I known that, I would 
have supported a different proposal: replace all of section 2.1.1.2 
and all of its subsections with two sentences: "The specifiedCurve 
field in ECParameters is of SpecifiedCurve type defined by ANSI X9 
[REF]. Its use is optional and is expected to be deprecated in future 
versions of this document."

Does that work for you?

--Paul Hoffman, Director
--VPN Consortium

---

From: Stephen Kent <[email-masked]>
Date: Mon, 25 Aug 2008 17:55:55 -0400

I think I agree with Russ's suggestion here. If we leave the ASN.1 
for curve specification in the spec, it will likely cause some set if 
implementers to try to implement it, adding to code bloat, untested 
code branches, etc. If we remove it that sends a clear message, i.e., 
we are deprecating this option and we REALLY don't want folks to 
support it. This won't prevent folks from using this option if they 
really want to, since the ASN.1 already exists, even if we redact it 
from our spec. But, I prefer this to including the ASN.1 and saying 
that we deprecate it, as that sends a mixed message.

Steve

---

From: Russ Housley <[email-masked]>
Date: Mon, 25 Aug 2008 19:28:15 -0400

Paul:

>>>>>>ASN.1 module.  This lets an implementation parse it correctly 
>>>>>>if it show up.  I also suggest adding language that 
>>>>>>specifiedCurve is beyond the scope by this specification and 
>>>>>>implementation is not required. This way, anyone that already 
>>>>>>supports specifiedCurve continues to conform to the PKIX specification.
>>>>>
>>>Right. I am proposing that it *become* an octet hole if we leave 
>>>it as a choice. That way, we are not specifying any semantics on 
>>>the field; we leave them up to consenting implementers.
>>>
>>>Our choices seem to be under-specify by giving hints, 
>>>under-specify by saying "we're not telling you anything", or 
>>>remove completely. I'm arguing in favor of the second.
>>
>[REF]. Its use is optional and is expected to be deprecated in 
>future versions of this document."
>
>Does that work for you?

I could certainly live with that.

Russ

---

From: "Turner, Sean P." <[email-masked]>
Date: Tue, 26 Aug 2008 11:01:36 -0400

Paul: 

>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Paul Hoffman
>Sent: Monday, August 25, 2008 6:11 PM
>To: Russ Housley; Turner, Sean P.; [email-masked]
>>>>>>ASN.1 module.  This lets an implementation parse it 
>correctly if it 
>>>>>>show up.  I also suggest adding language that specifiedCurve is 
>>>>>>beyond the scope by this specification and implementation is not 
>>>Right. I am proposing that it *become* an octet hole if we 
>leave it as 
>>>a choice. That way, we are not specifying any semantics on 
>the field; 
>>>we leave them up to consenting implementers.
>>>
>under-specify by 
>>>saying "we're not telling you anything", or remove completely.
>My apologies. There was nothing in the Internet Draft that 
>said that this field already had syntax defined by ANSI X9 
>(although the last sentence in 2.1.1.2 vaguely hints at it). 
>Had I known that, I would have supported a different proposal: 
>replace all of section 2.1.1.2 and all of its subsections with 
>two sentences: "The specifiedCurve field in ECParameters is of 
>SpecifiedCurve type defined by ANSI X9 [REF]. Its use is 
>optional and is expected to be deprecated in future versions 
>of this document."
>
>Does that work for you?
>
In the proposed text shouldn't it be "Its use is optional and it is
deprecated in this document"?  We want to deprecate it in this document not
in future ones.

If we're going to remove the choice from the ASN.1 we need to remove it from
the ECParameters structure.  With that in mind I think the text really ought
to go in 2.1.1 and we can just completely delete 2.1.1.2.  Along the same
lines as you suggested we'd delete the specifiedCurve bullet and replace it
with this paragraph:

ANSI X9 [X9.62] has defined the specifiedCurve as an additional choice for
ECParameters and it is of SpecifiedCurve type. Its use is optional and it is
deprecated in this document.

Also we'd comment out the specifiedCurve choice like so:

ECParameters ::= CHOICE {
  namedCurve      CURVE.&id({NamedCurve}),
  implicitCurve   NULL
  -- specifiedCurve  SpecifiedCurve,
  --is not supported by this specification
  -- Details for namedCurve can be found in [X9.62]
}

spt

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 26 Aug 2008 08:22:25 -0700

>deprecated in this document"?  We want to deprecate it in this document not

That works for me as well. The WG can decide which rev of the 
document it wants to deprecate in.

>   -- Details for namedCurve can be found in [X9.62]

That makes good sense if we are going to deprecate it now.

--Paul Hoffman, Director
--VPN Consortium

---

From: Michael StJohns <[email-masked]>
Date: Tue, 26 Aug 2008 12:11:48 -0400

Sorry for dropping in at the last moment, but I'm wondering if this is a viable approach due to the current definition.  I agree that deprecating this is the right idea, but I'm not sure that wiping the definition out of the ASN1 is the right way of doing it.

The problem is that none of the alternatives for CHOICE were defined with explicit tagging - which means parsing is dependent on the underlying object.  The current definition CHOICE has a match against OBJECT IDENTIFIER, NULL and SEQUENCE (specifiedCurve).  I would be worried that at some future time someone might specify as a choice an AlgorithmIdentifier  (e.g. - pointing to a known base curve, but a different base point for example) which also encodes as a SEQUENCE without realizing that the old definition which included specifiedCurve conflicts.  If the old definition is not carried forward either as it is or as a prohibition for future definitions its remotely possible that some stupidity could happen.

The AlgorithmIdentifier is just a contrived example, but one that's not totally far fetched.  I'd like to (weakly) suggest either leaving in specifiedCurve with a simple definition of SEQUENCE and commentary saying that it's both deprecated in this spec and that X9.62 has a definition, OR indicating that additional choices defined later MUST be explicitly tagged.  Or a third alternative?

Or just say I'm worrying way too much and move on... :-)

Mike

At 11:22 AM 8/26/2008, Paul Hoffman wrote:

>That works for me as well. The WG can decide which rev of the document it wants to deprecate in.
>

---

From: Daniel Brown <[email-masked]>
Date: Tue, 26 Aug 2008 12:19:45 -0400

Sean,

Does commenting out the third choice as you suggested, i.e.

affect the PER encoding, since it now uses a single bit to indicate the choice instead of two bits?  If so, does that matter to PKIX?

Also, I think that the third comment should not mention namedCurve, but instead say:

   -- Details for specifiedCurve can be found in [X9.62]

Best regards,

        Dan

---

From: Daniel Brown <[email-masked]>
Date: Tue, 26 Aug 2008 12:43:01 -0400

Sean:

In theory, wouldn't it work to IMPORT SpecifiedCurve from the X9.62-2005 module (without repeating its definitions), but then say the specifiedCurve SHOULD NOT or MUST NOT be used?  That should deter PKIX users from using this choice, while preserving the ASN.1 defintion across standards.

E.g.

IMPORTS SpecifiedCurve FROM ANSI-X9-62 { iso(1) member-body(2) us(840) 10045 module(0) 2}

ECParameters ::= CHOICE {
  namedCurve      CURVE.&id({NamedCurve}),
  implicitCurve   NULL,
  specifiedCurve  SpecifiedCurve, -- SHOULD NOT be used (in PKIX)
  -- SpecifiedCurve is defined in [X9.62]
}

Best regards,

        Dan

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 26 Aug 2008 10:47:45 -0700

At 12:43 PM -0400 8/26/08, Daniel Brown wrote:
>In theory, wouldn't it work to IMPORT SpecifiedCurve from the 
>X9.62-2005 module (without repeating its definitions), but then say 
>the specifiedCurve SHOULD NOT or MUST NOT be used?

Only in theory. In practice, you can either really import, or really deprecate.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 26 Aug 2008 10:43:05 -0700

At 12:19 PM -0400 8/26/08, Daniel Brown wrote:
>affect the PER encoding, since it now uses a single bit to indicate 
>the choice instead of two bits?

Yes.

>If so, does that matter to PKIX?

No. PKIX is defined for DER, not everyER.

>    -- Details for specifiedCurve can be found in [X9.62]

Good catch.

--Paul Hoffman, Director
--VPN Consortium

---

From: Russ Housley <[email-masked]>
Date: Tue, 26 Aug 2008 13:11:44 -0400

Dan:

>the choice instead of two bits?  If so, does that matter to PKIX?

PKIX makes use of these structures are only used in 
certificates.  DER must be used to validate the signature on the 
certificate, so I do not see how this is an issue.

Russ

---

From: Russ Housley <[email-masked]>
Date: Tue, 26 Aug 2008 13:22:56 -0400

Dan:

I'd rather see it commented out.  Otherwise, an implementor needs to 
chase the reference just to get the ASN.1 module to compile.

Russ

At 12:43 PM 8/26/2008, Daniel Brown wrote:
>the specifiedCurve SHOULD NOT or MUST NOT be used?  That should 
>deter PKIX users from using this choice, while preserving the ASN.1 
>defintion across standards.
>
>E.g.
>

---

From: Daniel Brown <[email-masked]>
Date: Tue, 26 Aug 2008 14:58:06 -0400

Russ,

Yes, 3280 is clear that DER must be used for verifying the signature of a cert.

However, 3280 does not prescribe DER for transmission of a certificate, does it?  If not, Alice could get Bob's cert PER-encoded from somewhere, then convert to DER for the purposes of signature verification.

Best regards,

        Dan

> From: Russ Housley [mailto:[email-masked]]
> Sent: Tuesday, August 26, 2008 1:12 PM
> To: Daniel Brown; [email-masked]
> Subject: RE: Removing specifiedCurve
>
> Dan:
>

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 26 Aug 2008 15:12:15 -0400

Sean,

I think that I would prefer to do the following:

1.  Specify it is MUST NOT used  -- I hesitate to say depreciate if you
think there is a chance it will un-deprecate later (SHOULD NOT?).

2.  Create a second module with the specifiedCurve ASN.1 and import from
there.  That keeps the ASN.1 around for those who want it, but makes it
clear that this is in an unsupported section of the ASN.1

Jim

> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Daniel Brown
> Sent: Tuesday, August 26, 2008 12:43 PM
> To: Turner, Sean P.; 'Paul Hoffman'; 'Russ Housley'; [email-masked]
> In theory, wouldn't it work to IMPORT SpecifiedCurve from the X9.62-
> 2005 module (without repeating its definitions), but then say the
> specifiedCurve SHOULD NOT or MUST NOT be used?  That should deter PKIX
> users from using this choice, while preserving the ASN.1 defintion
> across standards.
> 
> E.g.
> 
> > ANSI X9 [X9.62] has defined the specifiedCurve as an additional
> choice
> > for
> > ECParameters and it is of SpecifiedCurve type. Its use is optional
> and
> > it is

---

From: Russ Housley <[email-masked]>
Date: Tue, 26 Aug 2008 15:36:11 -0400

Dan:

>However, 3280 does not prescribe DER for transmission of a 
>certificate, does it?  If not, Alice could get Bob's cert 
>PER-encoded from somewhere, then convert to DER for the purposes of 
>signature verification.

All correct.  Given this information, I support Jim's suggested way forward.

Russ

---

From: "Kemp, David P." <[email-masked]>
Date: Tue, 26 Aug 2008 16:45:45 -0400

If specifiedCurve is to be deprecated, then PKIX-compliant certificate
generators MUST NOT create certificates using the specifiedCurve option.
SHOULD NOT is not strong enough, because that would lead to
interoperability problems.

However, it sends the wrong message to say that a generating or
consuming application compliant with X9.62 is by definition
non-compliant with PKIX.  Therefore PKIX should say that generating or
consuming applications MAY use the X9.62 ASN.1 module.  The PKIX ASN.1
module must neither include nor IMPORT the definition of specifiedCurve
because both cause extra code to be compiled and generated.

Michael StJohns makes an excellent point about extensibility of the
CHOICE, but I don't see how it can be addressed using ASN.1 syntax.  Any
attempt to include a dummy SEQUENCE would result in bits on the wire
incompatible with X9.62 if that choice were exercised.  Just leave it as
a comment:

ECParameters ::= CHOICE {
   namedCurve      CURVE.&id({NamedCurve}),
   implicitCurve   NULL,
-- specifiedCurve  SpecifiedCurve
}
-- SpecifiedCurve is defined in [X9.62] as a SEQUENCE
-- PKIX-conforming certificates MUST NOT be populated using
specifiedCurve

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Paul Hoffman
Sent: Tuesday, August 26, 2008 1:48 PM
To: [email-masked]
Subject: RE: Removing specifiedCurve

>the specifiedCurve SHOULD NOT or MUST NOT be used?

Only in theory. In practice, you can either really import, or really
deprecate.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Kemp, David P." <[email-masked]>
Date: Tue, 26 Aug 2008 17:16:39 -0400

Jim's way will not work.  If the CHOICE includes the specifiedCurve
option, the code for SpecifiedCurve will be compiled regardless of
whether the definition is included in the original PKIX module, a second
PKIX module, or the X9.62 module.

The specifiedCurve option must be commented out, in which case there is
no need to IMPORT the definition of SpecifiedCurve.  PKIX can still
create an orphan, unreferenced module so that when ecc-subpubkeyinfo is
published as an RFC the definition will remain publicly available.

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Russ Housley
Sent: Tuesday, August 26, 2008 3:36 PM
To: Daniel Brown; [email-masked]
Subject: RE: Removing specifiedCurve

>PER-encoded from somewhere, then convert to DER for the purposes of 

All correct.  Given this information, I support Jim's suggested way
forward.

Russ

---

From: Michael StJohns <[email-masked]>
Date: Tue, 26 Aug 2008 17:16:14 -0400

At 04:45 PM 8/26/2008, Kemp, David P. wrote:
>Any
>incompatible with X9.62 if that choice were exercised. 

Hi David - 

The idea about the dummy SEQUENCE was simply to have a place holder in the definition so that anyone who came along later would know not to reuse it (or at least to wrap any new SEQUENCE encoded CHOICE in a tag).  The definition would still point to X9.62 for the construction of the SEQUENCE - but keeping the low level stuff out of the local definition should keep "rogue" implementors from implementing specifiedCurve unless they hunted down a copy of X9.62.

I don't really have any strong feelings here, but I'm generally of a mind that if you're going to kill something, the least you can do is put up a tombstone over the body so no one digs there by mistake.  

Later, Mike

---

From: Daniel Brown <[email-masked]>
Date: Wed, 27 Aug 2008 11:25:45 -0400

Jim,

I agree with your suggestion.

Albeit, as already noted, if one uses an ASN.1 compiler on the main module, then one must also compile the second module.   Obviously, this does not force somebody to implement the crypto behind specifiedCurve.

If PKIX is certain to go with MUST NOT (i.e. not MAY or SHOULD NOT), then there may be ASN.1 mechanism to enforce this:

ECParameters ::= CHOICE {
   namedCurve      CURVE.&id({NamedCurve}),
   implicitCurve   NULL,
   specifiedCurve  SpecifiedCurve, -- MUST NOT be used in PKIX
   -- SpecifiedCurve is defined in [X9.62]
} (WITH COMPONENTS {specifiedCurve ABSENT})

In theory, an ASN.1 compiler should be able to compile this without needing SpecifiedCurve defined or imported.  If so, a second module would not even be needed.

If my understanding is correct, then the "WITH COMPONENTS" constraint is non-PER-visible, so my concern about incompatible PER encodings would then be remedied.

Best regards,

        Dan

> From: Jim Schaad [mailto:[email-masked]]
> Sent: Tuesday, August 26, 2008 3:12 PM
> To: Daniel Brown; 'Turner, Sean P.'; 'Paul Hoffman'; 'Russ Housley';
> [email-masked]
> > IMPORTS SpecifiedCurve FROM ANSI-X9-62 { iso(1) member-body(2)
> us(840)
> > 10045 module(0) 2}
> >

---

From: Steven Legg <[email-masked]>
Date: Thu, 28 Aug 2008 10:39:01 +1000

Daniel,

> In theory, an ASN.1 compiler should be able to compile this without needing SpecifiedCurve defined or imported.  If so, a second module would not even be needed.

X.680 requires a typereference to be defined locally or imported - without exceptions!
I would expect a conformant ASN.1 compiler to complain about SpecifiedCurve being
undefined. It would have to be fairly sophisticated to work out that this is a
non-critical error.

Incidentally, the PER encoding of SpecifiedCurve is not backward-compatible with
RFC 3279 because it is defined to be extensible. Extending any of the types in
RFC 3279, or even marking them as extensible, will break backward-compatibility
for PER so it is perhaps not worth worrying about. Renaming the fields has already
broken backward-compatibility for GSER and XER, so PER wouldn't be the exception.

Regards,
Steven

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Thu, 28 Aug 2008 15:54:03 +0200

Kemp, David P. wrote:
> [...] Any

I'm not convinced by that line of reasonning.

I hope I write something that makes sense, but something in the line
of :

ECParameters ::= CHOICE {
    namedCurve      CURVE.&id({NamedCurve}),
    implicitCurve   NULL,
    specifiedCurve  SpecifiedCurve -- do not use, deprecated in PKIX
}

-- If you really need to use SpecifiedCurve, remove the
-- declaration below, and import it from X9-62 with :
-- IMPORTS SpecifiedCurve FROM ANSI-X9-62 { iso(1) member-body(2)
--  us(840) 10045 module(0) 2}
SpecifiedCurve ::= SEQUENCE {
    version  INTEGER
    ...,
    ...
}

would see extremly low risks of someone trying to exercise the choice 
under that form, and would let all implementations accept SpecifiedCurve 
even it will not use it.

PS : I don't know if removing "version  INTEGER" would be allowed 
syntaxically. If yes, maybe it's better.

---

From: Daniel Brown <[email-masked]>
Date: Thu, 28 Aug 2008 10:48:34 -0400

Steven,

> From: Steven Legg [mailto:[email-masked]]
> Sent: Wednesday, August 27, 2008 8:39 PM
> To: Daniel Brown
> Cc: Jim Schaad; 'Turner, Sean P.'; 'Paul Hoffman'; 'Russ Housley';
> [email-masked]
> > If PKIX is certain to go with MUST NOT (i.e. not MAY or SHOULD NOT),
> then there may be ASN.1 mechanism to enforce this:
> >
> > In theory, an ASN.1 compiler should be able to compile this without
> needing SpecifiedCurve defined or imported.  If so, a second module
> would not even be needed.
>

Ok, fair enough.

> undefined. It would have to be fairly sophisticated to work out that

Well, if a compiler recognizes WITH COMPONENTS, it should require that the type
SpecifiedCurve is never used.  Then it seems just a small step to relax about its
being defined.

Regardless, I guess this means one has to throw in the second module, in theory
because of X.680 rules, in practice because of ASN.1 compilers.

> for PER

Oops, you're probably right, so I'll check this carefully.  It would be my fault, because
I updated the SpecifiedCurve type in ANSI X9.62-2005.  At the time, I knew little about PER,
so thought that the already existing version component (ecdpVer) would suffice
for making syntax updates backward-compatible.

But, even if SpecifiedCurve is PER-broken, we don't need to PER-break the rest of
ECParameters, i.e. namedCurve and implicitCurve too.

In summary, if PKIX wants to rate SpecifiedCurve as MAY or SHOULD NOT, then I think
Jim's second module approach is still the best way to go.  If PKIX wants SpecifiedCurve as
a MUST NOT, then I think Jim's second module approach plus the WITH COMPONENTS syntax
is the best way to go.   It enforces the MUST NOT at the ASN.1 level, which can be done
more automatically by an ASN.1 compiler, and it is also nicer for making PER backward
-compatible ECParameters, at least for the two options that PKIX wants to use.

> so it is perhaps not worth worrying about. Renaming the fields
> has already

Is XER also standardized in ISO/ITU?  I hadn't realized that XER actually using
the ASN.1 field names, otherwise I would have been more careful.  I never heard
of GSER before.

Best regards,

        Dan

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 28 Aug 2008 09:58:50 -0700

I would ask again: if this is already defined by X9, and we don't 
really want people to implement it but we want them to interoperate 
if they do, why should we define the sytax or the semantics at all in 
our document? Can't we just say "this is optional, but if you want to 
do it, do it as described by X9"?

--Paul Hoffman, Director
--VPN Consortium

---

From: "Kemp, David P." <[email-masked]>
Date: Thu, 28 Aug 2008 13:36:00 -0400

Jean-Marc,

If your PKIX specifiedCurve syntax were ever exercised to generate a
certificate, that certificate would contain a SEQUENCE followed by an
INTEGER and nothing else.  This certificate would be rejected by an
X9.62 parser because nothing following version (fieldID, curve, base,
etc) is OPTIONAL in X9.62.  An extensible syntax only works if every
extended element can be omitted.

This really seems like an angels-on-pinheads kind of discussion now,
since the only reason for attempting to put a SEQUENCE in the ASN.1
without dragging in extra baggage is to prevent some future hypothetical
body that does NOT have the X9.62 definition from defining a new field
that is also a non-tagged SEQUENCE.  In my opinion, a comment is a
sufficient message to send to that hypothetical body.

Dave

BTW, does anyone else have the problem of downloading
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ecc-subpubkeyinfo-06
.txt
and having it show up as a .zip file, or is my firewall just playing
games with me?  Saving it as .zip and then renaming it to .txt works.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Jean-Marc Desperrier
Sent: Thursday, August 28, 2008 9:54 AM
To: pkix
Subject: Re: Removing specifiedCurve

even it will not use it.

---

From: Steven Legg <[email-masked]>
Date: Fri, 29 Aug 2008 09:31:20 +1000

Dan,

Daniel Brown wrote:
[snip]
> Is XER also standardized in ISO/ITU?

Yes, it's X.693.

> I hadn't realized that XER actually using
> the ASN.1 field names,

XER is also sensitive to some type names.

 > otherwise I would have been more careful.  I never heard
> of GSER before.

GSER is defined in RFC 3641. It's used for the LDAP representation of PKI matching
rule assertion syntaxes, among other things.

Come to think of it, LDAP component matching (RFC 3687) on certificates will also
be affected by changes to the field names.

Regards,
Steven