Hi Joe, Its perfectly ok (and necessary for interop) for the implementers to agree beforehand about which cipher(s) are must implement. Support for multiple ciphers is a good thing. However, there is no need to call these out within the JOSE specification.
Perhaps the chairs can simply do a WG consensus call to ask which ciphers/algorithms to implement as part of the first WG deliverables. /thomas/ __________________________________________ > -----Original Message----- > From: Joe Hildebrand [mailto:[email protected]] > Sent: Tuesday, August 09, 2011 2:34 PM > To: Thomas Hardjono; [email protected] > Subject: Re: [woes] Support multiple Crypto algorithms? was RE: > Proposed charter, post-Quebec edition > > One of the goals of JOSE is to increase the number of interoperable > implementations. I don't think a lack of MTI algorithms will further > that goal. > > > On 8/9/11 12:02 PM, "Thomas Hardjono" <[email protected]> wrote: > > > > > As far as I can remember, CMS (RFC3852 and RFC5652) does not choose > > any specific algorithm. > > > > Therefore it make sense for JOSE to follow the same approach. > > > > /thomas/ > > > > > > > > __________________________________________ > > > > From: [email protected] [mailto:[email protected]] On Behalf > > Of Phillip Hallam-Baker > > Sent: Monday, August 08, 2011 10:34 PM > > To: Joe Hildebrand > > Cc: [email protected] > > Subject: Re: [woes] Support multiple Crypto algorithms? was RE: > > Proposed charter, post-Quebec edition > > > > > > On Mon, Aug 8, 2011 at 8:48 PM, Joe Hildebrand > > <[email protected]> > > wrote: > > Agree. Algorithm agility is a must, but large numbers of supported > > algorithms out of the gate are not. Having a small set of algorithms > > widely-implemented will increase interoperability drastically, > > particularly considering that in some of the target operating > > environments, we'll need to wait for people with adequate > cryptographic skills to help. > > > > I do really like the idea of splitting the MTI specification into a > > small separate draft, so that it can be rev'd easily as needed. > > > > +1 > > > > And that way we can have two profiles (or more) to address different > > implementation situations. > > > > Web Services implementation constraints are frequently asymmetric. > > There is one portion built on some all-singing/dancing platform like > > .NET or whatever and that talks to a thin client embedded in Jscript > > or a mobile device or what-have-you. > > > > If we can avoid creating yet another crypto-registry (i.e. re-use the > > PEM or whatever algorithm registry) then all the spec needs to say is > > that X is the slot where the algorithm name goes and the MTI doc(s) > > specify how to get interoperability. > > > > -- > Joe Hildebrand _______________________________________________ woes mailing list [email protected] https://www.ietf.org/mailman/listinfo/woes
