Re: [Fwd: Re: Signatures - I blog, therefore I am...]
On Sat, 28 May 2005 at 14:01:56 -0700 Paul Hoffman opined: > At 3:07 PM -0600 5/27/05, The Purple Streak, Hilarie Orman wrote: > >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. > 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. > >It doesn't solve the chain-of-trust problem, though. > 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
Re: [Fwd: Re: Signatures - I blog, therefore I am...]
At 3:07 PM -0600 5/27/05, The Purple Streak, Hilarie Orman wrote: 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. 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 --Internet Mail Consortium
Re: [Fwd: Re: Signatures - I blog, therefore I am...]
On Fri, 27 May 2005 at 13:02:17 -0700 Paul Hoffman spoke thusly: > At 12:57 PM -0600 5/27/05, The Purple Streak, Hilarie Orman wrote: > >Do you intend to require Keyinfo in the Signature element? Any > >requirements on that? > 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 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
Re: [Fwd: Re: Signatures - I blog, therefore I am...]
Tim Bray wrote: 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 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? ? ? 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
Re: [Fwd: Re: Signatures - I blog, therefore I am...]
At 12:57 PM -0600 5/27/05, The Purple Streak, Hilarie Orman wrote: Do you intend to require Keyinfo in the Signature element? Any requirements on that? 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
Re: [Fwd: Re: Signatures - I blog, therefore I am...]
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
Re: [Fwd: Re: Signatures - I blog, therefore I am...]
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
[Fwd: Re: Signatures - I blog, therefore I am...]
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
