Subject: Re: [COSE] Adding new curves for ECDSA signatures

From: DESPERRIER Jean-Marc <[email-masked]>
Date: Fri, 1 Mar 2019 17:36:33 +0000

> De : Jim Schaad <[email-masked]> 
>> From: DESPERRIER Jean-Marc <[email-masked]>
>> The other remark is the fact that only the secp***r1 curves can be 
>> used for ECDSA signature, which is a big constraint for algorithm agility.
>> I would support having an optional signed header to specify an 
>> alternative EC curve to use in replacement of the defaut secp one.
>> Or if this doesn't work, have additional signature scheme for using a 
>> different curve family.

> It should be possible for somebody to write a new document which would create the curve assignments for other curves to be created.  
> It would need to make it clear what the algorithms it can be used with are but, other than the potential buy 
> off on the curves from CFRG, this would be a trivial task.

Hi, now that the ISO/IEC JTC 1/SC 17/WG 10 group is going forward with using COSE, they are demands to add the brainpool curves as option for ECDSA signature (brainpoolP256r1, brainpoolP320r1, brainpoolP384r1, brainpoolP512r1).
So I would like to discuss more about how it can be done.

Defining new value for the COSE Elliptic Curves table wouldn't be hard.
The question is more how they can be allowed inside signature, since the ESxxx alg currently are only authorized with the respective curve P-xxx.
I agree with the Security Considerations that it doesn't seem a good idea to make substitution of different curve of the same size possible. 
Even if the risk seems rather theoretical, other signature formats don't allow it.

So either a new signature mechanism is added which is still ECDSA, but this time with brainpool, or a new signed header is defined that must be present when ESxxx isn't used with a P-xxx curve. 
Any signature with that header unsigned should be rejected as invalid.
It could directly contain the curve number from the COSE Elliptic Curves table to simplify expansions.

I find the second solution more satisfying as expanding the support to further new curves would become simpler, but if we consider that there will be only a limited number of new options beyond curve P-xxx and brainpool, the first one means less change to the current logic.

Br,
Jean-Marc Desperrier

---

From: Jim Schaad <[email-masked]>
Date: Fri, 1 Mar 2019 10:37:27 -0800

> -----Original Message-----
> Sent: Friday, March 1, 2019 9:37 AM
> To: Jim Schaad <[email-masked]>; 'cose' <[email-masked]>
> Subject: RE: Adding new curves for ECDSA signatures
> 
> >> From: DESPERRIER Jean-Marc <[email-masked]> The
> >> other remark is the fact that only the secp***r1 curves can be used
> >> for ECDSA signature, which is a big constraint for algorithm agility.
> > It should be possible for somebody to write a new document which would
> create the curve assignments for other curves to be created.
> > It would need to make it clear what the algorithms it can be used with
> > are but, other than the potential buy off on the curves from CFRG, this
> would be a trivial task.
> 
> Hi, now that the ISO/IEC JTC 1/SC 17/WG 10 group is going forward with using
> COSE, they are demands to add the brainpool curves as option for ECDSA
> signature (brainpoolP256r1, brainpoolP320r1, brainpoolP384r1,
> brainpoolP512r1).
> The question is more how they can be allowed inside signature, since the
> ESxxx alg currently are only authorized with the respective curve P-xxx.
> I agree with the Security Considerations that it doesn't seem a good idea to
> make substitution of different curve of the same size possible.

I could wish that it is true that other signature formats don't allow for a change of the curve to happen, however this is not generally a true statement.  It is true for TLS, but it is not true for CMS unless you include the attribute for the signature algorithm which is not normally done.   I haven't looked recently, but I don't believe that it would be true either for JOSE or XML DigSig as well.

Step number 1 would be to define the new values for the COSE Elliptic Curves table.  If people are not worried about the curve substitution attack then that would be the end of it.

> 
> So either a new signature mechanism is added which is still ECDSA, but this
> time with brainpool, or a new signed header is defined that must be present
> when ESxxx isn't used with a P-xxx curve.
> I find the second solution more satisfying as expanding the support to
> further new curves would become simpler, but if we consider that there will
> be only a limited number of new options beyond curve P-xxx and brainpool,
> the first one means less change to the current logic.

Alternatively, one could define the new header as only being required for non P-* curves which means that it only needs to be enforced for new curves.  

Overall I think that defining a new signature algorithms with the new algorithm parameter or adding the new algorithm parameter to the current signature algorithms would both be satisfactory approaches.

What you should do then is:

1.  Write up an ID for this.  I would suggest that the draft filename be draft- desperrier-cose-brainpool.   I would be more interested in this being an RFC if the new header parameter is defined for the current algorithms, but if it is going to be new signature algorithms then it could be done here or over in the ISO/IEC JTC 1/SC 17/WG 10.  Either way getting an ID for us to look at is useful.

2.  After the draft has been posted, ask for discussion on it.  If you think you are going to be in Prague for the F2F then I would be interested in meeting with you about it.  You could also ask for some time at the F2F COSE meeting. Depending on how long I end up running with my presentations and discussions there may or may not be time.

Jim