[doseta-discuss] Doing a DOSETA variant

[Bill Burke]

On 7/12/11 1:20 PM, Dave CROCKER wrote:
>>> 5. Reworked the section on Requirements for Tailoring the Signing
>>> Service, to use the signing template. This included adding "Required
>>> Fields" and "Required Algorithms" components.
>>>
>>
>> I'm not exactly clear what this section allows. For example. I'd like
>> to use
>> doseta to only sign a set of headers that come with the request
>
> You are describing a very different kind of rule for selecting header
> fields than the DOSETA base uses. Nothing says that using a template
> like this requires rigid adherence to every detail of the template. So,
> there's nothing wrong with what you want to do, of course, but it needs
> distinct specification language. (And, of course, it will affect the
> ability to use of any existing DOSETA software.)
>

Oh.  I thought DOSETA allowed you to add an arbitrary list of headers to 
add to the signature calculation?  I just wanted the option to leave out 
the "bh" field.

>
> Right. You want an entirely new key management service. Note that the
> "q=" tag is specifically for permitting this sort of alternative, albeit
> while still using domain names and selectors to name the keys.
>

I think I missed the "q" field last time I read the spec.  That will 
work for pluggability.  Thanks.

> Having noted the legality and the hint of support (via q=), I'll repeat
> my earlier comments that creating an Internet-scale critical-path query
> service has so far proved to be rather more daunting than devotees
> usually expect. There is a reason there are so few such services on the
> net and that existing services tend to be re-purposed for enhanced use.
>

I'm not ambitious (or stupid/naive) enough to go promoting a new 
"Internet-scale" protocol of anything.  I do think promoting a new 
"Enterprise-scale" or "Intranet-scale" protocol for app/service 
development is in the realm of possibilities though.  Its what I do...


> This probably should be distinguished between documentation issues vs.
> protocol specification issues.

I think this may (or may not) be a documentation issue.  It seems that 
DKIM/DOSETA is really the only mature spec out there that describes how 
to create/verify a signature header of parts of a message.  If somebody 
is designing a protocol that involves signatures, DOSETA should be *THE* 
spec to use.   I just worry that developers will use the key 
management/discovery requirements as an excuse to roll their own protocol.

Also, library developers take language like "MUST" and "REQUIRED" quite 
literally.  It would suck if I had to hack, fork, and maintain some 
doseta library all because I didn't want to have to provide a body-hash.

Am I making any sense?

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com