On 12/11/2013 08:38 PM, John Bradley wrote: > Some of the comments are based on earlier drafts.
Yes, the blog post was created in August 2013, the research for the post was done in July 2013, and the latest specs at that time were used. > There are issues with using x.509 certificate representations in some > circumstances where you are using self signed keys rather than a pkix > trust model. Some will likely observer that making PEM the only > format and relying on certificate processing is fine if you are in a > pkix/ca world like the payment industry. Keep in mind that the only place we use PEM encoding is for the expression of public and private keys. We don't use PEM anywhere else in the stack, IIRC. > Others may not find that path as attractive. Others like who? :) I'm sure there are others, and I want to make sure we're not missing out on a large use case. Let me reiterate that we're not greatly interested in corner cases with the SM specs. If there are corner cases that need to be addressed, the JOSE stack is capable of addressing those corner cases. > It is interesting feedback, I understand the argument for simplicity, > however the desire to serve broad communities is something that needs > to be strongly considered. I think it would be more productive to understand which "broad community" isn't being considered with the SM work and whether the addition of complexity to the specification outweighs the benefit of supporting that community. > I also didn't see anything on requiring integrity for encryption in > the comparison, but I can't imagine that they would only support > AES-CBC with it's well understood security problems as the ony > encryption option. I will need to look at the actual spec. In general, we will support the minimum set of encryption methods necessary to make the security community happy (ideally, there would be one, which would be deprecated and updated every few years). The exact suite and parameters isn't as important as trying to ensure that there is just one mechanism every few years. It simplifies the range of input that applications need to deal with and test. It simplifies the number of parameters that developers need to deal with and understand. > There are ways to do a number of things to support the SM trust model > in JOSE. "jku":"http://example.org/manu/keys/5"; vs "creator": > "http://example.org/manu/keys/5"; > > In JOSE there is a logical separation between the identity of the > signer and the location of the key. In SM for simplicity identity > and location may the same thing. No, that's not the case in SM. The identity and the keys are logically separated. Here's my test identity (curl to get the JSON-LD representation): https://dev.payswarm.com/i/manu Here's one of the keys associated with my test identity: https://dev.payswarm.com/i/manu/keys/17 The reason we use the "creator" terminology is because the entity that created the signature is the key: http://dublincore.org/documents/dces/#creator There is a link from the key to the owner of that key (this command will give you the JSON-LD representation for that key): curl "https://dev.payswarm.com/i/manu/keys/17"; -- manu -- Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny) Founder/CEO - Digital Bazaar, Inc. blog: Meritora - Web payments commercial launch http://blog.meritora.com/launch/ _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
