+1 For openID Connect forcing x.509 processing in all environments is not practical, or desirable.
Not all environments can call out to openSSL. We will need to create new native libraries for some environments. Having a simple JSON container for key information is important to our developers. John Bradley On 2011-08-08, at 12:41 PM, 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. > > 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ woes mailing list woes@ietf.org https://www.ietf.org/mailman/listinfo/woes
