Re: [apps-discuss] [http-auth] Web Keys and HTTP Signatures

[Michael Thomas <[e-mail]>]

Manu Sporny wrote:
> Yes, it seems like a very applicable technology for your use case. The
> one thing I missed is whether or not DKIM allows multiple identities per
> user in a domain? Does it let users create as many sub-accounts as they
> want and associate keys with them? Anything is possible, what I'm asking
> is if this is something that is standardized. Access to DNS places a
> pretty high bar and we were hoping to lower that by a significant amount
> with Web Keys.
> 
>>From my understanding, DKIM defines a domain-level digital signature
> authentication framework. WebKeys defines a identity-level digital
> signature authentication framework.


You can have any number of selectors per domain. Selectors can be delegated
as needed (or not). Whether it's a good idea to have zillions of records served
by given zone is another matter. I assume that an untrusted client has a selector.
That is another thing that's worth considering because the use case it's been
deployed with is mainly ~trustable entities. I don't see why that would be problem
off the top of my head, but it's worth thinking about.

> Where DKIM uses the DNS system to discover key information for a domain.
> Web Keys uses the Web and Linked Data formats to discover key
> information for a particular identity.

DKIM uses DNS to store raw public keys. No more, no less. It is linked to
a domain insofar as the domain's owners/managers determines what is populated
in its zone files. The bigger issue in my mind is whether you need DNSSEC.
For mail signing, it was an acceptable risk to not have the keys themselves
be signed. If you require that level of protection, then it implies DNSSEC
and all of the machinery behind it. Which isn't to say it's not possible,
just TANSTAAFL.

Mike