I find the canonicalization argument to be very misrepresented. The lesson learned from the XML signature world is that you do not want both sides to have to perform the same canonicalization. It is not that you don't want the sender to canonicalize. After all, by stating that you must use base64URL you are doing a canonicalization step - you are saying that it must be encoded this way.
I don't think it matters one whit to the receiving agent if the base64 decode routine is able to decode both base64 and base64url values. It just needs to accept the values sent to it by the sending agent. Jim From: [email protected] [mailto:[email protected]] On Behalf Of Bob Wyman Sent: Tuesday, September 04, 2012 2:22 PM To: Jim Schaad Cc: Mike Jones; [email protected] Subject: Re: [jose] Use of Base64 encoding On Tue, Sep 4, 2012 at 5:10 PM, Jim Schaad <[email protected]> wrote: I hope that you have a better response than this. If what you say is true then we should eliminate a large number of the cryptographic algorithms that have been proposed as they provide multiple ways of doing things. Do you really believe that the difference in the receiving software is going to be that different based on if base64 or base64URL encoding is used on a binary value? I think the whole point of using something like either base64 or base64URL encoding is to make the system as simple as possible. The alternative, used in the past, was to require some kind of complex canonicalization. That canonicalization proved, in many cases, to be so cumbersome that it prevented developers from building solutions to real problems. The base64* solution is the extreme opposite of the more complex canonicalization approach. Certainly, there are all sorts of intermediate positions between the two extremes, but it seems to me that we should avoid those mid-points unless there is some really significant benefit for doing so. bob wyman Jim > -----Original Message----- > From: Mike Jones [mailto:[email protected]] > Sent: Tuesday, September 04, 2012 1:46 PM > To: Jim Schaad; [email protected] > Subject: RE: [jose] Use of Base64 encoding > > Having multiple ways to do something never helps improve interop > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Jim Schaad > Sent: Tuesday, September 04, 2012 1:38 PM > To: [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] > 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
