Subject: [6lo] SEC-DIR review of AP-ND:

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 3 Feb 2020 13:29:06 +0000

Dear all

During SEC-DIR review, Benjamin pointed out:

> Why do we need to allow ambiguity/flexibility as to the point representation

> within a given Crypto-Type value (as opposed to fixing the representation as a

> parameter of the Crypto-Type)?  Alternately, what does "(un)compressed"

> mean, as it's not really clarified directly?  Furthermore, Table 2 lists an

> "(un)compressed" representation for type 0 (over P-256), but RFC 7518 notes

> that the compressed representation is not supported for P-256 (Section

> 6.2.1.1).  I also am not finding the needed codepoints registered in the JOSE

> registries to use ECDSA25519 (crypto-type 2) -- do we need to register

> anything there?

Any idea how we can address this?
In particular does anyone know why RFC 7518 does not support the compressed representation for P-256? Cc'ing LAKE on the impact of this

Pascal

---

From: Jim Schaad <[email-masked]>
Date: Mon, 3 Feb 2020 09:50:07 -0800

>From a quick run through the JOSE mailing list to refresh my memory:

1.	There is a view that on only one way should exist to do things.
Thus only either compressed or uncompressed
2.	There are still issues (at the time) about having compressed points
and patents

jim

From: Lake <[email-masked]> On Behalf Of Pascal Thubert (pthubert)
Sent: Monday, February 3, 2020 5:29 AM
To: [email-masked]
Cc: [email-masked]; Shwetha Bhandari (shwethab) <[email-masked]>;
The IESG <[email-masked]>; [email-masked]; [email-masked]; Benjamin Kaduk
<[email-masked]>
Subject: [Lake] SEC-DIR review of AP-ND:

Dear all

 

In particular does anyone know why RFC 7518 does not support the compressed
representation for P-256? Cc'ing LAKE on the impact of this

Pascal

---

From: Jim Schaad <[email-masked]>
Date: Mon, 3 Feb 2020 10:16:04 -0800

What is following is personal opinion (although I will admit to being one of
the DEs on these registries):

1.	I don't think that you are going to be able to start doing
compressed points easily in JOSE.   It is a design philosophy that people
really wanted at the time.  There was extensive discussions about getting
compressed points as well as how to expressed the point format.
2.	In my opinion, table 2 should not be referencing the Curve25519 in
the last column.  From my point of view when curves are expressed as using
different coordinate systems then you need to be expressing these as
different curves.  An algorithm negotiation currently only needs to include
the curve and not additionally include the point format.  This needs to be
maintained.  I therefore believe that a new curve code point should be
registered here.  That is the only registration that I believe needs to be
done in the JOSE registries.

Note, I find section 7.5 to be missing a small piece of guidance that might
be needed.  If you use the "same" private key for both the Edwards and
Weierstrass curve representations, is that a problem according to this
guidance?

Jim

Dear all

 

 

Pascal

---

From: Rene Struik <[email-masked]>
Date: Mon, 3 Feb 2020 15:46:56 -0500

Hi Jim:

Just weighing-in on this: see below.

Best regards, Rene

On 2/3/2020 1:16 PM, Jim Schaad wrote:
>
> What is following is personal opinion (although I will admit to being 
> one of the DEs on these registries):
>
>  1. I don’t think that you are going to be able to start doing
>     compressed points easily in JOSE.   It is a design philosophy that
>     people really wanted at the time.  There was extensive discussions
>     about getting compressed points as well as how to expressed the
>     point format.
>
RS>> I would be curious what this design philosophy was: if there is a 
record of this, that would be great. It would be particularly 
interesting to understand the reasoning as to why for Montgomery curves 
and twisted Edwards curves compression is a must, while for short 
Weierstrass curves this is forbidden... This is not just so with JOSE, 
it is also in RFC 8152 (OKP vs. EC2 distinction). It seems to be pretty 
random. <<RS
>
>  1. In my opinion, table 2 should not be referencing the Curve25519 in
>     the last column.  From my point of view when curves are expressed
>     as using different coordinate systems then you need to be
>     expressing these as different curves.  An algorithm negotiation
>     currently only needs to include the curve and not additionally
>     include the point format.  This needs to be maintained.  I
>     therefore believe that a new curve code point should be registered
>     here.  That is the only registration that I believe needs to be
RS>> Please note that the different crypto types in Table 2 refer to 
complete specifications of signature schemes, including point 
representation, bit/byte ordering, etc. Please note that curves 
expressed in different coordinate systems are not really different: only 
their representations are (unfortunately, this confusion is caused by 
heavy marketing by some people in the past). The different 
representations, not just of curve points, but also LSB/MSB and lsb/msb 
ordering conventions, are already captured in Table 2.  Since different 
bit/byte ordering, even with the same curve, makes a difference, 
representation conventions are the guiding metric, not just different 
curve models. <<RS

> 1.
>
> Note, I find section 7.5 to be missing a small piece of guidance that 
> might be needed.  If you use the “same” private key for both the 
> Edwards and Weierstrass curve representations, is that a problem 
> according to this guidance?
>
RS>> Reuse of the same public-private key pair with different signature 
schemes is not allowed.  <<RS

> Jim
>
> *From:* Lake <[email-masked]> *On Behalf Of *Pascal Thubert 
> (pthubert)
> *Sent:* Monday, February 3, 2020 5:29 AM
> *To:* [email-masked]
> *Cc:* [email-masked]; Shwetha Bhandari (shwethab) 
> <[email-masked]>; The IESG <[email-masked]>; [email-masked]; 
> [email-masked]; Benjamin Kaduk <[email-masked]>
> *Subject:* [Lake] SEC-DIR review of AP-ND:
>
> Dear all
>
> In particular does anyone know why RFC 7518 does not support the 
> compressed representation for P-256? Cc’ing LAKE on the impact of this
>
> Pascal
>

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 287-3867

---

From: Rene Struik <[email-masked]>
Date: Mon, 3 Feb 2020 16:05:22 -0500

The second part of the sentence below (see ....) did not make it to my 
earlier email. My apologies.

RS>> Reuse of the same public-private key pair with different signature 
schemes is not allowed.  See also Security Considerations, Section 7.5. <<RS

On 2/3/2020 3:46 PM, Rene Struik wrote:
>>     compressed points easily in JOSE.   It is a design philosophy
>>     that people really wanted at the time.  There was extensive
>>     discussions about getting compressed points as well as how to
>>     expressed the point format.
>>
> interesting to understand the reasoning as to why for Montgomery 
> curves and twisted Edwards curves compression is a must, while for 
> short Weierstrass curves this is forbidden... This is not just so with 
> JOSE, it is also in RFC 8152 (OKP vs. EC2 distinction). It seems to be 
> pretty random. <<RS
>>
>>  1. In my opinion, table 2 should not be referencing the Curve25519
>>     in the last column.  From my point of view when curves are
>>     expressed as using different coordinate systems then you need to
>>     be expressing these as different curves.  An algorithm
>>     negotiation currently only needs to include the curve and not
>>     additionally include the point format.  This needs to be
>>     maintained.  I therefore believe that a new curve code point
>>     should be registered here.  That is the only registration that I
>>     believe needs to be done in the JOSE registries.
>>
> expressed in different coordinate systems are not really different: 
> only their representations are (unfortunately, this confusion is 
> caused by heavy marketing by some people in the past). The different 
> representations, not just of curve points, but also LSB/MSB and 
> lsb/msb ordering conventions, are already captured in Table 2.  Since 
> different bit/byte ordering, even with the same curve, makes a 
> difference, representation conventions are the guiding metric, not 
> just different curve models. <<RS
>
>> 1.
>>
>>
> RS>> Reuse of the same public-private key pair with different 
> signature schemes is not allowed.  See also Security Considerations, 
> Section 7.5. <<RS
>
>> Jim
>>
> email:[email-masked]  | Skype: rstruik

---

From: Jim Schaad <[email-masked]>
Date: Mon, 3 Feb 2020 14:49:01 -0800

From: Rene Struik <[email-masked]> 
Sent: Monday, February 3, 2020 12:47 PM
To: Jim Schaad <[email-masked]>; 'Pascal Thubert (pthubert)'
<[email-masked]>; [email-masked]
Cc: [email-masked]; 'Shwetha Bhandari (shwethab)' <[email-masked]>;
'The IESG' <[email-masked]>; [email-masked]; 'Benjamin Kaduk' <[email-masked]>
Subject: Re: [Lake] SEC-DIR review of AP-ND:

Hi Jim:

Best regards, Rene

RS>> I would be curious what this design philosophy was: if there is a
record of this, that would be great. It would be particularly interesting to
understand the reasoning as to why for Montgomery curves and twisted Edwards
curves compression is a must, while for short Weierstrass curves this is
forbidden... This is not just so with JOSE, it is also in RFC 8152 (OKP vs.
EC2 distinction). It seems to be pretty random. <<RS

[JLS]  I would suggest going and reading through JOSE mailing list for how
things were setup for there.  I think that you and I have a different view
of how the curves are setup for the difference between OKP and EC2.  For the
EC2 curves, there are both an X and a Y point publicly provided to the user.
For the Edwards curve, only the X portion of the point is provided publicly
to the user.  This means that there would be a large discussion of what
should be done with the Y coordinate.  Being able to validate that the
correct set of fields are present without having to understand all of the
fields is considered to be desirable, at least by me, so reflecting that
difference between the two key formats is logical.   I don't see it as being
random at all.  I can see some future three coordinate version of a
hyperspace that might come in the future that would get some type of 3 point
public key and that would again require a new key format to be defined.
(Note that I have no reason to expect it, just that I can imagine it.)

RS>> Please note that the different crypto types in Table 2 refer to
complete specifications of signature schemes, including point
representation, bit/byte ordering, etc. Please note that curves expressed in
different coordinate systems are not really different: only their
representations are (unfortunately, this confusion is caused by heavy
marketing by some people in the past). The different representations, not
just of curve points, but also LSB/MSB and lsb/msb ordering conventions, are
already captured in Table 2.  Since different bit/byte ordering, even with
the same curve, makes a difference, representation conventions are the
guiding metric, not just different curve models. <<RS

[JLS]  If you do not plan to use either JOSE or COSE key formats, then you
are free to do what you will.  If you want to use those key formats then I
am afraid that you are going to need to deal with the perceptions of the
people who currently hold the review world there.

3.	 

[JLS] And are they different signature schemes?  Some people might not think
so based on what is currently documented.  Can you switch the signature
format between the two schemes?  If so does that mean that they are really
different?

Jim

From: Lake  <mailto:[email-masked]> <[email-masked]> On Behalf
Of Pascal Thubert (pthubert)
Sent: Monday, February 3, 2020 5:29 AM
To: [email-masked] <mailto:[email-masked]> 
Cc: [email-masked] <mailto:[email-masked]> ; Shwetha Bhandari
(shwethab)  <mailto:[email-masked]> <[email-masked]>; The IESG
<mailto:[email-masked]> <[email-masked]>; [email-masked] <mailto:[email-masked]> ;
[email-masked] <mailto:[email-masked]> ; Benjamin Kaduk
<mailto:[email-masked]> <[email-masked]>
Subject: [Lake] SEC-DIR review of AP-ND:

Dear all

 

 

Pascal

-- 
email: [email-masked] <mailto:[email-masked]>  | Skype:
rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 287-3867

---

From: Rene Struik <[email-masked]>
Date: Tue, 4 Feb 2020 00:05:49 -0500

On 2/3/2020 5:49 PM, Jim Schaad wrote:
>
> *From:* Rene Struik <[email-masked]>
> *Sent:* Monday, February 3, 2020 12:47 PM
> *To:* Jim Schaad <[email-masked]>; 'Pascal Thubert (pthubert)' 
> *Cc:* [email-masked]; 'Shwetha Bhandari (shwethab)' 
> <[email-masked]>; 'The IESG' <[email-masked]>; [email-masked]; 
> 'Benjamin Kaduk' <[email-masked]>
> *Subject:* Re: [Lake] SEC-DIR review of AP-ND:
>
> Hi Jim:
>
>     What is following is personal opinion (although I will admit to
>     being one of the DEs on these registries):
>
> [JLS]  I would suggest going and reading through JOSE mailing list for 
> how things were setup for there.  I think that you and I have a 
> different view of how the curves are setup for the difference between 
> OKP and EC2. For the EC2 curves, there are both an X and a Y point 
> publicly provided to the user.  For the Edwards curve, only the X 
> portion of the point is provided publicly to the user.  This means 
> that there would be a large discussion of what should be done with the 
> Y coordinate.  Being able to validate that the correct set of fields 
> are present without having to understand all of the fields is 
> considered to be desirable, at least by me, so reflecting that 
> difference between the two key formats is logical.   I don’t see it as 
> being random at all.  I can see some future three coordinate version 
> of a hyperspace that might come in the future that would get some type 
> of 3 point public key and that would again require a new key format to 
> be defined.  (Note that I have no reason to expect it, just that I can 
> imagine it.)
>
RS2>> In the future, one may indeed have to deal with definition of new 
key formats (which is beyond scope of ap-nd deliberations). Just for 
clarity: For EdDSA, one currently, uses lossless point compression, 
whereas for X25519, one exchanges only the x-coordinates (lossy 
compression), and for Weierstrass curves one uses lossless, but 
uncompressed coordinates. <<RS2

>
>
>      2. In my opinion, table 2 should not be referencing the
>         Curve25519 in the last column.  From my point of view when
>         curves are expressed as using different coordinate systems
>         then you need to be expressing these as different curves.  An
>         algorithm negotiation currently only needs to include the
>         curve and not additionally include the point format.  This
>         needs to be maintained.  I therefore believe that a new curve
>         code point should be registered here.  That is the only
>         registration that I believe needs to be done in the JOSE
>         registries.
>
> [JLS]  If you do not plan to use either JOSE or COSE key formats, then 
> you are free to do what you will.  If you want to use those key 
> formats then I am afraid that you are going to need to deal with the 
> perceptions of the people who currently hold the review world there.
>
RS2>> If not both entries in the tuple (curve, representation 
conventions) are the same, then reuse of the long-term public-private 
key pair may not be safe. As an example, if one were to use Edwards25519 
with deterministic Schnorr and defines two instantiations, viz.  (1) 
with LSB/lsb representation and (2) with MSB/msb representation, then 
one can certainly not reuse long-term public/private key pairs, since 
this would immediately expose the private key (since the hash function 
H(R,Q,m) would have differently formatted representations of R:=kG and 
Q:=dG. I hope this illustrates that representation conventions are an 
essential part of a signature scheme. In the end, we both mean the same 
thing, except that my statement was a little bit broader, in the sense 
that representations are another input parameter of an instantiation of 
a signature scheme. <<RS2
>
>     3.
>
>     Note, I find section 7.5 to be missing a small piece of guidance
>     that might be needed.  If you use the “same” private key for both
>     the Edwards and Weierstrass curve representations, is that a
>     problem according to this guidance?
>
> signature schemes is not allowed.  <<RS
>
> [JLS] And are they different signature schemes?  Some people might not 
> think so based on what is currently documented.  Can you switch the 
> signature format between the two schemes?  If so does that mean that 
> they are really different?
>
RS2>> Those schemes are different per the remark above, since the pairs 
(curve, representation conventions) are different. Perhaps, 
reformulating this as different instantiations of signature schemes 
would satisfy your remark? <<RS2
>
>     Jim
>
>     *From:* Lake <[email-masked]>
>     <mailto:[email-masked]> *On Behalf Of *Pascal Thubert
>     (pthubert)
>     <mailto:[email-masked]>
>     *Cc:* [email-masked] <mailto:[email-masked]>; Shwetha
>     Bhandari (shwethab) <[email-masked]>
>     <mailto:[email-masked]>; The IESG <[email-masked]>
>     <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>;
>     [email-masked] <mailto:[email-masked]>; Benjamin Kaduk
>     <[email-masked]> <mailto:[email-masked]>
> email:[email-masked]  <mailto:[email-masked]>  | Skype: rstruik