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. -- Website: http://hallambaker.com/ _______________________________________________ woes mailing list [email protected] https://www.ietf.org/mailman/listinfo/woes
