On Mon, 2011-08-08 at 09:41 -0700, Ben Adida wrote: > On 8/8/11 8:36 AM, Hal Lockhart wrote: > > > > I am with Eric here. I would like to explicitly state that I think it > > is NOT desirable to do anything which encourages people to do new > > implementations of crypto operations. The corollary is that the spec > > should specify objects in formats which make them easy to be passed > > as arguments to existing libraries, especially libraries which are > > likely to be present in the target environment. > > I think this may miss some important use cases. We're using JWT/JWS at > https://browserid.org, and we need to do all of the crypto in > JavaScript. JavaScript-based crypto, and crypto in other programming > languages in general, is likely to be a growing need. So, "no new > implementations" is unrealistic. There will be new implementations. > There have to be.
I think the point is that one should use existing, proven software libraries to implement the cryptography wherever possible—JOSE should not necessitate a novel application of cryptography to achieve the charter objectives. If no such library exists in a particular programming/runtime environment, then obviously one would need to be developed. That said, I would suggest that such a new implementation focus on implementing the cryptographic functions much the way they are implemented in other environments, and allow JOSE implementations to build upon that. > If we force these new implementations to bear the full complexity of > X.509, then we're introducing security risk. It would be much better if > we had a simpler, JSON-focused certificate format. > > We don't get to choose whether there will be new implementations. We > only get to choose how simple those have to be. > > -Ben > _______________________________________________ > woes mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/woes
_______________________________________________ woes mailing list [email protected] https://www.ietf.org/mailman/listinfo/woes
