[doseta-discuss] suggestions/concerns on spec

[Murray S. Kucherawy]

> -----Original Message-----
> From: doseta-discuss-bounces at blackops.org [mailto:doseta-discuss-bounces at blackops.org] On Behalf Of Bill Burke
> Sent: Thursday, June 02, 2011 11:05 AM
> To: doseta-discuss at trusteddomain.org
> Subject: [doseta-discuss] suggestions/concerns on spec
> 
> - 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.

DKIM's not at the point where we can say the majority of the Internet is using it, but a lot of big players are indeed using it (eBay/PayPal, Yahoo, Gmail, AOL, various other players).

I'm the lead engineer on one of the most widely used open source implementations, so I'm happy to answer any questions you might have about architecture or deployment.

> - 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.

I talked about doing this with Mark Nottingham at the Maastricht IETF and he also agreed it would be a good idea.  The pushback I got with pursuing such an effort involved the DKIM base; starting to sign now with keys in HTTP servers would mean lots of mail would hit verifiers that have no idea what that is and thus can't verify the signatures, and the perceived benefit was thus minimal at the time.  Maybe that's changed.

I'd be happy to help with such an effort, both in terms of updating our open source DKIM library to support it and ensuring that our DOSETA implementation does the same.

> - 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.

If that's not in DOSETA already then it definitely should be.

> - A field registry where people can register their own custom fields for
> the signature header

We have that for DKIM, so DOSETA should have that too if it doesn't already.  But really I think the idea is that for a specific application, you would create a new signing mechanism that follows the DOSETA model, and in the document that defines your new mechanism, you would create/register the new tags there.

> - Separate specs for different use cases:  Email, HTTP.  Not sure how
> different they'd actually be, but, who knows.

That's definitely appropriate.  DOSETA is the baseline, and then MIMEAUTH and DKIM are the layer above.  So I think we have something like that already.

-MSK