+1 to Bob's argument.
Just pick one and stick with it universally. I see no good reason to
deviate from that. Below, are you suggesting that we pick normal base64
for one value but base64url for others? Or are you suggesting that we
allow multiple kinds of encoding for these? If the latter, why wouldn't
you also allow hex encoding, or base32, or any number of arbitrary
binary encodings using the same argument as below. Base64URL is well
established, available on basically every platform, trivial to implement
if it's not, and doesn't run into any double-encoding issues in any of
the environments that we care about putting these values in. This isn't
a useful kind of flexibility that I can see, especially if we don't have
any way to signal what encoding is being used for a value. Do we want to
do something like:
hash: {
encoding: base64,
value: AeyBEadf2....
}
to accommodate that structure? I hope not.
One of the biggest problems with allowing both Base64 and Base64URL is
that in some cases they're exactly the same. This can lead you to
getting lucky picking the wrong encoding but getting the right result
one time, then having it blow up on you the second time. I've written
that exact bug a few times.
And more to the point: why *not* use Base64URL everywhere for binary
encoding? What *benefit* does it give you? I don't see any.
-- Justin
On 09/04/2012 05:06 PM, Bob Wyman wrote:
It seems to me that if the difference in the decoders is minimal, then
one should feel comfortable in requiring one rather than the other
since any benefit from providing individual developers choice is
likely to be minimal compared to the cost of added complexity for all
developers.
bob wyman
On Tue, Sep 4, 2012 at 4:45 PM, Mike Jones
<[email protected] <mailto:[email protected]>> wrote:
Having multiple ways to do something never helps improve interop
-----Original Message-----
From: [email protected] <mailto:[email protected]>
[mailto:[email protected] <mailto:[email protected]>] On
Behalf Of Jim Schaad
Sent: Tuesday, September 04, 2012 1:38 PM
To: [email protected] <mailto:[email protected]>
Subject: [jose] Use of Base64 encoding
<personal>
I was struck by the questions of which base64 encoder should be
used in the different documents that the working group employed
and I started going through the different locations in the
document to see where and how much it mattered if the base64 or
base64URL encoder was used. This message represents my
conclusions and leads to some questions
1. The simple dot encoding of the objects does require it as it
will possibly be sent as part of a URL 2. If you are going to be
in a space constrained environment then you MIGHT want it as it
will shrink the result, however doing a solution that deals with
binary data more generally would be a better solution.
3. Joe might have an argument that only doing things one way is
simpler, however that argument can apply in both directions
The rest of the time I don't think it matters which of the
encoding formats is used. If you are looking at the SHA-1 hash of
a certificate, does it matter if you use base64 or base64URL, not
except for the minor size increase. The padding characters
themselves are protected from the URL by the outside base64URL
encoding.
Except for the case of the dot encoding step, I think that the use
of base64 URL can be dropped from a MUST to a SHOULD with the
justifications being explained. It was stated at the F2F that the
difference in the decoders is minimal so there is no reason not to
allow there and this would allow different people to make
different decisions on this issue.
Jim
_______________________________________________
jose mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
