No argument on that. We just can't assume that it is trivial to reemployment PKIX X.509 processing in all new environments. Using public keys without PKIX, is a simpler task.
Where we need to develop new libraries, using establishd cryptographic methods should be the goal. JWE/JWS had no intention of deviating from those norms and inventing new algorithms. John B. On 2011-08-08, at 1:09 PM, Paul C. Bryan wrote: > 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 >> woes@ietf.org >> https://www.ietf.org/mailman/listinfo/woes > > _______________________________________________ > woes mailing list > woes@ietf.org > https://www.ietf.org/mailman/listinfo/woes
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ woes mailing list woes@ietf.org https://www.ietf.org/mailman/listinfo/woes
