[doseta-discuss] suggestions/concerns on spec

[Mark Nottingham]

On 03/06/2011, at 4:04 AM, Bill Burke wrote:

> Sorry, this might get very long...
> 
> We're looking seriously to promote Doseta as a means to sign messages for restful web services.  After implementing Doseta in Java, talking to various engineers when I was at a recent JBoss/Red Hat conference, and talking to a couple of users that have signing requirements, here's some of my thoughts on doseta.
> 
> * Maybe I'm unclear or new to the current notation, but the spec is a little unclear on the signing and verification algorithm.  Either better examples are needed or clearer language.  I can suggest some changes to that section if the doc if you're open.
> 
> 
> * I've discussed with a few people and one of the biggest suggestions is to split the document(s) into various pluggable parts:
> 
> - Public key discovery should be fully broken out with DKIM as one possible solution for public key discover.  One of the problems I had was to actually find somebody that has deployed DKIM.  I could not find anybody as of yet.  The people I talked to thought using DNS was an interesting idea, but the biggest concern was the lack of knowledge/deployment of DNS Sec.  Security sounds like it might be an issue with public key publication.  I don't know enough about DNS to say whether or not something like DNS SEc would be required to ensure the integrity of the public key you are obtaining to verify a signature.
> 
> - Many people I talked to thought DNS would be difficult to deploy and manage for a public key infrastructure.  I myself had difficulties finding a DNS solution that I could embed in unit tests (even then I had to hack it).  Then I had to learn how to configure DNS text records (yeah, its easy, but...).  Generally application developers just don't have the know-how or permission to set up a DNS server.  I and others I've talked to would really like to have HTTP-based solution to publish keys.

+1. My thinking has been RFC5785 over HTTPS...


> - A very generic signature header specification that describes how the signature header is created, canonicalized, and how the hash and signing algorithms are applied.  Very few fields should be required.  And only a few defined (like bh, v, h only).  SOme of the people talked to are interested in a signature header spec, but uninterested in DKIM.  Like for instance, they want to be able to use a signature header to sign requests and not necessarily a body.  It would be good to define something that people can refer to and innovate with on their own for their own purposes.
> 
> - A field registry where people can register their own custom fields for the signature header
> 
> - Separate specs for different use cases:  Email, HTTP.  Not sure how different they'd actually be, but, who knows.
> 
> I'd be willing to draft any part of these suggestions.  Let me know.
> 
> Thanks,
> 
> Bill
> 
> 
> -- 
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> doseta-discuss mailing list
> doseta-discuss at trusteddomain.org
> http://www.trusteddomain.org/mailman/listinfo/doseta-discuss

--
Mark Nottingham   http://www.mnot.net/