Re: Signature wording
Tim Bray wrote: On Jun 22, 2005, at 12:03 PM, James M Snell wrote: I'm planning to write a separate Internet-Draft that discusses digital signing of Atom feeds and entries. Some parts of that document will includes mandates; other parts will include recommendations. We can describe for entry producers a way of producing signed entries that can be aggregated with original signatures in tact and a set of recommendations to aggregators that wish to pass those signed entries around with signatures in tact. Sure, it's all up to the aggregators and content providers to decide whether or not they want to support those methods -- which is the whole point of I'm working on this as a separate I-D and positioning it as an optional extension to Atom. :-) A man who spots a problem, then volunteers to do the work around fixing it! We need more like that. I suspect that there's an excellent chance that this might become a WG draft, but I remained concerned about our lack of hands-on experience. -Tim The lack of hands on experience is a big issue. What I'd like to see is a) I/we draft the I-D describing the details, b) get some aggregator folks (Bob?) to implement a prototype based on it, c) start iterating the I-D and implementations accordingly. If we can get some committment from the aggregator folks to start doing some implementation work, our job is going to become much easier.
Re: Signature wording
On Jun 22, 2005, at 12:03 PM, James M Snell wrote: I'm planning to write a separate Internet-Draft that discusses digital signing of Atom feeds and entries. Some parts of that document will includes mandates; other parts will include recommendations. We can describe for entry producers a way of producing signed entries that can be aggregated with original signatures in tact and a set of recommendations to aggregators that wish to pass those signed entries around with signatures in tact. Sure, it's all up to the aggregators and content providers to decide whether or not they want to support those methods -- which is the whole point of I'm working on this as a separate I-D and positioning it as an optional extension to Atom. :-) A man who spots a problem, then volunteers to do the work around fixing it! We need more like that. I suspect that there's an excellent chance that this might become a WG draft, but I remained concerned about our lack of hands-on experience. -Tim
Re: Signature wording
On Jun 22, 2005, at 11:55 AM, James M Snell wrote: Note that I am not trying to change Atom's model or the core spec, We do agree on Paul's suggested changed saying "it's OK to sign entries" though, I think. I am trying to define an Atom extension that is capable of meeting a specific problem space that happens to include the types of things aggregators are going to want to be able to do. I think this is a good idea. I'd be pretty strongly against us trying to write some sort of c14n language into the format spec because we have little prior art to draw on with respect to XML DigSig in general, and exactly zero (as far as I know) to draw on for digsig in a feed or aggregated-feed context. So we just totally don't know how this is going to shake down in the market. So I agree. Remove the prohibition on signing entries, and let the engineers figure out what works. -Tim
Re: Signature wording
Paul Hoffman wrote: At 11:49 AM -0600 6/22/05, Antone Roundy wrote: I take it, Paul, that you're suggesting that we punt on ensuring that entries can be aggregated without breaking signatures. Exactly right. In the core Atom spec, absolutely. If so, we might consider suggesting some guidelines for maximizing the probability of a signature remaining valid, such as including a element in each signed , using the most commonly used namespace prefixes for any namespaces used in the entry, and using UTF-8 (or whatever is most common for the language the feed is published in). Someone might want to work on a document that advises (not mandates) a way to canonicalize the heck out of an entry to reduce the likelihood that an aggregator would want to change any bits in the entry, regardless of whether or not the entry is signed. We cannot tell aggregators that they cannot change bits in an signed entry: they might choose to do so even though it would break the signature because the bits they are changing are more important than the signature. For example, the aggregator may know the end recipient can't validate the signature anyway, or the aggregator may know that the signature was broken before they got the entry. I'm planning to write a separate Internet-Draft that discusses digital signing of Atom feeds and entries. Some parts of that document will includes mandates; other parts will include recommendations. We can describe for entry producers a way of producing signed entries that can be aggregated with original signatures in tact and a set of recommendations to aggregators that wish to pass those signed entries around with signatures in tact. Sure, it's all up to the aggregators and content providers to decide whether or not they want to support those methods -- which is the whole point of I'm working on this as a separate I-D and positioning it as an optional extension to Atom. :-) Such a document would probably be useful, or it might just be a useful entry in the implementer's guide. Getting input from some currently-active aggregators would be really useful for that, of course. --Paul Hoffman, Director --Internet Mail Consortium - James
Re: Signature wording
Paul Hoffman wrote: At 10:32 AM -0700 6/22/05, James M Snell wrote: Paul Hoffman wrote: 2) What you are signing is just the set of bits in the entry, or just the set of bits in the feed, with no interpretation of them. No pre-canonicalization is needed, and none is to be expected by the validating party. I truly don't believe that any change is needed to the format document to reflect this. There is nothing in section 5 that the signature is over the "bits plus everything relevant at the time of the signature". Bear in mind that because of the compulsory presence of and in every entry, some of the benefits of canonicalization (reducing ambiguity in comparisons) are not material. Hmm... not sure about this one. We've already demonstrated via several examples that things like XML namespaces and the lack of a source element can cause problems in aggregator scenarios and that some form of atom-specific canonicalization may be required. I don't feel like you have demonstrated that. You have demonstrated that an aggregator might need to change some signed entries when they aggregate: that will inherently break the signature, and the aggregator will need to sign the entry themselves. But that's part of the aggregator's business model, not the Atom model. "We found this entry, we cleaned it up so you can use it, and we sign this set of bits so you know it is exactly what we emitted". If they want, they can also include the signed-and-unchanged original. Ok, I think this clears up the disconnect a bit. What I'm shooting for is a way of allowing aggregators to pass entries along as is without breaking the original signature -- something that you do not seem to think is important (correct?). The demonstrations I've provided to this point have shown that an aggregator would almost certainly have to break the signature even if it is not adding any value or peforming any processing on the entry, which obviously misses the mark a bit. Three models: 1. Subscriber directly accesses a digitally signed source feed. 2. Subscriber receives entries via an aggregator that modifies entries, breaking any signatures that exist, potentially re-signs the entries 3. Subscriber receives entries via an aggregator that does not modify entries, aggregator wishes to pass those along in a way that does not break any of the original signatures 1 and 2 are easy. They really don't require a lot of discussion. #3 is where the problem appears to exists. The only reason I've seen thus far to digitally sign individual entries within a feed is to enable aggregation scenarios so it really doesn't seem to make a lot of sense if the solution requires aggregators to break signatures within entries in order to aggregate those entries. If breaking the signature is required, might as well just sign the source feed document and skip signing the entries at all. So your change in #1 would be unnecessary Note that I am not trying to change Atom's model or the core spec, I am trying to define an Atom extension that is capable of meeting a specific problem space that happens to include the types of things aggregators are going to want to be able to do. I just don't want Atom to get in the way like it does now with not allowing Signatures on child elements. Adding any kind of language that precludes the ability to accomplish #3 unnecessarily gets in the way of the solution. I'm not sure if the second item in your original note is suggesting that such language be added ??? Can you expand a bit on your assertion with a few examples? Some angle brackets would really help me understand exactly where you're coming from. But that's exactly the point: no angle brackets are needed to understand "the set of bits in the entry". The signature is over the exact characters being signed, not some understanding of them based on namespaces, source elements, and so on. That's the difference between "bits" and "bits plus everything relevant at the time of the signature". An example would be necessary to show how to accomplish #3 ONLY IF you agreed that providing an aggregators ability to pass along an entry unmodified with the original signature in tact was an important thing to do, which does not appear to be the case (please correct me if I'm wrong) --Paul Hoffman, Director --Internet Mail Consortium - James
Re: Signature wording
At 11:49 AM -0600 6/22/05, Antone Roundy wrote: I take it, Paul, that you're suggesting that we punt on ensuring that entries can be aggregated without breaking signatures. Exactly right. If so, we might consider suggesting some guidelines for maximizing the probability of a signature remaining valid, such as including a element in each signed , using the most commonly used namespace prefixes for any namespaces used in the entry, and using UTF-8 (or whatever is most common for the language the feed is published in). Someone might want to work on a document that advises (not mandates) a way to canonicalize the heck out of an entry to reduce the likelihood that an aggregator would want to change any bits in the entry, regardless of whether or not the entry is signed. We cannot tell aggregators that they cannot change bits in an signed entry: they might choose to do so even though it would break the signature because the bits they are changing are more important than the signature. For example, the aggregator may know the end recipient can't validate the signature anyway, or the aggregator may know that the signature was broken before they got the entry. Such a document would probably be useful, or it might just be a useful entry in the implementer's guide. Getting input from some currently-active aggregators would be really useful for that, of course. --Paul Hoffman, Director --Internet Mail Consortium
Re: Signature wording
At 10:32 AM -0700 6/22/05, James M Snell wrote: Paul Hoffman wrote: 2) What you are signing is just the set of bits in the entry, or just the set of bits in the feed, with no interpretation of them. No pre-canonicalization is needed, and none is to be expected by the validating party. I truly don't believe that any change is needed to the format document to reflect this. There is nothing in section 5 that the signature is over the "bits plus everything relevant at the time of the signature". Bear in mind that because of the compulsory presence of and in every entry, some of the benefits of canonicalization (reducing ambiguity in comparisons) are not material. Hmm... not sure about this one. We've already demonstrated via several examples that things like XML namespaces and the lack of a source element can cause problems in aggregator scenarios and that some form of atom-specific canonicalization may be required. I don't feel like you have demonstrated that. You have demonstrated that an aggregator might need to change some signed entries when they aggregate: that will inherently break the signature, and the aggregator will need to sign the entry themselves. But that's part of the aggregator's business model, not the Atom model. "We found this entry, we cleaned it up so you can use it, and we sign this set of bits so you know it is exactly what we emitted". If they want, they can also include the signed-and-unchanged original. Can you expand a bit on your assertion with a few examples? Some angle brackets would really help me understand exactly where you're coming from. But that's exactly the point: no angle brackets are needed to understand "the set of bits in the entry". The signature is over the exact characters being signed, not some understanding of them based on namespaces, source elements, and so on. That's the difference between "bits" and "bits plus everything relevant at the time of the signature". --Paul Hoffman, Director --Internet Mail Consortium
Re: Signature wording
On Wednesday, June 22, 2005, at 11:32 AM, James M Snell wrote: Paul Hoffman wrote: 2) What you are signing is just the set of bits in the entry, or just the set of bits in the feed, with no interpretation of them. No pre-canonicalization is needed, and none is to be expected by the validating party. Hmm... not sure about this one. We've already demonstrated via several examples that things like XML namespaces and the lack of a source element can cause problems in aggregator scenarios and that some form of atom-specific canonicalization may be required. Can you expand a bit on your assertion with a few examples? Some angle brackets would really help me understand exactly where you're coming from. I take it, Paul, that you're suggesting that we punt on ensuring that entries can be aggregated without breaking signatures. If so, we might consider suggesting some guidelines for maximizing the probability of a signature remaining valid, such as including a element in each signed , using the most commonly used namespace prefixes for any namespaces used in the entry, and using UTF-8 (or whatever is most common for the language the feed is published in).
Re: Signature wording
Paul Hoffman wrote: Greetings again. The recent thread on digital signatures has shown a few areas that need to be clarified. I propose the following and ask for discussion. That is, I am *not* stating this is consensus, although it would be grand if it was. 1) We made a mistake, and we really meant to allow signing of stand-alone feeds, stand-alone entries, *and* entries in feeds. Proposed change: Current: The root of an Atom document (i.e., atom:feed in an Atom Feed Document, atom:entry in an Atom Entry Document) MAY have an Enveloped Signature, as described by XML-Signature and Syntax Processing [W3C.REC-xmldsig-core-20020212]. New: The root of an Atom document (i.e., atom:feed in an Atom Feed Document, atom:entry in an Atom Entry Document), or any atom:entry element, MAY have an Enveloped Signature, as described by XML-Signature and Syntax Processing [W3C.REC-xmldsig-core-20020212]. +1 2) What you are signing is just the set of bits in the entry, or just the set of bits in the feed, with no interpretation of them. No pre-canonicalization is needed, and none is to be expected by the validating party. I truly don't believe that any change is needed to the format document to reflect this. There is nothing in section 5 that the signature is over the "bits plus everything relevant at the time of the signature". Bear in mind that because of the compulsory presence of and in every entry, some of the benefits of canonicalization (reducing ambiguity in comparisons) are not material. Hmm... not sure about this one. We've already demonstrated via several examples that things like XML namespaces and the lack of a source element can cause problems in aggregator scenarios and that some form of atom-specific canonicalization may be required. Can you expand a bit on your assertion with a few examples? Some angle brackets would really help me understand exactly where you're coming from. - James
Signature wording
Greetings again. The recent thread on digital signatures has shown a few areas that need to be clarified. I propose the following and ask for discussion. That is, I am *not* stating this is consensus, although it would be grand if it was. 1) We made a mistake, and we really meant to allow signing of stand-alone feeds, stand-alone entries, *and* entries in feeds. Proposed change: Current: The root of an Atom document (i.e., atom:feed in an Atom Feed Document, atom:entry in an Atom Entry Document) MAY have an Enveloped Signature, as described by XML-Signature and Syntax Processing [W3C.REC-xmldsig-core-20020212]. New: The root of an Atom document (i.e., atom:feed in an Atom Feed Document, atom:entry in an Atom Entry Document), or any atom:entry element, MAY have an Enveloped Signature, as described by XML-Signature and Syntax Processing [W3C.REC-xmldsig-core-20020212]. 2) What you are signing is just the set of bits in the entry, or just the set of bits in the feed, with no interpretation of them. No pre-canonicalization is needed, and none is to be expected by the validating party. I truly don't believe that any change is needed to the format document to reflect this. There is nothing in section 5 that the signature is over the "bits plus everything relevant at the time of the signature". Bear in mind that because of the compulsory presence of and in every entry, some of the benefits of canonicalization (reducing ambiguity in comparisons) are not material. --Paul Hoffman, Director --Internet Mail Consortium
Re: More on Atom XML signatures and encryption
Bob Wyman wrote: James M Snell wrote: I am becoming increasingly convinced that a c14n algorithm is the *only* way to accomplish the goal here. The need for C14N should never have been questioned. Where there are signatures, there *must* be C14N (Canonicalization). In the absence of explicitly defined C14N rules, the C14N algorithm is simply: "Leave it as it is!" -- but that is rarely useful and is certainly not useful in the case of Atom. The only interesting question is "What is the C14N process for Atom?" The question: "Is C14N required?" is rhetorical at best. The answer is "Yes." Well, yeah, obviously ;-) I was never questioning the need for c14n, I was trying to figure out if some Atom specific c14n process is required. Sorry if I wasn't being clear; it was based on the assumption that we all already knew that some form of c14n was going to be necessary no matter what. The algorithm would recast the entry being signed as a standalone entity with all appropriate namespace declarations, etc. Precisely. It is also exceptionally important to ensure that a source element be included in any signed entry in order to ensure that the signed entry can be copied to other feeds without breaking the signature or changing the semantics of the entry by allowing feed metadata from the non-source feed to "bleed" into the entry. Right. So what else is it going to need to do? Given that I typically do not use any online aggregation services I'm not sure if it is typical for such aggregators to insert metadata into the entries they serve up? bob wyman
RE: More on Atom XML signatures and encryption
James M Snell wrote: > I am becoming increasingly convinced that a c14n algorithm is > the *only* way to accomplish the goal here. The need for C14N should never have been questioned. Where there are signatures, there *must* be C14N (Canonicalization). In the absence of explicitly defined C14N rules, the C14N algorithm is simply: "Leave it as it is!" -- but that is rarely useful and is certainly not useful in the case of Atom. The only interesting question is "What is the C14N process for Atom?" The question: "Is C14N required?" is rhetorical at best. The answer is "Yes." > The algorithm would recast the entry being signed as a standalone entity > with all appropriate namespace declarations, etc. Precisely. It is also exceptionally important to ensure that a source element be included in any signed entry in order to ensure that the signed entry can be copied to other feeds without breaking the signature or changing the semantics of the entry by allowing feed metadata from the non-source feed to "bleed" into the entry. bob wyman
