We need base64URL for using the tokens in OAuth and other places in a URL. I don't see a benefit to making recipients figure out what encoding was used.
Stick with base64URL and if someone wants to convert it to base64 on receipt that is not a huge deal. John B. On 2012-09-04, at 6:21 PM, Bob Wyman <[email protected]> wrote: > > 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
