Re: [woes] Naked Public Key, was: RE: Proposed charter, post-Quebec edition

[John Bradley <[e-mail]>]

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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/woes
> 
> _______________________________________________
> woes mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/woes