I think people are reading more into my comment about raw keys than I said.
The specific historical use case was that we needed to verify a signature with a specific PK. There was no certificate chain, no PKI processing of any kind required. The key was explicitly trusted. Revocation was out of scope. Therefore we (SAML TC) decided to specify the use of a PK as a binary value, not imbedded in a cert. When implementations were done, it was discovered that common libraries, OpenSSL for example, expected the key to be contained in something that looked like an ASN.1 formatted certificate. It would not accept a binary value. In order to use such a library, it was necessary to gin up an ASN.1 certificate structure and stuff in the key value, simply to comply with the requirements of the method signature. I am not talking about doing PKI. I am not talking about doing X.509. I am not talking about processing any other part of the cert except the PK. I am talking about defining something that is practical to implement. I agree with those who believe both forms should be specified. There seems to be a distinct argument about the generality of the spec, which I will address in a separate message. Hal -----Original Message----- From: Paul C. Bryan [mailto:paul.br...@forgerock.com] Sent: Monday, August 08, 2011 1:09 PM To: woes@ietf.org Subject: Re: [woes] Naked Public Key, was: RE: Proposed charter, post-Quebec edition 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
