Re: More on Atom XML signatures and encryption
Ok, this is fine. I'll back this out of the draft. Bob Wyman wrote: Paul Hoffman wrote: Same as above. Even though it is included-by-reference, the referenced content is still a part of the message. No, it isn't. The reference is part of the message. +1 The signature should only cover the bits that are actually in the element (feed or entry) that is signed. Referenced data may be under different administrative control, may change independently of the signed element, etc. bob wyman
Re: More on Atom XML signatures and encryption
Paul Hoffman wrote: Same as above. Even though it is included-by-reference, the referenced content is still a part of the message. No, it isn't. The reference is part of the message. +1 The signature should only cover the bits that are actually in the element (feed or entry) that is signed. Referenced data may be under different administrative control, may change independently of the signed element, etc. bob wyman
Re: More on Atom XML signatures and encryption
At 11:58 AM -0700 6/30/05, James M Snell wrote: 3. When signing complete Atom documents (atom:feed and top level atom:entry), Inclusive Canonicalization with no pre-c14n normalization is required. There seems to be many more interoperability issues with Inclusive Canonicalization than with Exclusive. What is your reasoning here? Two reasons: a. No need to re-envelope things at the document level There is no reason to do that with Canonical XML. b. Ignorance on my part as to what all the interoperability issues are. Can you elaborate or point me to some relevant discussions? The description of how to pull things down from the outside info is well-defined for Canonical XML, and Canonical XML is required for XMLDigSig, so folks have worked harder on it than Inclusive. 4. The signature should cover the signing key. (e.g. if a x509 cert stored externally from the feed is used, the Signature should reference and cover that x509 cert). Failing to do so opens up a security risk. Please explain the "security risk". I probably disagree with this requirement, but want to hear your risk analysis. This is mostly tied to #2 above and comes from a lesson learned from WS-Security. Specifically section 13.2.4 of http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf "Implementers should be aware of the possibility of a token substitution attack. In any situation where a digital signature is verified by reference to a token provided in the message, which specifies the key, it may be possible for an unscrupulous producer to later claim that a different token, containing the same key, but different information was intended." If we don't verify-by-reference to a key contained elsewhere in the feed (or other location), this no longer becomes an issue. We have no intention of doing HMACs, so I believe that this falls out. I have added words about that in a different message I just sent. 5. When signing individual atom:entry elements within a feed, Exclusive Canonicalization MUST be used. If a separate KeyInfo is used to identify the signing key, it MUST be contained as either a child of the entry or source elements. A source element SHOULD be included in the entry. Why is this different than #3? These entries are subject to re-enveloping in a way that document level elements are not. It is possible to use ex-c14n throughout so that the behavior is consistent. The KeyInfo statement relates to #2 and thus becomes irrelevant. Consistency will probably lead to more interoperability, particularly in an area as tricky as canonicalization. 6. If an entry contains any "enclosure" links, the digital signature SHOULD cover the referenced resources. Enclosure links that are not covered are considered untrusted and pose a potential security risk Fully disagree. We are signing the bits in the document, not the outside. There is "security risk", those items are simply unsigned. I tend to consider enclosures to be part of the document, even if they are included by reference. As a potential consumer of an enclosure I want to know whether or not the referenced enclosure can be trusted. Is it accepted to change the SHOULD to a MAY with a caveat outlining the security risk? You have to define exactly what is covered by the signature. No SHOULDs, no MAYs. So you either have to define exactly how to bring in referenced data (and do you follow links in that data, and links in links...?), or you say "it's just the bits you see here". As another example, how would you sign an entry that points to a page that is known to change all the time because it shows the current date? Or a hit counter? There is no "security risk" if you state exactly what is signed. You should point out that the referenced material can change and is not covered by the signature. 7. If an entry contains a content element that uses @src, the digital signature MUST cover the referenced resource. Fully disagree. Same as above. Even though it is included-by-reference, the referenced content is still a part of the message. No, it isn't. The reference is part of the message. 8. Aggregators and Intermediaries MUST NOT alter/augment the content of digitally signed entry elements. Also disagree, but for a different reason. Aggregators and intermediaries should be free to diddle bits if they strip the signatures that they have broken. Ok, my fault. I wasn't clear. Reword to "Aggregators and Intermediaries MUST NOT alter/augment the content of digitally signed entry elements unless they strip the Signature from the entry" That works for me. You might also consider adding "and they are allowed to add their own signatures in the place of stripped signatures". 9. In addition to serving as a message authenticator, the Signature may be used by implementations to assert that potentially untrustworthy content within a feed can
Re: More on Atom XML signatures and encryption
At 3:16 PM -0600 6/30/05, Antone Roundy wrote:
On Thursday, June 30, 2005, at 12:58 PM, James M Snell wrote:
6. If an entry contains any "enclosure" links, the digital
signature SHOULD cover the referenced resources. Enclosure links
that are not covered are considered untrusted and pose a
potential security risk
Fully disagree. We are signing the bits in the document, not the
outside. There is "security risk", those items are simply unsigned.
I tend to consider enclosures to be part of the document, even if
they are included by reference. As a potential consumer of an
enclosure I want to know whether or not the referenced enclosure
can be trusted. Is it accepted to change the SHOULD to a MAY with
a caveat outlining the security risk?
Perhaps a good approach would be for the signed entry to contain a
separate signature for the enclosure--so the entry's signature would
cover the bits in the enclosure's signature, but not the bits in the
enclosure itself. That way, the signature for the entry could be
verified without having to fetch the enclosure.
Where would that signature go? Did we decide that doesn't
have to be empty? If so, that might be a good place...but then I
don't have any experience with signed XML, so I don't know whether
there would be technical difficulties with putting it in any
particular place.
This is possible. It translates to "I say that the bits gotten from
have a hash of ". If the hash doesn't match, you can't
assume anything about the bits; if it does, the other semantic data
in the message can apply to them ("...and it is a picture of me",
"...and it is a program that will delete your data"...).
--Paul Hoffman, Director
--Internet Mail Consortium
Re: More on Atom XML signatures and encryption
On Thursday, June 30, 2005, at 12:58 PM, James M Snell wrote: 6. If an entry contains any "enclosure" links, the digital signature SHOULD cover the referenced resources. Enclosure links that are not covered are considered untrusted and pose a potential security risk Fully disagree. We are signing the bits in the document, not the outside. There is "security risk", those items are simply unsigned. I tend to consider enclosures to be part of the document, even if they are included by reference. As a potential consumer of an enclosure I want to know whether or not the referenced enclosure can be trusted. Is it accepted to change the SHOULD to a MAY with a caveat outlining the security risk? Perhaps a good approach would be for the signed entry to contain a separate signature for the enclosure--so the entry's signature would cover the bits in the enclosure's signature, but not the bits in the enclosure itself. That way, the signature for the entry could be verified without having to fetch the enclosure. Where would that signature go? Did we decide that doesn't have to be empty? If so, that might be a good place...but then I don't have any experience with signed XML, so I don't know whether there would be technical difficulties with putting it in any particular place.
Re: More on Atom XML signatures and encryption
Paul Hoffman wrote: At 12:47 PM -0700 6/29/05, James M Snell wrote: 1. After going through a bunch of potential XML encryption use cases, it really doesn't seem to make any sense at all to use XML Encryption below the document element level. The I-D will not cover anything about encryption of Atom documents as there are really no special considerations that are specific to Atom. Good. 2. The I-D will allow a KeyInfo element to included as a child of the atom:feed, atom:entry and atom:source elements. These will be used to identify the signing key. (e.g. the KeyInfo in the Signature can reference another KeyInfo contained elsewhere in the Feed). This is OK from a security standpoint, but why have it? Why not always have the signature contain all the validating information? You know, if you had asked me this when I wrote this requirement down in my notes three days ago I would have been able to give you the answer. The fact that I'm staring at my screen trying to recall what that answer is indicates that it's not a very good one ;-) ... You're right, there really is no need to separate the keyinfo from the signature in this situation. 3. When signing complete Atom documents (atom:feed and top level atom:entry), Inclusive Canonicalization with no pre-c14n normalization is required. There seems to be many more interoperability issues with Inclusive Canonicalization than with Exclusive. What is your reasoning here? Two reasons: a. No need to re-envelope things at the document level b. Ignorance on my part as to what all the interoperability issues are. Can you elaborate or point me to some relevant discussions? 4. The signature should cover the signing key. (e.g. if a x509 cert stored externally from the feed is used, the Signature should reference and cover that x509 cert). Failing to do so opens up a security risk. Please explain the "security risk". I probably disagree with this requirement, but want to hear your risk analysis. This is mostly tied to #2 above and comes from a lesson learned from WS-Security. Specifically section 13.2.4 of http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf "Implementers should be aware of the possibility of a token substitution attack. In any situation where a digital signature is verified by reference to a token provided in the message, which specifies the key, it may be possible for an unscrupulous producer to later claim that a different token, containing the same key, but different information was intended." If we don't verify-by-reference to a key contained elsewhere in the feed (or other location), this no longer becomes an issue. 5. When signing individual atom:entry elements within a feed, Exclusive Canonicalization MUST be used. If a separate KeyInfo is used to identify the signing key, it MUST be contained as either a child of the entry or source elements. A source element SHOULD be included in the entry. Why is this different than #3? These entries are subject to re-enveloping in a way that document level elements are not. It is possible to use ex-c14n throughout so that the behavior is consistent. The KeyInfo statement relates to #2 and thus becomes irrelevant. 6. If an entry contains any "enclosure" links, the digital signature SHOULD cover the referenced resources. Enclosure links that are not covered are considered untrusted and pose a potential security risk Fully disagree. We are signing the bits in the document, not the outside. There is "security risk", those items are simply unsigned. I tend to consider enclosures to be part of the document, even if they are included by reference. As a potential consumer of an enclosure I want to know whether or not the referenced enclosure can be trusted. Is it accepted to change the SHOULD to a MAY with a caveat outlining the security risk? 7. If an entry contains a content element that uses @src, the digital signature MUST cover the referenced resource. Fully disagree. Same as above. Even though it is included-by-reference, the referenced content is still a part of the message. 8. Aggregators and Intermediaries MUST NOT alter/augment the content of digitally signed entry elements. Also disagree, but for a different reason. Aggregators and intermediaries should be free to diddle bits if they strip the signatures that they have broken. Ok, my fault. I wasn't clear. Reword to "Aggregators and Intermediaries MUST NOT alter/augment the content of digitally signed entry elements unless they strip the Signature from the entry" 9. In addition to serving as a message authenticator, the Signature may be used by implementations to assert that potentially untrustworthy content within a feed can be trusted (e.g. binary enclosures, scripts, etc) How will you assert that? Not so much a normative assertion. More of a "if you know who produced this feed/e
Re: More on Atom XML signatures and encryption
At 12:47 PM -0700 6/29/05, James M Snell wrote: 1. After going through a bunch of potential XML encryption use cases, it really doesn't seem to make any sense at all to use XML Encryption below the document element level. The I-D will not cover anything about encryption of Atom documents as there are really no special considerations that are specific to Atom. Good. 2. The I-D will allow a KeyInfo element to included as a child of the atom:feed, atom:entry and atom:source elements. These will be used to identify the signing key. (e.g. the KeyInfo in the Signature can reference another KeyInfo contained elsewhere in the Feed). This is OK from a security standpoint, but why have it? Why not always have the signature contain all the validating information? 3. When signing complete Atom documents (atom:feed and top level atom:entry), Inclusive Canonicalization with no pre-c14n normalization is required. There seems to be many more interoperability issues with Inclusive Canonicalization than with Exclusive. What is your reasoning here? 4. The signature should cover the signing key. (e.g. if a x509 cert stored externally from the feed is used, the Signature should reference and cover that x509 cert). Failing to do so opens up a security risk. Please explain the "security risk". I probably disagree with this requirement, but want to hear your risk analysis. 5. When signing individual atom:entry elements within a feed, Exclusive Canonicalization MUST be used. If a separate KeyInfo is used to identify the signing key, it MUST be contained as either a child of the entry or source elements. A source element SHOULD be included in the entry. Why is this different than #3? 6. If an entry contains any "enclosure" links, the digital signature SHOULD cover the referenced resources. Enclosure links that are not covered are considered untrusted and pose a potential security risk Fully disagree. We are signing the bits in the document, not the outside. There is "security risk", those items are simply unsigned. 7. If an entry contains a content element that uses @src, the digital signature MUST cover the referenced resource. Fully disagree. 8. Aggregators and Intermediaries MUST NOT alter/augment the content of digitally signed entry elements. Also disagree, but for a different reason. Aggregators and intermediaries should be free to diddle bits if they strip the signatures that they have broken. 9. In addition to serving as a message authenticator, the Signature may be used by implementations to assert that potentially untrustworthy content within a feed can be trusted (e.g. binary enclosures, scripts, etc) How will you assert that? 10. The I-D will not introduce any new elements or attributes Thank you! 11. Certain types of [X]HTML content will be forbidden in unsigned feeds. e.g. , ,
Re: Annotating signed entries (was Re: More on Atom XML signatures and encryption)
Another possible alternative approach would be to have signed entries include a special container for metadata additions that is expressly not covered by the Signature via a Transform. (the name "annotations" for the tag is just a strawman for discussion purposes) e.g.
Annotating signed entries (was Re: More on Atom XML signatures and encryption)
On Wednesday, June 29, 2005, at 01:47 PM, James M Snell wrote: 8. Aggregators and Intermediaries MUST NOT alter/augment the content of digitally signed entry elements. Just mulling over things... Obviously, we don't have any way to annotate signed entries without breaking the signature. I hesitate to introduce new complexity, so I don't know whether I LIKE the idea I'm about to write about, but here it is. If you want to annotate a signed entry, or even annotate an unsigned one but keep your annotations separate, you might do something like this: [feed metadata] the entry's signature goes here [this annotation could be signed here] ... ... ... foo [entry's signature here if signed] ... Notes: 1) is optional, but recommended if the entry is signed and the annotation is signed. 2) Multiple annotations could point to the same entry 3) It could be requested that aggregators forward annotations along with their entries...but of course, that's optional, and they could certainly be dropped at the request of the end user if they only want to see the originals. 4) It might be recommended or required that elements appear before the entries they annotate (whether above all entries or interspersed with them) to make life easier for processors that finalize their processing of entries as soon as they hit rather than doing it after they've parsed the whole document. 5) Aggregators COULD attach annotations from various sources when outputting entries, even if those annotations never appeared together within a feed before. 6) I don't see any way to choose between conflicting annotations.
Re: More on Atom XML signatures and encryption
Ok, I've been going back through all of the discussion on this thread and use scenarios, etc and should have an I-D ready for this by this weekend. Here's the summary (in no particular order) 1. After going through a bunch of potential XML encryption use cases, it really doesn't seem to make any sense at all to use XML Encryption below the document element level. The I-D will not cover anything about encryption of Atom documents as there are really no special considerations that are specific to Atom. 2. The I-D will allow a KeyInfo element to included as a child of the atom:feed, atom:entry and atom:source elements. These will be used to identify the signing key. (e.g. the KeyInfo in the Signature can reference another KeyInfo contained elsewhere in the Feed). 3. When signing complete Atom documents (atom:feed and top level atom:entry), Inclusive Canonicalization with no pre-c14n normalization is required. 4. The signature should cover the signing key. (e.g. if a x509 cert stored externally from the feed is used, the Signature should reference and cover that x509 cert). Failing to do so opens up a security risk. 5. When signing individual atom:entry elements within a feed, Exclusive Canonicalization MUST be used. If a separate KeyInfo is used to identify the signing key, it MUST be contained as either a child of the entry or source elements. A source element SHOULD be included in the entry. 6. If an entry contains any "enclosure" links, the digital signature SHOULD cover the referenced resources. Enclosure links that are not covered are considered untrusted and pose a potential security risk 7. If an entry contains a content element that uses @src, the digital signature MUST cover the referenced resource. 8. Aggregators and Intermediaries MUST NOT alter/augment the content of digitally signed entry elements. 9. In addition to serving as a message authenticator, the Signature may be used by implementations to assert that potentially untrustworthy content within a feed can be trusted (e.g. binary enclosures, scripts, etc) 10. The I-D will not introduce any new elements or attributes 11. Certain types of [X]HTML content will be forbidden in unsigned feeds. e.g. , ,
Re: More on Atom XML signatures and encryption
On Tue, 2005-06-21 at 17:13 -0700, James M Snell wrote: >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]. > Given this language, the the spec only explicitly allows digital signing > of the Atom Feed and Entry Documents. It does not explicitly allow for > digitally signing individual entries within a Feed document. Makes sense to me James. Which bit of 'only explicitly' don't you grok? -- Regards, Dave Pawson XSLT + Docbook FAQ http://www.dpawson.co.uk
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
Re: More on Atom XML signatures and encryption
Eric Scheid wrote: On 22/6/05 1:39 AM, "Paul Hoffman" <[EMAIL PROTECTED]> wrote: One would also have to contend with the potential problems introduced by namespace declarations with the feed. The bottom line of this is that an entry with a signature could not simply be copied over to a new containing feed element with the signature in tact making the aggregator scenario unworkable. Again, fully disagree. It is quite reasonable to pass along signed entries without changing them. I think the problem is with clashing xmlns prefixes. Consider these two separate feeds containing signed entries: http://example.com/"; ...> [...] [...] foo! http://foo.com/"; ...> [...] [...] foo! The problem is the xmlns prefix "ns1" is used for two different namespaces. Question: is the element itself included in the signature? Yes If not, then we can declare the xmlns:ns1 on the element ... but we'd also need to disallow any extension or foreign attributes on the (and ) elements. I am becoming increasingly convinced that a c14n algorithm is the *only* way to accomplish the goal here. The algorithm would recast the entry being signed as a standalone entity with all appropriate namespace declarations, etc. Validation of a signed entry would require first that the entry is extracted from the feed in accordance with the canonicalization. This will make it possible for us to evaluate the entry without the messy interference that the containing feed element introduces. The only trick now is in coming up with the right algorithm. e.
Re: More on Atom XML signatures and encryption
On 22/6/05 1:39 AM, "Paul Hoffman" <[EMAIL PROTECTED]> wrote: >> One would also have to contend with the potential problems >> introduced by namespace declarations with the feed. The bottom line >> of this is that an entry with a signature could not simply be copied >> over to a new containing feed element with the signature in tact >> making the aggregator scenario unworkable. > > Again, fully disagree. It is quite reasonable to pass along signed > entries without changing them. I think the problem is with clashing xmlns prefixes. Consider these two separate feeds containing signed entries: http://example.com/"; ...> [...] [...] foo! http://foo.com/"; ...> [...] [...] foo! The problem is the xmlns prefix "ns1" is used for two different namespaces. Question: is the element itself included in the signature? If not, then we can declare the xmlns:ns1 on the element ... but we'd also need to disallow any extension or foreign attributes on the (and ) elements. e.
Re: More on Atom XML signatures and encryption
Here's a use-case: I aggregate entries from several sources and create a composite feed. I want entries that were signed in the source feeds to still carry their original signatures in the composite feed, so that parsers can check that the entry has not been modified since it was issued by the original source. A particular instance of this use-case is in education, where learning systems might export entries as part of evidence of learning (for example, posts from a collaborative course blog), which are then aggregated by the learner to create a single view across all their evidence from multiple providers. If this view is then published and used to support a claim (say, of skill competency), its important to be able to tell whether individual entries were modified by the learner after they were obtained from the providers. For this use-case, option 2 must be possible. Scott Wilson http://www.cetis.ac.uk On 21 Jun 2005, at 07:15, James M Snell wrote: OK, thanks to the feedback that has already been offered in this thread I've been able to make progress on the XML Encryption side of this. Now to the digital signature side. I'd like to get some opinions on the following question: The spec already allows enveloped XML signatures for the document. Question: should we only allow signing of the entire document or are there valid use cases for allowing each individual entry in the feed to be individually signed? e.g. or or urn:abc... I'm quite happy with limiting it to the first as I don't really see much of a reason to support the second and third examples, but wanted to see if anyone had any opinions or use cases that could justify the ability to independently sign individual entries within a feed. - James smime.p7s Description: S/MIME cryptographic signature
Re: More on Atom XML signatures and encryption
Paul Hoffman wrote: At 2:15 PM -0700 6/20/05, James M Snell wrote: The spec already allows enveloped XML signatures for the document. Question: should we only allow signing of the entire document or are there valid use cases for allowing each individual entry in the feed to be individually signed? There are many valid use cases for both: that's why the spec explicitly allows both. From the spec (Section 5) 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]. ... Other elements in an Atom Document MUST NOT be signed unless their definitions explicitly specify such a capability. Given this language, the the spec only explicitly allows digital signing of the Atom Feed and Entry Documents. It does not explicitly allow for digitally signing individual entries within a Feed document. In fact, it explicitly forbids it given that the definition of does not "explicitly specify" the capacity to be signed. Is this a bug in the spec or am I reading the spec incorrectly? If the former, then we need to get it resolved, because as it appears to read (to me anyway) we are not allowed to put Signatures within a Feeds entry elements. If the latter, I'll thwack my head on the desk to see if that helps me to start making better sense of what I'm reading. :-) I'm quite happy with limiting it to the first as I don't really see much of a reason to support the second and third examples, but wanted to see if anyone had any opinions or use cases that could justify the ability to independently sign individual entries within a feed. The spec uses MAY for the conformance criteria, so no one has to support either. At 9:17 PM -0700 6/20/05, James M Snell wrote: In other words, if the entry in the first example above were to be included in an aggregate feed containing entries from multiple authors, the element from its containing feed would need to be added to the entry element's collection of metadata... (... becomes .. . ... ) thereby invalidating any signature calculated over the entry. Fully disagree. No one is *forced* to add the collection of metadata to the entry. You give a very good reason why someone would not want to. The only way someone would not be forced to add author or source-w/author to the entry would be if digitally signed entry elements contained within a feed were required to be complete entries capable of standing alone as entry documents and were required to contain source elements as Bob has asserted. If the author and/or source elements are missing from the entry, it would not work in an aggregated feed scenario without adding in those pieces of metadata. The only solution for this (as has been noted in other notes in this thread) is a canonicalization scheme for signed entry elements. One would also have to contend with the potential problems introduced by namespace declarations with the feed. The bottom line of this is that an entry with a signature could not simply be copied over to a new containing feed element with the signature in tact making the aggregator scenario unworkable. Again, fully disagree. It is quite reasonable to pass along signed entries without changing them. Only if such entries are canonicalized in order to remove any problems introduced by namespace declarations. The entry in the example below... http://www.w3.org/1999/xhtml"; xmlns="..."> ... ... Could not simply be reliably passed along unmodified to an aggregate feed that could quite possibly use a different set of namespace declarations. e.g. http://www.w3.org/1999/xhtml";> ... ... Am I missing something fundamental here? So... given all this... I think I'm gong to make an assertion and open that assertion up for debate: The need for an end-to-end trust model for Atom capable of traversing any number of intermediaries is largely a myth. How can we debate that before businesses have had a chance to create their models? What is really needed is a simple mechanism for protecting feeds against spoofed sources (e.g. man-in-the-middle serving up a bogus feed) and for indicating that content is trustworthy* on the document level (as opposed to individual feed entry level). * by which I mean, for example, binary enclosures are trustworthy, the feed itself does not contain any malicious content, etc This is a very different model than what we chose for Atom. It is possibly an interesting idea, but it isn't Atom. ?? I don't understand. What part of my post "isn't Atom"? My comment deals with potential security issues that are specifical
Re: More on Atom XML signatures and encryption
At 2:15 PM -0700 6/20/05, James M Snell wrote: The spec already allows enveloped XML signatures for the document. Question: should we only allow signing of the entire document or are there valid use cases for allowing each individual entry in the feed to be individually signed? There are many valid use cases for both: that's why the spec explicitly allows both. I'm quite happy with limiting it to the first as I don't really see much of a reason to support the second and third examples, but wanted to see if anyone had any opinions or use cases that could justify the ability to independently sign individual entries within a feed. The spec uses MAY for the conformance criteria, so no one has to support either. At 9:17 PM -0700 6/20/05, James M Snell wrote: In other words, if the entry in the first example above were to be included in an aggregate feed containing entries from multiple authors, the element from its containing feed would need to be added to the entry element's collection of metadata... (... becomes .. . ... ) thereby invalidating any signature calculated over the entry. Fully disagree. No one is *forced* to add the collection of metadata to the entry. You give a very good reason why someone would not want to. One would also have to contend with the potential problems introduced by namespace declarations with the feed. The bottom line of this is that an entry with a signature could not simply be copied over to a new containing feed element with the signature in tact making the aggregator scenario unworkable. Again, fully disagree. It is quite reasonable to pass along signed entries without changing them. So... given all this... I think I'm gong to make an assertion and open that assertion up for debate: The need for an end-to-end trust model for Atom capable of traversing any number of intermediaries is largely a myth. How can we debate that before businesses have had a chance to create their models? What is really needed is a simple mechanism for protecting feeds against spoofed sources (e.g. man-in-the-middle serving up a bogus feed) and for indicating that content is trustworthy* on the document level (as opposed to individual feed entry level). * by which I mean, for example, binary enclosures are trustworthy, the feed itself does not contain any malicious content, etc This is a very different model than what we chose for Atom. It is possibly an interesting idea, but it isn't Atom. --Paul Hoffman, Director --Internet Mail Consortium
Re: More on Atom XML signatures and encryption
On Monday, June 20, 2005, at 11:33 PM, James M Snell wrote: OK, so given the arguments I previously posted in my response to Dan + the assertion that digitally signing individual entries will be necessary, the only real possible solution would be to come up with a canonicalization scheme for digitally signed Atom entries. ...or as Bob said, always including a source element in signed entries, even if they're in the origin feed. The following is all academic at this point, but here's "pseudofeed" of what I'd like to have seen...part of it only in retrospect: [feed metadata] [entry metadata and content] [entry metadata and content] ... [etc.] Of course, aggregating this while preserving the signatures' validity would require a different aggregation model than what we've chosen--like what I proposed for aggregation documents. (Indentation added for readability--in practice, that would break the signature, right?): [aggregation metadata] [feed metadata] [entry metadata and content] ... [etc.] [etc.]
Re: More on Atom XML signatures and encryption
James M Snell wrote: the ability to omit the author element from a contained if the containing feed has an author... Signed entries should include a source element and that source element should contain any of the feed level elements that the entry depends on. This is one of the reasons that souce elements exist. The use of source elements drastically simplifies this part of the canonicalization process. bob wyman
Re: More on Atom XML signatures and encryption
OK, so given the arguments I previously posted in my response to Dan + the assertion that digitally signing individual entries will be necessary, the only real possible solution would be to come up with a canonicalization scheme for digitally signed Atom entries. When applied to an entry, the scheme would transform the entry into what is effectively a standalone Atom Entry Document with a source and author elements included and all necessary namespace declarations. For example, given the following: ... ... The canonicalized version of the entry would look something like: ... ... The digital signature would then be calculated over the canonicalized entry. What else would the canonicalization scheme have to do? - James Bob Wyman wrote: James M Snell wrote: Question: should we only allow signing of the entire document or are there valid use cases for allowing each individual entry in the feed to be individually signed? We definitely need to be able to sign each entry. This is necessary so that we can passed signed content in aggregated feeds. The mere act of aggregation should not force a signature to be removed from an item. (Note: Signed entries really *must* include source elements. Otherwise, aggregators will be forced to strip off the signatures in order to insert the source elements.) bob wyman
Re: More on Atom XML signatures and encryption
On Jun 20, 2005, at 11:17 PM, James M Snell wrote: The thought here then is that feeds would not be considered atomic units and that elements can be pulled as is out of a containing element and passed around independently of it. That's basically the idea, yes. That really doesn't seem to square up with some basic XML signature principles and other atom conventions such as the ability to omit the author element from a contained if the containing feed has an author... Which XML-DSig principles does this violate? It seems to me that if you come across a signed node, as long as you don't break the well-formedness of it, you can do what you like with it. As for Atom conventions, such as the omission of key information from an ---yes, this is a complication. One approach would be to make my Atom feeds "disassemblable", such that each entry found in the feed could equally stand on its own as an Atom Entry Document. Then again, this may not be such a big deal. In the case of an aggregator it's an issue, but in the peers-sharing-entries case, it's conceivable that each peer already knows the level metadata and can refer to it when necessary. (Perhaps the peers periodically---but rarely!---poll the conventional Atom feed, or perhaps they exchange the entire contents among themselves if it too has been signed by the original publisher.) So the question with regards to enabling aggregation services is whether or not those services could even exist without performing a level of processing against the feed and entries that would necessarily break the digital signature. In other words, if the entry in the first example above were to be included in an aggregate feed containing entries from multiple authors, the element from its containing feed would need to be added to the entry element's collection of metadata... (... becomes .. . ... ) thereby invalidating any signature calculated over the entry. I agree that destructively processing the entries is almost certain to cause trouble (and relates directly to your canonicalization argument below). This might not be such a big deal; aggregators might simply pass along what users can verify as authentic, placing the pressure on original Atom content producers (i.e. publishers and their software) to create "self-sufficient" entries. One would also have to contend with the potential problems introduced by namespace declarations with the feed. The bottom line of this is that an entry with a signature could not simply be copied over to a new containing feed element with the signature in tact making the aggregator scenario unworkable. Ugh. I don't have an answer for the namespaces problem. (XML isn't doing me any favors here. Or perhaps the reverse is more true?) I suppose that in my mind, an Atom feed is mostly a vector (pun intended) for carrying Atom entries. After all, the entries are what the user (or end processor, or what have you) is really interested in! They are stable, mostly-unchanging, "atomic" (!) bits of data that can be exchanged and stored and reasoned about. On the other hand, the feed is always changing, even if most of its data remains the same; as a sliding window of Atom "events", it's a moving target, almost entirely uninteresting in itself from the perspective of processing applications. Digital signatures just bring this point to the fore. Which brings me to the following heresy: Wouldn't it be nice if an Atom feed were just a list of self-contained Atom Entry Documents? Yes, some data will be duplicated between items, but there's a tremendous flexibility benefit, to my mind. Entries are now much more loosely coupled to one another, and can survive on their own in any context, for any purpose. (The reason I think that this is a *useful* flexibility is that when I look at current applications of newsfeeds, I see a strong focus on entries. Popular newsreaders spend the bulk of their UI energy on listing and presenting entries, because that's where the user's focus is. The "objects" in the system, from the user's perspective, are the entries. The feed is just the box they came in. How long before newsreaders allow users to clip and save their favorite entries, individually, in a *different* box---like saving email messages to a folder? Even this simple operation is made difficult by binding entries tightly to their feeds. But I digress.) The only potential way around this problem would be to define a standard canonicalization mechanism for Atom entries that would make it possible to reliably sign and verify them across multiple feeds. I agree that canonicalization would also solve this. (Just to be sure we're on the same page: XML Canonicalization is woefully insufficient for this domain-specific task.) You might view the concept of an Atom Entry Document as a start in this direction. Unless such a canonicalization mechanism is defined,
Re: More on Atom XML signatures and encryption
James M Snell wrote: Question: should we only allow signing of the entire document or are there valid use cases for allowing each individual entry in the feed to be individually signed? We definitely need to be able to sign each entry. This is necessary so that we can passed signed content in aggregated feeds. The mere act of aggregation should not force a signature to be removed from an item. (Note: Signed entries really *must* include source elements. Otherwise, aggregators will be forced to strip off the signatures in order to insert the source elements.) bob wyman
Re: More on Atom XML signatures and encryption
Dan Sandler wrote: On Jun 20, 2005, at 4:15 PM, James M Snell wrote: Question: should we only allow signing of the entire document or are there valid use cases for allowing each individual entry in the feed to be individually signed? I believe that individually signed entries are essential for a couple of Atom usage contexts: (1) aggregation services, e.g. third parties which combine or filter portions of feeds (2) redistribution applications, e.g. clients which share portions of feeds with one another The common thread here is that these scenarios represent third parties interposed between publisher and user. [In category (1) the third party is the aggregator; in category (2) the third party is "some other client". This is a continuous design space, of course, but let's stick with these two simple scenarios.] When a third party is involved, signatures are required to verify that the information received by the user has not been altered since the publisher released it. If Atom data may only be signed at the level, the granularity at which these third parties may slice and dice content is constrained to that level also. The seems to me to be more generally useful as, well, an "atomic" signature unit for these applications. Without individually signed entries, it would be impossible, for example, to implement the most basic category (1) service: an aggregator which can be *trusted* to combine two Atom feeds into one. With signed entries, a client could be sure that each entry found in the aggregation is authentic, despite having received the entries from a potentially untrustworthy entity. If this seems a bit far-fetched because there are currently few examples of these Atom intermediaries, just wait; aggregators are the new clipping services, and I suspect we'll see more of them in the future. (Just as with traditional clipping services, people may even pay money for this valuable service, which is a Good Thing for technology that enables it.) And as for (2), I'm working on it :) The thought here then is that feeds would not be considered atomic units and that elements can be pulled as is out of a containing element and passed around independently of it. That really doesn't seem to square up with some basic XML signature principles and other atom conventions such as the ability to omit the author element from a contained if the containing feed has an author... for example: ... ... ... as oppose to ... ... In the first case, the is entirely dependent on the containing feed for specifying a critical and required piece of metadata making it impossible to separate from the feed without first processing it. So the question with regards to enabling aggregation services is whether or not those services could even exist without performing a level of processing against the feed and entries that would necessarily break the digital signature. In other words, if the entry in the first example above were to be included in an aggregate feed containing entries from multiple authors, the element from its containing feed would need to be added to the entry element's collection of metadata... (... becomes .. . ... ) thereby invalidating any signature calculated over the entry. One would also have to contend with the potential problems introduced by namespace declarations with the feed. The bottom line of this is that an entry with a signature could not simply be copied over to a new containing feed element with the signature in tact making the aggregator scenario unworkable. e.g. Feed 1: ... urn:123 ... Feed 2: ... urn:abc ... Perfectly Legal Synthesized Aggregated Feed urn:123 ... urn:abc ... The only potential way around this problem would be to define a standard canonicalization mechanism for Atom entries that would make it possible to reliably sign and verify them across multiple feeds. While plausible, that approach gets rather complicated and is only justified if a) there is enough of a use case justification and b) there's not an easier way. Unless such a canonicalization mechanism is defined, it would appear as if there would be no way of ensuring that the individual entries within a synthesized aggregate feed are indeed "authentic" unless a) they contained a self-referential pointer back to a digitally signed version of itself, b) the synthesized feed in which it was contained is digitally signed by a trusted entity and c) the version of the entry contained in the synthesized feed is identical to its digitally signed reference copy. but even this is obviously imperfect. Digitally signed original @ http://myblog.com/entries/1 urn:123
Re: More on Atom XML signatures and encryption
On Jun 20, 2005, at 4:15 PM, James M Snell wrote: Question: should we only allow signing of the entire document or are there valid use cases for allowing each individual entry in the feed to be individually signed? I believe that individually signed entries are essential for a couple of Atom usage contexts: (1) aggregation services, e.g. third parties which combine or filter portions of feeds (2) redistribution applications, e.g. clients which share portions of feeds with one another The common thread here is that these scenarios represent third parties interposed between publisher and user. [In category (1) the third party is the aggregator; in category (2) the third party is "some other client". This is a continuous design space, of course, but let's stick with these two simple scenarios.] When a third party is involved, signatures are required to verify that the information received by the user has not been altered since the publisher released it. If Atom data may only be signed at the level, the granularity at which these third parties may slice and dice content is constrained to that level also. The seems to me to be more generally useful as, well, an "atomic" signature unit for these applications. Without individually signed entries, it would be impossible, for example, to implement the most basic category (1) service: an aggregator which can be *trusted* to combine two Atom feeds into one. With signed entries, a client could be sure that each entry found in the aggregation is authentic, despite having received the entries from a potentially untrustworthy entity. If this seems a bit far-fetched because there are currently few examples of these Atom intermediaries, just wait; aggregators are the new clipping services, and I suspect we'll see more of them in the future. (Just as with traditional clipping services, people may even pay money for this valuable service, which is a Good Thing for technology that enables it.) And as for (2), I'm working on it :) ---dan http://www.cs.rice.edu/~dsandler/
Re: More on Atom XML signatures and encryption
OK, thanks to the feedback that has already been offered in this thread I've been able to make progress on the XML Encryption side of this. Now to the digital signature side. I'd like to get some opinions on the following question: The spec already allows enveloped XML signatures for the document. Question: should we only allow signing of the entire document or are there valid use cases for allowing each individual entry in the feed to be individually signed? e.g. or or urn:abc... I'm quite happy with limiting it to the first as I don't really see much of a reason to support the second and third examples, but wanted to see if anyone had any opinions or use cases that could justify the ability to independently sign individual entries within a feed. - James
Re: More on Atom XML signatures and encryption
The plus side to the third option is that it is really no different than an Atom feed that uses content payloads of any other arbitrary XML media type (section 4.1.3.3 item #4). The current spec is silent on what an Atom implementer needs to do with content media types that they don't understand. Paul Hoffman wrote: At 2:25 PM -0700 6/16/05, James M Snell wrote: So perhaps we should limit XML encryption to a) The entire feed b) individual entries and c) the content of content elements. (examples 2, 4 and 5 in my original note). Or less. Sections 5.1 and 5.2 of the current spec clearly only cover 1 and 2. Going beneath that is outside the spec, and likely to be ignored by implementers. --Paul Hoffman, Director --Internet Mail Consortium
Re: More on Atom XML signatures and encryption
At 2:25 PM -0700 6/16/05, James M Snell wrote: So perhaps we should limit XML encryption to a) The entire feed b) individual entries and c) the content of content elements. (examples 2, 4 and 5 in my original note). Or less. Sections 5.1 and 5.2 of the current spec clearly only cover 1 and 2. Going beneath that is outside the spec, and likely to be ignored by implementers. --Paul Hoffman, Director --Internet Mail Consortium
Re: More on Atom XML signatures and encryption
I didn't see any requirement to encrypt feeds. Please note my email re keyinfo and identification of signer from a few weeks ago. Hilarie Orman
Re: More on Atom XML signatures and encryption
Bill de hÓra wrote: James M Snell wrote: Thoughts? The mot straightforward way (imo) to deal with encoded fragments is to use two attributes, ie @type and @enc. So defining a new extension attribute would work for me. See my comments below on the type identification. Here's another challenge... what about Text constructs like summary that only allow html, text and xhtml values for their type attribute. It would apear that we cannot embed an EncryptedData element in Text constructs. I dunno, is this a problem? Outside , I really don't think we should be encouraging folks to encrypt individual metadata elements as that could get rather silly. So perhaps we should limit XML encryption to a) The entire feed b) individual entries and c) the content of content elements. (examples 2, 4 and 5 in my original note). I'm not sure you need to deal with signalling the type of a fully encrypted document in your case 5; if it's not possible to signal the type via xmlenc I'd claim it's a spec bug there, not here. You know... it really would help if I *re-read* the relevant specs before opening my mouth ;-) The EncryptedData element already has attributes for specifying the original type of the encrypted data. Now I just feel silly. Example 1: This is some text Becomes http://www.w3.org/2001/04/xmlenc#Content MimeType="text/plain">... Example 2:This is some HTML
Becomes http://www.w3.org/2001/04/xmlenc#Content"; MimeType="text/html">... (note to self: read the damn spec next time ;-) ) cheers Bill - James
Re: More on Atom XML signatures and encryption
James M Snell wrote: Thoughts? The mot straightforward way (imo) to deal with encoded fragments is to use two attributes, ie @type and @enc. So defining a new extension attribute would work for me. I'm not sure you need to deal with signalling the type of a fully encrypted document in your case 5; if it's not possible to signal the type via xmlenc I'd claim it's a spec bug there, not here. cheers Bill
