Subject: [Fwd: Re: Signatures - I blog, therefore I am...]

From: James M Snell <[email-masked]>
Date: Fri, 27 May 2005 11:23:25 -0700

In general, the idea of associating the signing keys with the network 
resource (feed or entry document URI) makes a lot of sense but I think 
there may be some issues there with aggregate feeds and intermediaries 
(e.g. Feedburner) that would need to be worked out. In any case, this is 
definitely something that should be worked up. If there is interest in 
coming up with a ID on the topic, I volunteer to help write it up. The 
question is whether or not this list is the right place to discuss 
extensions like this or whether we should take this offline?

Bob Wyman wrote:

>Paul Hoffman wrote:
>  
>
>>It is much better to say "..having feeds, not people, be
>>associated with keys...". That is, the identifier that is 
>>associated with the key is a URI of the feed, not a person
>>or company name.
>>    
>>
>	You are, of course, correct. My apologies for being sloppy and
>letting the "ownership" concept slip in. The correct concept is an
>association between things, not ownership.
>
>  
>
>>A different method would be to have multiple identities
>>associated with keys. My key might be identified with "Paul 
>>Hoffman" and "http://lookit.proper.com" and
>>http://saladwithsteve.com/osx/" and so on.
>>    
>>
>	This is certainly possible. However, I quite like the idea of
>rooting the hierarchy in an association between keys and a verifiable
>network resource. Presumably, it will be much easier for us to gather
>"reputation" information concerning feeds and having such verifiable
>resources at the root of the hierarchy will make it somewhat harder for
>people to generate spurious keys. 
>
>  
>
>>Much simpler, but completely insecure. :-)... Having said that, 
>>I support the latter more than the former, and believe that >90% of
>>signed feeds that people actually use will follow that model.
>>    
>>
>	I agree. In many ways, the process of getting keys from a small
>number of centralized certificate authorities may be viewed as "more
>correct." However, we have decades of experience with "correct" solutions
>that are simply not used. They are often elegant, but useless... If we're
>ever going to get signatures in wide use, we're going to have to compromise
>a bit and focus on what is practical -- not just what is technically
>superior. An unimplemented solution is *not* superior, in any useful sense,
>to a less elegant but implemented solution that delivers the same result.
>
>		bob wyman
>
>
>
>  
>

---

From: Tim Bray <[email-masked]>
Date: Fri, 27 May 2005 11:48:33 -0700

On May 27, 2005, at 11:23 AM, James M Snell wrote:

> In general, the idea of associating the signing keys with the  
> network resource (feed or entry document URI) makes a lot of sense  
> but I think there may be some issues there with aggregate feeds and  
> intermediaries (e.g. Feedburner) that would need to be worked out.  
> In any case, this is definitely something that should be worked up.  
> If there is interest in coming up with a ID on the topic, I  
> volunteer to help write it up. The question is whether or not this  
> list is the right place to discuss extensions like this or whether  
> we should take this offline?

I think that this list is the perfect place to discuss this stuff,  
the people who care are here.

Also, until we get AtomPubIssuesList cleaned up and the format I-D  
filed, the WG is kind of between tasks, so now is a good time.   -Tim

---

From: "The Purple Streak, Hilarie Orman" <[email-masked]>
Date: Fri, 27 May 2005 12:57:18 -0600

It's silly to require that signatures be validated without some
security model relating that signature to some kind of meaningful
authentication.

Feeds should be able to provide certificates (self-signed or
otherwise) or be required to provide a method to get the cert; the
signature on the data should be checked against that certificate; the
user should be given some visible information about the identity
associated with the certificate used to validate a signature and a
chance to accept or reject the signed data.

Do you intend to require Keyinfo in the Signature element?  Any
requirements on that?

Hilarie Orman

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 27 May 2005 13:02:17 -0700

>Do you intend to require Keyinfo in the Signature element?  Any

In the base format spec, we are simply relying on XMLDigSig. If that 
turns out to be insufficient, we'll certainly add advice about what 
signed feeds and entries should do.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: James M Snell <[email-masked]>
Date: Fri, 27 May 2005 13:30:08 -0700

> filed, the WG is kind of between tasks, so now is a good time.   -Tim
Excellent.

Ok, so given that, continuing on what Paul and Bob have already put forward:

Associating the keys with the feed rather than with the individual is 
goodness.  The issue of how we establish trust of those keys is going to 
be the sticking point (as always). 

 >>    * The much simpler method of the feed including an extension element
 >>that identifies its signing keys -- it could either point to a file 
or to a
 >>key server.
 >Much simpler, but completely insecure. :-) It's a self-signed 
attestation that
 >has to be verified by out-of-band means that, from a security 
standpoint, are
 >equivalent to the first if done right and horribly dangerous if done 
wrong.
 >Having said that, I support the latter more than the former, and believe
 >that >90% of signed feeds that people actually use will follow that 
model.

Agreed that the second approach is better, but both approaches should be 
supported (that is, it should still be possible to use certificates 
issued by a centralized CA).  Can we articulate the right and wrong ways 
of doing the second option?

Other important questions that need hashing out (just throwing these out 
as I think of 'em for discussion)

1. What is being signed?  In a feed document, is it the entire feed, the 
collection of entries as a whole, individual entries, entry metadata, 
etc. and where does the signature go?  
<feed><entry/><signature/></feed>? <feed><entry><signature/></entry></feed>?
2. What is the purpose of the signature?  That is, is it saying "This 
feed/entry really was generated by x" or is it saying "This entry really 
did come from source x".  If the latter, how do we authenticate the 
origin of "source x"?
3. What about aggregate feeds (e.g. feeds produced by intermediaries 
that contains entries from multiple sources, some set of which may have 
already been signed by the source generator).
4. How should intermediaries handle signatures?  For example, what 
should happen if someone asks Feedburner to augment a digitally signed 
feed?  Is FeedBurner a client that is generating a new feed from the 
source original (and therefore may or may not be required to produce a 
new signature) or is FeedBurner modifying the existing feed and required 
to pass along the existing signatures in tact?
5. What are the validation requirements?  How should clients handle 
feeds/entries that don't validate?

- James

---

From: "The Purple Streak, Hilarie Orman" <[email-masked]>
Date: Fri, 27 May 2005 15:07:17 -0600

>  --Internet Mail Consortium

The Key Info is part of the XMLDigSig, but it is not required.  Because
it tells you where and how to obtain the pertinent certificate, it
could be a boon for this particular application.  There is no need
to keep the signer secret, so I'd think it should be required.

It doesn't solve the chain-of-trust problem, though.

Hilarie

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 28 May 2005 14:01:56 -0700

>to keep the signer secret, so I'd think it should be required.

This is the kind of thing we can do in the implementer's guidelines.

>It doesn't solve the chain-of-trust problem, though.

Nothing does :-) . Or is that :-( ?

--Paul Hoffman, Director

---

From: "The Purple Streak, Hilarie Orman" <[email-masked]>
Date: Sat, 28 May 2005 17:48:33 -0600

>  This is the kind of thing we can do in the implementer's guidelines.

It's more like an actual law than a guideline :-) You couldn't
possibly write a compliant implementation for checking signatures
without knowing how to get the certificate that goes with a signed
entry, so it seems to be a fundamental part of the design, not an
implementation guideline.

>  Nothing does :-) . Or is that :-( ?

Yes to both.  Sweet and sour.

But what is the intent of the signature?  It should be to validate that
some entity, having some relationship to the signed entry, declared
that at some time, it was authentic.  How can a checker decide that
the entity has an appropriate relationship?  If the signer doesn't
know this, then the signature might hamper interoperability.

Hilarie