[doseta-discuss] Doing a DOSETA variant

[Dave CROCKER]

Bill,


On 7/12/2011 9:54 AM, Bill Burke wrote:
> On 7/12/11 11:59 AM, Dave CROCKER wrote:
>> 2. Drop 'version' tag -- versions don't get used
>
> Seems to still be a reference to the version tag in section 4.2

oops.  thanks.  so much for the infallibility of string searching; it still 
requires attentive eyes, which for me remains a challenge...


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

    My immediate suggestion is that the "Required Fields" section would need to 
contain a detailed protocol specification for this, rather than merely listing a 
set of header fields.


> and not required
>> the "d" field and make DNS lookup optional and/or provide a URI mechanism to
>> locate keys.

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.

In terms of a specification, this means that you need to specify the means by 
which different keys are distinguish (named) and obtained and administered.

Again, there is nothing inherently 'wrong' with doing any of that.  The template 
doesn't have a slot for this pre-defined. So the specification that makes use of 
DOSETA will need a section that replaces DOSETA's key management details.  (And, 
again, no existing DOSETA software can be re-used for this.)

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.

Still, given your enthusiasm for this, I'll suggest you start by specifying all 
of the necessary details to define a running service.  For example, saying "URI" 
is like saying "XML".  It covers a generic syntax, but none of the necessary 
details for actually doing something.


> I'm also wondering if it would be more beneficial to completely separate the
> Signing Service from Key Management. i.e. the signing template would make the
> "d" field optional. I can see a lot of developers (myself in particular) that
> will want to re-use the signing/verification/canonicalization algorithms of
> DOSETA, but not the key discovery and management requirements of DOSETA.

This probably should be distinguished between documentation issues vs. protocol 
specification issues.  Let's defer the documentation issues for now, since I 
think that the current documentation is well enough partitioned for your 
purposes.  (If you'd like to see better partitioning, let me know what you think 
it should look like.)

In terms of protocol specification, I think the q= parameter is a sufficient 
hook in the signing service mechanism to give you a means of invoking an 
entirely different key management service, unless you also require a completely 
different naming scheme for keys.  Given the reference to URIs, perhaps you do 
require that.  Except that URIs all contain domain names too, so some of this 
might be finessed.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net