[doseta-discuss] suggestions/concerns on spec

[Bill Burke]

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.

- 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