Subject: Re: [Unbearable] Base64url encoding in draft-ietf-tokbind-https

From: Brian Campbell <[email-masked]>
Date: Mon, 1 Aug 2016 09:53:51 -0600

Most base64 decoders, I think, will happily handle both padded and unpadded
input.  So it probably doesn't matter all that much. But for consistency
and marginal space savings, I'd be in favor of having HTTPSTB say to omit
the padding. There's some language in a comment on
https://github.com/TokenBinding/Internet-Drafts/issues/27 to that effect,
which could be borrowed from, if desired.

Most base64 encoders/decoders (nowadays?) also handle both the standard and
the URL/filename safe alphabet. I don't really think there's value in an
appendix like the one in RFC 7515.

On Fri, Jul 29, 2016 at 4:30 PM, John Bradley <[email-masked]> wrote:

> Brian Campbell has pointed out to me that in testing Chrome 54.0.2811.0
> it is sending Sec-Token-Binding headers with padding.
>
> In https://tools.ietf.org/html/draft-ietf-tokbind-https-05#section-2 we
> say
>
>  The header field name is "Sec-Token-Binding", and
>    EncodedTokenBindingMessage is a base64url encoding (see [RFC4648]
>    Section 5 <https://tools.ietf.org/html/rfc4648#section-5>) of the TokenBindingMessage as defined in
>    [I-D.ietf-tokbind-protocol <https://tools.ietf.org/html/draft-ietf-tokbind-https-05#ref-I-D.ietf-tokbind-protocol>]
>
>
> When we did JOSE we found RFC4648
> <https://tools.ietf.org/html/rfc4648#section-5> a touch to vague on
> padding.  in principal encoders and decoders will work both ways.
> However for interoperability and space saving we required the producer to
> send non padded to avoid confusion.
>
> We also added a appendix to help people with base64url without padding.
> https://tools.ietf.org/html/rfc7515#appendix-C
>
> Can the authors  look at clarifying this,  as written sending with or
> without padding is allowed by my reading.
>
> Including the appendix would also be fine with me if people think it would
> help clarify things for developers.
>
> Thanks.
>
> John B.
>
> _______________________________________________
> Unbearable mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/unbearable
>
>

---

From: John Bradley <[email-masked]>
Date: Mon, 01 Aug 2016 12:13:31 -0400

Decoders will likely do the correct thing.  However having one correct way to produce encoded token binding message will reduce confusion I suspect, it makes examples less ambiguous.

John B.
> On Aug 1, 2016, at 11:53 AM, Brian Campbell <[email-masked]> wrote:
> 
> Most base64 decoders, I think, will happily handle both padded and unpadded input.  So it probably doesn't matter all that much. But for consistency and marginal space savings, I'd be in favor of having HTTPSTB say to omit the padding. There's some language in a comment on https://github.com/TokenBinding/Internet-Drafts/issues/27 <https://github.com/TokenBinding/Internet-Drafts/issues/27> to that effect, which could be borrowed from, if desired. 
> 
> Most base64 encoders/decoders (nowadays?) also handle both the standard and the URL/filename safe alphabet. I don't really think there's value in an appendix like the one in RFC 7515. 
> 
> On Fri, Jul 29, 2016 at 4:30 PM, John Bradley <[email-masked] <mailto:[email-masked]>> wrote:
> Brian Campbell has pointed out to me that in testing Chrome 54.0.2811.0 it is sending Sec-Token-Binding headers with padding.
> 
> In https://tools.ietf.org/html/draft-ietf-tokbind-https-05#section-2 <https://tools.ietf.org/html/draft-ietf-tokbind-https-05#section-2> we say
> When we did JOSE we found RFC4648 <https://tools.ietf.org/html/rfc4648#section-5> a touch to vague on padding.  in principal encoders and decoders will work both ways.
> However for interoperability and space saving we required the producer to send non padded to avoid confusion.
> 
> https://tools.ietf.org/html/rfc7515#appendix-C <https://tools.ietf.org/html/rfc7515#appendix-C>
> 
> Can the authors  look at clarifying this,  as written sending with or without padding is allowed by my reading.
> 
> Including the appendix would also be fine with me if people think it would help clarify things for developers.
> 
> Thanks.
> 
> John B.
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/unbearable <https://www.ietf.org/mailman/listinfo/unbearable>
> 
>

---

From: Dirk Balfanz <[email-masked]>
Date: Mon, 01 Aug 2016 23:07:32 +0000

Can you guys propose some language how to make this more precise? And add
that to https://github.com/TokenBinding/Internet-Drafts/issues/56 ?

Thanks,

Dirk.

On Mon, Aug 1, 2016 at 9:13 AM John Bradley <[email-masked]> wrote:

> Decoders will likely do the correct thing.  However having one correct way
> to produce encoded token binding message will reduce confusion I suspect,
> it makes examples less ambiguous.
>
> John B.
>
> Most base64 decoders, I think, will happily handle both padded and
> unpadded input.  So it probably doesn't matter all that much. But for
> consistency and marginal space savings, I'd be in favor of having HTTPSTB
> say to omit the padding. There's some language in a comment on
> Most base64 encoders/decoders (nowadays?) also handle both the standard
> and the URL/filename safe alphabet. I don't really think there's value in
> an appendix like the one in RFC 7515.
>
>> Including the appendix would also be fine with me if people think it
>> would help clarify things for developers.
>>
>> Thanks.
>>
>> John B.
>>

---

From: [email-masked]
Date: Tue, 02 Aug 2016 01:06:29 -0600

> that to https://github.com/TokenBinding/Internet-Drafts/issues/56 ?

see:  
https://github.com/TokenBinding/Internet-Drafts/issues/56#issuecomment-236815758

>>>    [I-D.ietf-tokbind-protocol  
>>> <https://tools.ietf.org/html/draft-ietf-tokbind-https-05#ref-I-D.ietf-tokbind-protocol>]
>>>
>>>

---

From: Brian Campbell <[email-masked]>
Date: Tue, 2 Aug 2016 08:14:20 -0600

I just submitted pull request #57
<https://github.com/TokenBinding/Internet-Drafts/pull/57>, which has
proposed language for this (also copied below).

   The header field name is "Sec-Token-Binding" and its value is a
   base64url encoding of the TokenBindingMessage defined in
   [I-D.ietf-tokbind-protocol] using the URL- and filename-safe
   character set described in Section 5 of [RFC4648], with all trailing
   pad characters '=' omitted and without the inclusion of any line
   breaks, whitespace, or other additional characters.

On Tue, Aug 2, 2016 at 1:06 AM, <[email-masked]> wrote:

>>>>    [I-D.ietf-tokbind-protocol <
>>>> https://tools.ietf.org/html/draft-ietf-tokbind-https-05#ref-I-D.ietf-tokbind-protocol
>>>> >]
>>>>
>>>>

---

From: Mike Jones <[email-masked]>
Date: Tue, 2 Aug 2016 14:50:35 +0000

+1

From: Unbearable [mailto:[email-masked]] On Behalf Of Brian Campbell
Sent: Tuesday, August 2, 2016 7:14 AM
To: Jeff Hodges <[email-masked]>
Cc: IETF Tokbind WG <[email-masked]>; =JeffH Hodges <[email-masked]>; Dirk Balfanz <[email-masked]>; Andrei Popov <[email-masked]>; John Bradley <[email-masked]>
Subject: Re: [Unbearable] Base64url encoding in draft-ietf-tokbind-https

I just submitted pull request #57<https://github.com/TokenBinding/Internet-Drafts/pull/57>, which has proposed language for this (also copied below).

On Tue, Aug 2, 2016 at 1:06 AM, <[email-masked]<mailto:[email-masked]>> wrote:

Quoting Dirk Balfanz <[email-masked]<mailto:[email-masked]>>:
Can you guys propose some language how to make this more precise? And add
that to https://github.com/TokenBinding/Internet-Drafts/issues/56 ?

see: https://github.com/TokenBinding/Internet-Drafts/issues/56#issuecomment-236815758

On Mon, Aug 1, 2016 at 9:13 AM John Bradley <[email-masked]<mailto:[email-masked]>> wrote:
Decoders will likely do the correct thing.  However having one correct way
to produce encoded token binding message will reduce confusion I suspect,
it makes examples less ambiguous.

John B.

On Aug 1, 2016, at 11:53 AM, Brian Campbell <[email-masked]<mailto:[email-masked]>>
wrote:

On Fri, Jul 29, 2016 at 4:30 PM, John Bradley <[email-masked]<mailto:[email-masked]>> wrote:
Brian Campbell has pointed out to me that in testing Chrome 54.0.2811.0
it is sending Sec-Token-Binding headers with padding.

Thanks.

John B.

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

---

From: "Hodges, Jeff" <[email-masked]>
Date: Tue, 2 Aug 2016 21:50:05 +0000

+1

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, August 2, 2016 at 7:50 AM
To: Brian Campbell <[email-masked]<mailto:[email-masked]>>, =JeffH <[email-masked]<mailto:[email-masked]>>
Cc: Tokbind WG <[email-masked]<mailto:[email-masked]>>, "Hodges, Jeff" <[email-masked]<mailto:[email-masked]>>, Dirk Balfanz <[email-masked]<mailto:[email-masked]>>, Andrei Popov <[email-masked]<mailto:[email-masked]>>, John Bradley <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Unbearable] Base64url encoding in draft-ietf-tokbind-https

+1

From: Unbearable [mailto:[email-masked]] On Behalf Of Brian Campbell
Sent: Tuesday, August 2, 2016 7:14 AM
To: Jeff Hodges <[email-masked]<mailto:[email-masked]>>
Cc: IETF Tokbind WG <[email-masked]<mailto:[email-masked]>>; =JeffH Hodges <[email-masked]<mailto:[email-masked]>>; Dirk Balfanz <[email-masked]<mailto:[email-masked]>>; Andrei Popov <[email-masked]<mailto:[email-masked]>>; John Bradley <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Unbearable] Base64url encoding in draft-ietf-tokbind-https

John B.

Thanks.

John B.