Subject: [Unbearable] ecdsap256 questions

From: Brian Campbell <[email-masked]>
Date: Tue, 17 May 2016 13:34:59 -0600

Is ecdsap256 the NIST P-256 curve? I'm guessing so but it's not totally
clear from the document. The relevant text (that I could find anyway) from
TBPROTO-03 here:

   "When an ecdsap256 key is used, TokenBinding.signature contains a pair
   of integers, R followed by S, as defined in [ANSI.X9-62.2005
<https://tools.ietf.org/html/draft-ietf-tokbind-protocol-05#ref-ANSI.X9-62.2005>].
R and
   S are encoded in big-endian format.  ECPoint.point contains the X
   coordinate followed by the Y coordinate.  The X and Y coordinates are
   unsigned integers encoded in big-endian format."

I was going to suggest that TBPROTO explicitly say that for ecdsap256 R & S
and X & Y always be exactly 32 octets/bytes long and that any leading zero
bytes be preserved (rare but possible AFAIK), which I assume was the intent
so that the point and signature can be consistently processed. Then I
thought maybe I should first look at ANSI.X9-62 to see if this was already
clearly stated there somewhere. But it seems that one can't actually read
X9-62 without shelling out $100, which is a lot to just look for a little
details like that.

So, from that fun little story (sorry!), a couple comments/questions:

Can TBPROTO state the curve used with the ecdsap256 TB key parameters in a
way that's easy and obvious? And maybe also cite a document that's a little
more accessible than X9-62 in doing so?  I believe many RFCs, 7518/JWA
<http://tools.ietf.org/html/rfc7518#section-3.4> for example, cite FIPS PUB
186-4 "Digital Signature Standard (DSS)"
<http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf> for ECDSA and
the P-* curves. I expect most implementers will be using an existing ECDSA
implementation and just need to get the parameters and input/output
formatted correctly. That reference and the text in JWA was enough for many
independent implementations to get it right with JWS.

And about getting the input/output formatted correctly, can or should
TBPROTO say that R&S/X&Y are always 32 bytes and so leading zeros need to
be added or retained?

Thanks for obliging my little questions,
Brian

---

From: Andrei Popov <[email-masked]>
Date: Fri, 20 May 2016 19:08:36 +0000

Thanks for the feedback Brian, I’ll clarify in the next revision.

Cheers,

Andrei

From: Unbearable [mailto:[email-masked]] On Behalf Of Brian Campbell
Sent: Tuesday, May 17, 2016 12:35 PM
To: IETF Tokbind WG <[email-masked]>
Subject: [Unbearable] ecdsap256 questions

Is ecdsap256 the NIST P-256 curve? I'm guessing so but it's not totally clear from the document. The relevant text (that I could find anyway) from TBPROTO-03 here:

   of integers, R followed by S, as defined in [ANSI.X9-62.2005<https://tools.ietf.org/html/draft-ietf-tokbind-protocol-05#ref-ANSI.X9-62.2005>].  R and

I was going to suggest that TBPROTO explicitly say that for ecdsap256 R & S and X & Y always be exactly 32 octets/bytes long and that any leading zero bytes be preserved (rare but possible AFAIK), which I assume was the intent so that the point and signature can be consistently processed. Then I thought maybe I should first look at ANSI.X9-62 to see if this was already clearly stated there somewhere. But it seems that one can't actually read X9-62 without shelling out $100, which is a lot to just look for a little details like that.
So, from that fun little story (sorry!), a couple comments/questions:
Can TBPROTO state the curve used with the ecdsap256 TB key parameters in a way that's easy and obvious? And maybe also cite a document that's a little more accessible than X9-62 in doing so?  I believe many RFCs, 7518/JWA<http://tools.ietf.org/html/rfc7518#section-3.4> for example, cite FIPS PUB 186-4 "Digital Signature Standard (DSS)"<http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf> for ECDSA and the P-* curves. I expect most implementers will be using an existing ECDSA implementation and just need to get the parameters and input/output formatted correctly. That reference and the text in JWA was enough for many independent implementations to get it right with JWS.
And about getting the input/output formatted correctly, can or should TBPROTO say that R&S/X&Y are always 32 bytes and so leading zeros need to be added or retained?
Thanks for obliging my little questions,
Brian

---

From: Nick Harper <[email-masked]>
Date: Mon, 23 May 2016 15:05:12 -0700

I'm curious as to why the format for R&S was chosen as such in draft-06.
The format that my implementation uses differs from what is in draft-06,
yet as far as I can tell is compliant with the draft-05 version. My
implementation formats the signature as a DER-encoded ECDSA-Sig-Value ASN.1
object. This is defined in RFC 5480, which refers to X9.62 as where this
ASN.1 definition comes from (I also don't have a copy of X9.62 to check
against). This definition (the ECDSA-Sig-Value ASN.1 object) is the same
format of signature used in tls, so it seems like a Token Binding library
should have no difficulty producing/consuming this signature format. If
X9.62 is going to be used as the reference for this pair of 32-byte ints
with leading zeroes, can the section of X9.62 that defines this be cited?

On Fri, May 20, 2016 at 12:08 PM, Andrei Popov <[email-masked]>
wrote:

> *From:* Unbearable [mailto:[email-masked]] *On Behalf Of *Brian
> Campbell
> *Sent:* Tuesday, May 17, 2016 12:35 PM
> *To:* IETF Tokbind WG <[email-masked]>
> *Subject:* [Unbearable] ecdsap256 questions
>
>
>
>    of integers, R followed by S, as defined in [ANSI.X9-62.2005 <https://tools.ietf.org/html/draft-ietf-tokbind-protocol-05#ref-ANSI.X9-62.2005>].  R and
>
> I was going to suggest that TBPROTO explicitly say that for ecdsap256 R &
> S and X & Y always be exactly 32 octets/bytes long and that any leading
> zero bytes be preserved (rare but possible AFAIK), which I assume was the
> intent so that the point and signature can be consistently processed. Then
> I thought maybe I should first look at ANSI.X9-62 to see if this was
> already clearly stated there somewhere. But it seems that one can't
> actually read X9-62 without shelling out $100, which is a lot to just look
> for a little details like that.
>
> <http://tools.ietf.org/html/rfc7518#section-3.4> for example, cite FIPS
> PUB 186-4 "Digital Signature Standard (DSS)"
> _______________________________________________
> Unbearable mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/unbearable
>
>

---

From: Martin Thomson <[email-masked]>
Date: Mon, 23 May 2016 18:17:42 -0400

On 23 May 2016 at 18:05, Nick Harper <[email-masked]> wrote:
> My implementation formats the signature as a DER-encoded ECDSA-Sig-Value
> ASN.1 object.

R||S is pretty widely used now.  We definitely don't need more
ASN.1+DER.  I think that you will find that there is no single
reference for this, though WebCrypto does it this way, as does a bunch
of other more modern stuff.

The idea being that you don't need to worry about R and S separately,
which is good for your API.  You definitely don't need to carry around
the extra baggage that DER provides you with.  That is, you keep the
API clean:

  S = sign(k, M)
  ok = verify(K, M, S)

---

From: Andrei Popov <[email-masked]>
Date: Mon, 23 May 2016 22:39:09 +0000

> I'm curious as to why the format for R&S was chosen as such in draft-06.

As early as TBPROTO-04 we said " R and S are encoded in big-endian format."
TBPROTO-06 only clarified that there are 32 bytes and leading zeros (if any) are preserved, per Brian's comment.

My original thinking was that we would use TLS-style ASN.1+DER, but there have been concerns about unnecessary complexity. I tend to agree with Martin that we don't need more ASN.1+DER...

Cheers,

Andrei

-----Original Message-----
From: Martin Thomson [mailto:[email-masked]] 
Sent: Monday, May 23, 2016 3:18 PM
To: Nick Harper <[email-masked]>
Cc: Andrei Popov <[email-masked]>; IETF Tokbind WG <[email-masked]>; Brian Campbell <[email-masked]>
Subject: Re: [Unbearable] ecdsap256 questions

R||S is pretty widely used now.  We definitely don't need more
ASN.1+DER.  I think that you will find that there is no single reference for this, though WebCrypto does it this way, as does a bunch of other more modern stuff.

The idea being that you don't need to worry about R and S separately, which is good for your API.  You definitely don't need to carry around the extra baggage that DER provides you with.  That is, you keep the API clean:

  S = sign(k, M)
  ok = verify(K, M, S)

---

From: Nick Harper <[email-masked]>
Date: Mon, 23 May 2016 16:16:57 -0700

I agree with you and Martin that we don't need more ASN.1 + DER, and the
format in draft 06 makes sense for something modern.

On Mon, May 23, 2016 at 3:39 PM, Andrei Popov <[email-masked]>
wrote:

> My original thinking was that we would use TLS-style ASN.1+DER, but there
> have been concerns about unnecessary complexity. I tend to agree with
> Martin that we don't need more ASN.1+DER...
>
> Cheers,
>
> Andrei
>
> Cc: Andrei Popov <[email-masked]>; IETF Tokbind WG <
> [email-masked]>; Brian Campbell <[email-masked]>
> ASN.1+DER.  I think that you will find that there is no single reference
> for this, though WebCrypto does it this way, as does a bunch of other more
> modern stuff.
>
> which is good for your API.  You definitely don't need to carry around the
> extra baggage that DER provides you with.  That is, you keep the API clean:
>
>   S = sign(k, M)
>   ok = verify(K, M, S)
>

---

From: Bill Cox <[email-masked]>
Date: Mon, 23 May 2016 17:19:28 -0700

> format in draft 06 makes sense for something modern.

Just one question: how are the RSA exponent and modulus length-prefixed?
Are they uint16-length-prefixed?

Bill

---

From: Andrei Popov <[email-masked]>
Date: Tue, 24 May 2016 00:30:31 +0000

struct {
    opaque modulus<1..2^16-1>;
    opaque publicexponent<1..2^8-1>;
} RSAPublicKey;

In “TLS Presentation Language”, this means 2 bytes of length prefix for modulus and 1 byte of length prefix for exponent.

Cheers,

Andrei

From: Bill Cox [mailto:[email-masked]]
Sent: Monday, May 23, 2016 5:19 PM
To: Nick Harper <[email-masked]>
Cc: Andrei Popov <[email-masked]>; IETF Tokbind WG <[email-masked]>; Brian Campbell <[email-masked]>; Martin Thomson <[email-masked]>
Subject: Re: [Unbearable] ecdsap256 questions

On Mon, May 23, 2016 at 4:16 PM, Nick Harper <[email-masked]<mailto:[email-masked]>> wrote:
I agree with you and Martin that we don't need more ASN.1 + DER, and the format in draft 06 makes sense for something modern.

Just one question: how are the RSA exponent and modulus length-prefixed?  Are they uint16-length-prefixed?

Bill

---

From: Brian Campbell <[email-masked]>
Date: Thu, 26 May 2016 15:17:16 -0600

Might there be some value in providing some examples in -tokbind-protocol
and/or -tokbind-https that could help serve to validate reader's
interpretation of the text?

As an implementer of JWS & JWE, for instance, I found the examples in the
documents to be exceptionally valuable in aiding my understanding and
helping to vet the implementation. I think some example
TokenBindingMessages in the TB doc(s) could be similarly valuable.

On Mon, May 23, 2016 at 6:30 PM, Andrei Popov <[email-masked]>
wrote:

> In “TLS Presentation Language”, this means 2 bytes of length prefix for
> modulus and 1 byte of length prefix for exponent.
>
>
>
> Cheers,
>
>
>
> Andrei
>
>
>
> *From:* Bill Cox [mailto:[email-masked]]
> *Sent:* Monday, May 23, 2016 5:19 PM
> *To:* Nick Harper <[email-masked]>
> *Cc:* Andrei Popov <[email-masked]>; IETF Tokbind WG <
> [email-masked]>; Brian Campbell <[email-masked]>; Martin
> Thomson <[email-masked]>
> *Subject:* Re: [Unbearable] ecdsap256 questions
>
>
>

---

From: Andrei Popov <[email-masked]>
Date: Tue, 31 May 2016 16:32:51 +0000

Hi Brian,

For me personally, looking at BLOBs doesn't help much. It is true that the spec relies on the reader understanding the "TLS presentation language". However, I don't feel strongly about this; if there is WG support for adding sample message BLOBs to the spec, I can do it once our implementation is up to date with the spec.

Cheers,

Andrei

From: Brian Campbell [mailto:[email-masked]]
Sent: Thursday, May 26, 2016 2:17 PM
To: Andrei Popov <[email-masked]>
Cc: Bill Cox <[email-masked]>; Nick Harper <[email-masked]>; IETF Tokbind WG <[email-masked]>; Martin Thomson <[email-masked]>
Subject: Re: [Unbearable] ecdsap256 questions

Might there be some value in providing some examples in -tokbind-protocol and/or -tokbind-https that could help serve to validate reader's interpretation of the text?

As an implementer of JWS & JWE, for instance, I found the examples in the documents to be exceptionally valuable in aiding my understanding and helping to vet the implementation. I think some example TokenBindingMessages in the TB doc(s) could be similarly valuable.

On Mon, May 23, 2016 at 6:30 PM, Andrei Popov <[email-masked]<mailto:[email-masked]>> wrote:
struct {
    opaque modulus<1..2^16-1>;
    opaque publicexponent<1..2^8-1>;
} RSAPublicKey;

Cheers,

Andrei

From: Bill Cox [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Monday, May 23, 2016 5:19 PM
To: Nick Harper <[email-masked]<mailto:[email-masked]>>
Cc: Andrei Popov <[email-masked]<mailto:[email-masked]>>; IETF Tokbind WG <[email-masked]<mailto:[email-masked]>>; Brian Campbell <[email-masked]<mailto:[email-masked]>>; Martin Thomson <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Unbearable] ecdsap256 questions

Bill

---

From: Brian Campbell <[email-masked]>
Date: Tue, 31 May 2016 12:22:58 -0600

Agree that just looking at BLOBs doesn't help much or at all. The value, I
think, is providing an early sanity check for implementations. Or parts of
implementations anyway. Several of the key parameter type's signatures
aren't deterministic so one can't just reproduce examples for those. But if
one can verify the examples and produce results that can also be verified,
it's a pretty good sign things are in good shape. The EKM value needs to be
provided with the example too for such implementation checks to be
possible. Such examples can help drive out interoperability problems
earlier on before implementations actually interoperate.

On Tue, May 31, 2016 at 10:32 AM, Andrei Popov <[email-masked]>
wrote:

> Hi Brian,
>
>
>
> For me personally, looking at BLOBs doesn't help much. It is true that the
> spec relies on the reader understanding the "TLS presentation language".
> However, I don't feel strongly about this; if there is WG support for
> adding sample message BLOBs to the spec, I can do it once our
> implementation is up to date with the spec.
>
>
>
> Cheers,
>
>
>
> Andrei
>
>
>
> *From:* Brian Campbell [mailto:[email-masked]]
> *Sent:* Thursday, May 26, 2016 2:17 PM
> *To:* Andrei Popov <[email-masked]>
> *Cc:* Bill Cox <[email-masked]>; Nick Harper <[email-masked]>;
> IETF Tokbind WG <[email-masked]>; Martin Thomson <
> [email-masked]>