On Mon, 2011-08-08 at 11:28 -0700, Hal Lockhart wrote:
> There seems to be a position forming around the idea that > woes/joes/jose should specify (perhaps even design) a single algorithm > (perhaps one for sign and one for encrypt). I presume that means that > if in future it was necessary to use a different algorithm we would > just start over and write a new spec. If such a position is actually forming, I'd like to know why we'd want to pre-bake obsolescence into the spec. > I am not in favor of this, but I concede that it would simplify things > in this group a lot. If by simplify you mean thinning out the number of people who will find it useful, perhaps. ;-) > If there was only one algorithm, there is no need for any JSON > metadata about what the algorithm is being used. True, but perhaps at the very least we'd need some kind of metadata saying what version of JOSE is being used, if nothing more than to determine what version of what cipher(s) it supports. > All we need is a way to indicate what is signed or encrypted and > something that says this is a JOES signature (or encryption) and > perhaps some kind of indication of what key was used. This may not be enough, especially when JOSE undergoes a revision. > If we were to specify only one algorithm, but provide metadata to > indicate the algorithm, others will use additional, unspecified > algorithms, just as people used 3-DES and AES in Kerberos while > continuing to cite RFC 1510 which only includes DES. I think if we establish a minimum supported set, with extensibility (i.e. cipher suite can be specified), we retain core interoperability while not throwing out the standard when the core ciphers prove unsuitable. > I won't bother to list the many (many, many) reasons why a single > algorithm is unlikely to fly, unless it turns out a lot of people are > really committed to that view. +1 > Instead, I suggest we say explicitly say that multiple algorithms will > be possible, but one will be MTI. It wouldn't hurt to also say we are > not going to design any new algorithms, but simply provide means to > specify which existing one is being used. +1, though I suggest we may codify a handful of well-used suites while possibly making one mandatory to implement. Paul
_______________________________________________ woes mailing list [email protected] https://www.ietf.org/mailman/listinfo/woes
