Subject: [Unbearable] PR#82: TBPROTO: update ECPoint.point to be in X9.62 format with leading 0x04 byte

From: =JeffH <[email-masked]>
Date: Tue, 6 Dec 2016 12:36:17 -0800

PR#82: TBPROTO: update ECPoint.point to be in X9.62 format with leading 
0x04 byte, fixes #62
https://github.com/TokenBinding/Internet-Drafts/pull/82

see also: https://github.com/TokenBinding/Internet-Drafts/issues/62

I seem to recall we discussed this in Seoul ietf-97, but neither my 
notes or the minutes seem to have captured that portion of the discussion.

In any case, in case we can get rough consensus to make have the 
ECPoint.point format match that of X9.62  (and SEC1-v2 S 2.3.3 [1]), 
this PR#82 implements that.

HTH,

=JeffH

[1] http://www.secg.org/sec1-v2.pdf

---

From: Andrei Popov <[email-masked]>
Date: Tue, 6 Dec 2016 22:11:59 +0000

This change would add a fixed-value (0x04), 1-byte prefix to the encoding of the ecdsap256 TB IDs.
This 1-byte prefix would not serve any purpose in the Token Binding protocol, except that it would enable us to call our ECPoint representation "uncompressed point format per ANSI.X9-62.2005".

The above label does not mean much to me, so I would rather not add the fixed-value prefix that implementations will simply skip.
However, I think we should discuss this on the unbearable mailing list and ask our chairs to gauge WG consensus, so that we can resolve this one way or the other.

Thanks,

Andrei

-----Original Message-----
From: Unbearable [mailto:[email-masked]] On Behalf Of =JeffH
Sent: Tuesday, December 6, 2016 12:36 PM
To: IETF TokBind WG <[email-masked]>
Subject: [Unbearable] PR#82: TBPROTO: update ECPoint.point to be in X9.62 format with leading 0x04 byte

I seem to recall we discussed this in Seoul ietf-97, but neither my notes or the minutes seem to have captured that portion of the discussion.

In any case, in case we can get rough consensus to make have the ECPoint.point format match that of X9.62  (and SEC1-v2 S 2.3.3 [1]), this PR#82 implements that.

HTH,

=JeffH

_______________________________________________
Unbearable mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/unbearable

---

From: Martin Thomson <[email-masked]>
Date: Wed, 7 Dec 2016 07:22:22 +0900

On 7 December 2016 at 05:36, =JeffH <[email-masked]> wrote:
> PR#82: TBPROTO: update ECPoint.point to be in X9.62 format with leading 0x04
> byte, fixes #62

Thanks Jeff, I think that this is a good idea.  There is more value in
uniformity than in any narrow notion of optimality

---

From: Bill Cox <[email-masked]>
Date: Tue, 6 Dec 2016 14:31:19 -0800

Well... this would be a binary incompatible change, meaning I'd have to
start over with syncing with Chrome.  The powers-that-be require that any
change I make takes several weeks to go live.  I can have Google support
for the -10 version global sometime in Jan if we do not make this change.

Bill

On Tue, Dec 6, 2016 at 2:22 PM, Martin Thomson <[email-masked]>
wrote:

> 0x04

---

From: Nick Harper <[email-masked]>
Date: Tue, 6 Dec 2016 14:52:42 -0800

I agree with Martin and Jeff. Let's use pre-existing standards unless
there's a good reason not to.

---

From: Brian Campbell <[email-masked]>
Date: Tue, 6 Dec 2016 16:28:03 -0700

However, in this case, there's not a compelling reason to use that
preexisting standard either.

Value comes from using preexisting standards when there exist reusable
abstractions/implementations of the standard. I've not seen that to be the
case and X9.62 just becomes extra baggage.

X9.62 2005 isn't exactly easily accessible either - I've not been able to
find a copy that doesn't require $100 payment.

As Andre has said, the only thing that using the X9.62 format seems to do
is allow TB to call the ECPoint representation "uncompressed point format
per ANSI.X9-62.2005". I don't see the value in that.

It'd also be an incompatible change (as Bill points out). That's a good
reason, to me anyway, to not make the change at this late stage in the
process.

And yes it's only 1 byte but it's a unnecessary byte that's just going to
be ignored. I just don't see a benefit to adding that.

I'd prefer that we leave it as currently defined. Noting that there exist
multiple independent interoperable implementations of the current draft.

-- 
<https://www.pingidentity.com>
<https://www.pingidentity.com>
Brian Campbell
Distinguished Engineer
[email-masked]
w: +1 720.317.2061
c: +1 303.918.9415
Connect with us: 
<https://www.glassdoor.com/Overview/Working-at-Ping-Identity-EI_IE380907.11,24.htm>
[image:
LinkedIn logo] <https://www.linkedin.com/company/21870> [image: twitter
logo] <https://twitter.com/pingidentity> 
<https://www.facebook.com/pingidentitypage> 
<https://www.youtube.com/user/PingIdentityTV> 
<https://plus.google.com/u/0/114266977739397708540> 
<https://www.pingidentity.com/en/blog.html>
<https://www.pingidentity.com/en/about.html>

---

From: Martin Thomson <[email-masked]>
Date: Wed, 7 Dec 2016 08:50:48 +0900

This is a false economy: anyone who is using existing code will likely have
a library that produces X9.62.  All of the languages/libraries I'm aware of
natively support that format; only a few have native access to X and Y.  In
those languages/libraries, dealing with the custom format is more work.

Access to the spec isn't needed, Jeff included a nice definition.  (I've
never seen a copy myself and I haven't felt any pain.)

I think that the relevant concern is Bill's.

On 7 December 2016 at 08:28, Brian Campbell <[email-masked]>
wrote:

> <https://www.glassdoor.com/Overview/Working-at-Ping-Identity-EI_IE380907.11,24.htm> [image:

---

From: Bill Cox <[email-masked]>
Date: Tue, 6 Dec 2016 15:56:47 -0800

All they have to do is strip off the leading 0x04.  It does not make sense
to me to use a pseudo-standard for EC, but a custom format for RSA.

On Tue, Dec 6, 2016 at 3:50 PM, Martin Thomson <[email-masked]>
wrote:

> This is a false economy: anyone who is using existing code will likely
> have a library that produces X9.62.  All of the languages/libraries I'm
> aware of natively support that format; only a few have native access to X
> and Y.  In those languages/libraries, dealing with the custom format is
> more work.
>
>>> On Tue, Dec 6, 2016 at 2:22 PM, Martin Thomson <[email-masked]
>>> > wrote:
>>>
>> w: +1 720.317.2061 <(720)%20317-2061>
>> c: +1 303.918.9415 <(303)%20918-9415>
>> Connect with us:

---

From: Andrei Popov <[email-masked]>
Date: Wed, 7 Dec 2016 00:07:53 +0000

Ø  …anyone who is using existing code will likely have a library that produces X9.62.
This is not necessarily the case: I maintain existing TLS code that produces and consumes X9.62, but I have to add/strip the 0x04 in my code. The crypto libraries in Windows don’t handle 0x04 for me.
In practice, I’d rather not add a useless byte or change the wire format without a good technical reason (IMHO being able to reference X9.62 is not a good technical reason).

Cheers,

Andrei

From: Unbearable [mailto:[email-masked]] On Behalf Of Bill Cox
Sent: Tuesday, December 6, 2016 3:57 PM
To: Martin Thomson <[email-masked]>
Cc: IETF TokBind WG <[email-masked]>; Brian Campbell <[email-masked]>; Nick Harper <[email-masked]>; =JeffH <[email-masked]>
Subject: Re: [Unbearable] PR#82: TBPROTO: update ECPoint.point to be in X9.62 format with leading 0x04 byte

All they have to do is strip off the leading 0x04.  It does not make sense to me to use a pseudo-standard for EC, but a custom format for RSA.

On Tue, Dec 6, 2016 at 3:50 PM, Martin Thomson <[email-masked]<mailto:[email-masked]>> wrote:
This is a false economy: anyone who is using existing code will likely have a library that produces X9.62.  All of the languages/libraries I'm aware of natively support that format; only a few have native access to X and Y.  In those languages/libraries, dealing with the custom format is more work.
Access to the spec isn't needed, Jeff included a nice definition.  (I've never seen a copy myself and I haven't felt any pain.)
I think that the relevant concern is Bill's.

On 7 December 2016 at 08:28, Brian Campbell <[email-masked]<mailto:[email-masked]>> wrote:
However, in this case, there's not a compelling reason to use that preexisting standard either.
Value comes from using preexisting standards when there exist reusable abstractions/implementations of the standard. I've not seen that to be the case and X9.62 just becomes extra baggage.

X9.62 2005 isn't exactly easily accessible either - I've not been able to find a copy that doesn't require $100 payment.
As Andre has said, the only thing that using the X9.62 format seems to do is allow TB to call the ECPoint representation "uncompressed point format per ANSI.X9-62.2005". I don't see the value in that.
It'd also be an incompatible change (as Bill points out). That's a good reason, to me anyway, to not make the change at this late stage in the process.
And yes it's only 1 byte but it's a unnecessary byte that's just going to be ignored. I just don't see a benefit to adding that.
I'd prefer that we leave it as currently defined. Noting that there exist multiple independent interoperable implementations of the current draft.

On Tue, Dec 6, 2016 at 3:52 PM, Nick Harper <[email-masked]<mailto:[email-masked]>> wrote:
I agree with Martin and Jeff. Let's use pre-existing standards unless there's a good reason not to.

On Tue, Dec 6, 2016 at 2:22 PM, Martin Thomson <[email-masked]<mailto:[email-masked]>> wrote:

_______________________________________________
Unbearable mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/unbearable

_______________________________________________
Unbearable mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/unbearable

Brian Campbell
Distinguished Engineer
[email-masked]
w: +1 720.317.2061
c: +1 303.918.9415 <https://www.pingidentity.com>

Connect with us: <https://www.pingidentity.com>

_______________________________________________
Unbearable mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/unbearable<https://www.pingidentity.com>

---

From: Mike Jones <[email-masked]>
Date: Wed, 7 Dec 2016 03:23:59 +0000

I agree that adding a byte to all the packets for no actual gain is a bad tradeoff.  I advocate that things stay as they are.

                                                       -- Mike

From: Unbearable [mailto:[email-masked]] On Behalf Of Andrei Popov
Sent: Tuesday, December 6, 2016 4:08 PM
To: Bill Cox <[email-masked]>; Martin Thomson <[email-masked]>
Cc: IETF TokBind WG <[email-masked]>; Brian Campbell <[email-masked]>; =JeffH <[email-masked]>; Nick Harper <[email-masked]>
Subject: Re: [Unbearable] PR#82: TBPROTO: update ECPoint.point to be in X9.62 format with leading 0x04 byte

  *   …anyone who is using existing code will likely have a library that produces X9.62.
This is not necessarily the case: I maintain existing TLS code that produces and consumes X9.62, but I have to add/strip the 0x04 in my code. The crypto libraries in Windows don’t handle 0x04 for me.
In practice, I’d rather not add a useless byte or change the wire format without a good technical reason (IMHO being able to reference X9.62 is not a good technical reason).

Cheers,

Andrei

From: Unbearable [mailto:[email-masked]] On Behalf Of Bill Cox
Sent: Tuesday, December 6, 2016 3:57 PM
To: Martin Thomson <[email-masked]<mailto:[email-masked]>>
Cc: IETF TokBind WG <[email-masked]<mailto:[email-masked]>>; Brian Campbell <[email-masked]<mailto:[email-masked]>>; Nick Harper <[email-masked]<mailto:[email-masked]>>; =JeffH <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Unbearable] PR#82: TBPROTO: update ECPoint.point to be in X9.62 format with leading 0x04 byte

--

Brian Campbell
Distinguished Engineer

---

From: Brian Campbell <[email-masked]>
Date: Wed, 7 Dec 2016 06:33:34 -0700

In working on a sever side implementation in Java I've not found API
support for the X9.62 format. So that generalization might be a bit too
broad.

On Tue, Dec 6, 2016 at 5:07 PM, Andrei Popov <[email-masked]>
wrote:

> This is not necessarily the case: I maintain existing TLS code that
> produces and consumes X9.62, but I have to add/strip the 0x04 in my code.
> The crypto libraries in Windows don’t handle 0x04 for me.
>
> In practice, I’d rather not add a useless byte or change the wire format
> without a good technical reason (IMHO being able to reference X9.62 is not
> a good technical reason).
>
>
>
> Cheers,
>
>
>
> Andrei
>
>
>
> *From:* Unbearable [mailto:[email-masked]] *On Behalf Of *Bill
> Cox
> *Sent:* Tuesday, December 6, 2016 3:57 PM
> *To:* Martin Thomson <[email-masked]>
> *Cc:* IETF TokBind WG <[email-masked]>; Brian Campbell <
> [email-masked]>; Nick Harper <[email-masked]>; =JeffH <
> [email-masked]>
> *Subject:* Re: [Unbearable] PR#82: TBPROTO: update ECPoint.point to be in
> X9.62 format with leading 0x04 byte
>
>
>
> *Brian Campbell Distinguished Engineer [email-masked] w: +1
> 720.317.2061 c: +1 303.918.9415 <https://www.pingidentity.com>*
>
> *Connect with us: <https://www.pingidentity.com>*
>
> [email-masked]*
> *https://www.ietf.org/mailman/listinfo/unbearable*