Subject: Signatures in feeds of Aggregated Entry Documents

From: "Bob Wyman" <[email-masked]>
Date: Sat, 8 Jan 2005 23:41:39 -0500

As Robert Sayre recently wrote:

>DSig and XMLEnc are in core.

>http://atompub.org/2004/10/20/draft-ietf-atompub-format-03.html#rfc.section
.7

However, the text says: 

"The document element 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" . "Other elements in an Atom document MUST NOT be signed unless
their definitions explicitly specify such a capability."

The definition of atom:entry does not "explicitly specify" that signatures
can be used on an atom:entry that appears within an Atom Feed Document (i.e.
as a child of atom:feed). This would seem to imply that I cannot compose an
Atom Feed Document by collecting together Atom Entry Documents and wrapping
them in a atom:feed - unless I strip out any signatures that might have been
in the Atom Entry Documents prior to inserting them in the Atom Feed
Document. This is a significant problem for a system like PubSub.com's that
composes feeds by combining entries found in Atom Feed Documents or Atom
Entry Documents. It also prevents the use of Atom Feed Documents as a means
of "logging" a sequence of Atom Entry Documents that may be delivered over
time - perhaps via a mechanism like "Atom over XMPP". Additionally, this
constraint would prevent "search engines" from delivering up unmodified Atom
Entry Documents as elements of result sets that are presented as Atom Feed
Documents. (i.e. the search engine might receive signed atom Entry Documents
but would be forced to remove the signatures if it returns results as an
Atom Feed.)

I can't remember if this has been discussed before. I'm tempted to write a
Pace which would specify that any atom:entry can be signed - whether it is
found in an Atom Feed Document or an Atom Entry Document. Before doing so, I
would appreciate if someone could explain if the constraint in the current
specification is intentional. Why would a signature not be permitted on an
atom:entry found in an Atom Feed Document?

            bob wyman

---

From: Eric Scheid <[email-masked]>
Date: Sun, 09 Jan 2005 21:18:19 +1100

On 9/1/05 3:41 PM, "Bob Wyman" <[email-masked]> wrote:

> This would seem to imply that I cannot compose an
> Document.

if an entry in a feed document are signed, then you will have to strip the
signature if you either insert a head-in-entry element, or inline the
/feed/head/author parts.

and of course you won't be able to insert any extra elements of your own
without breaking the signature.

sidebar: does the signature technology we use for the atom format allow us
to state that certain child elements are not to be included in the signature
algorithm. I'm thinking of something along the lines of the following...

<feed>
    ...
    <entry>
        <content ... />
        <date ... />
        ... <!-- usual atom:entry elements -->
        <Signature ... />
        <annotation by="pubsub.com">
            <!-- stuff which the atom spec says won't be
                 included in the signature calculation -->
        </annotation>
    </entry>
</feed>

e.

---

From: "Bob Wyman" <[email-masked]>
Date: Sun, 9 Jan 2005 13:05:17 -0500

Eric Scheid wrote:
> does the signature technology we use for the atom format allow us
> to state that certain child elements are not to be included in 
> the signature algorithm?
	Yes, the signature specification provides for an XPath filter[1] to
be defined that excludes flagged portions of the data from the signature.
You may remember that we discussed this subject back in September[2] when I
proposed that we require that signatures on Atom Entries should be required
to include the following XPath filter element: 

<XPath Filter="subtract"
    xmlns="http://www.w3.org/2002/06/xmldsig-filter2";>
      .//*[@not-signed]
</XPath>

Items added to entries after they are signed should be given a "not-signed"
attribute. I gave an example of this in PaceHeadInEntry[3] where you will
see "<head not-signed>...</head>" in the example. If all signatures on Atom
entries include the filter above then you could add any content you wanted
without interfering with the signature mechanism. Note: A signature on an
Atom feed should *not* contain the XPath above.

	bob wyman

[1] http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/#sec-XPath
[2] http://www.imc.org/atom-syntax/mail-archive/msg09604.html
http://www.imc.org/atom-syntax/mail-archive/msg09596.html
[3] http://www.intertwingly.net/wiki/pie/PaceHeadInEntry

---

From: Robert Sayre <[email-masked]>
Date: Sun, 09 Jan 2005 18:54:15 -0500

>atom:entry found in an Atom Feed Document?

I don't know if the constraint was intentional. At the time, I just 
wrote down what Mark P. and Paul told me to (PaceDigitalSignatures), but 
I wrote a little command line program with Apache XMLSec today, and it 
wasn't very difficult (I'll publish the source soon).

I looked around a bit today, so the following are the findings of a 
non-expert. MustIgnore should let you put a DSig element anywhere you 
want, but I don't think we can reasonably require an XPath Filter. Xpath 
is not a MUST[0], and not all implementations allow it[1]. Also, the 
DSig people have come up with a new XPath filter that allows greatly 
increased performance[2], and very few implementations support that[3]. 
That leaves us with the possibility of specifying how to sign an entry 
that allows unsigned mangling, but not requiring it. I think there's 
also the question of whether a feed signature includes the DSig elements 
that appear within it.

We can probably strike the following:

"Other elements in an Atom document MUST NOT be signed unless their 
definitions explicitly specify such a capability."

if we gain mustIgnore text (I think this should be uncontroversial).

Robert Sayre

[0] http://www.w3.org/TR/xmldsig-core/#sec-TransformAlg
[1] http://www.w3.org/Signature/2001/04/05-xmldsig-interop.html
[2] http://www.w3.org/TR/xmldsig-filter2/
[3] http://www.w3.org/Signature/2002/05/xmldsig-filter2-interop.html

---

From: Antone Roundy <[email-masked]>
Date: Mon, 10 Jan 2005 09:17:37 -0700

On Saturday, January 8, 2005, at 09:41  PM, Bob Wyman wrote:
> >http://atompub.org/2004/10/20/draft-ietf-atompub-format- 
> 03.html#rfc.section.7
>
> However, the text says:
>
> “The document element 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” … “Other elements in an Atom document MUST NOT be  
> signed unless their definitions explicitly specify such a capability.”
...
> I can’t remember if this has been discussed before. I’m tempted to  
> write a Pace which would specify that any atom:entry can be signed –  
> whether it is found in an Atom Feed Document or an Atom Entry  
> Document. Before doing so, I would appreciate if someone could explain  
> if the constraint in the current specification is intentional. Why  
> would a signature not be permitted on an atom:entry found in an Atom  
> Feed Document?
>
Might this constraint have grown out of  
http://www.imc.org/atom-syntax/mail-archive/msg09550.html - which I  
don't read as meaning what's in the current draft?  Perhaps the  
original intent was to impose the following constraints, and the  
restriction on other elements being signed slipped in inadvertantly:

* Document elements may only be signed using DSig.
* Document elements may only use enveloped signatures (as opposed to  
enveloping, sibling...).
and perhaps:
* If other elements are signed, they must use enveloped signatures,  
unless their definitions explicitly specify a capability to use  
enveloping, etc., signatures.

Thinking about it, I haven't been able to come up with a reason to  
forbid the signing of other elements, and I don't recall discussion of  
such a restriction either.

---

From: Antone Roundy <[email-masked]>
Date: Mon, 10 Jan 2005 09:47:53 -0700

>                  included in the signature calculation -->
This has come up before[1], but I don't think a Pace was ever 
written--a "not-signed" attribute seemed to be preferred early in the 
discussion.  One drawback vs. a "not-signed" attribute is that 
applications would have to be able to recognize that <annotation>'s 
children belong at the level where the annotation element itself lives. 
  The obvious advantage of <annotation> would be that the annotation 
itself could be signed, a la:

<feed>
     ...
     <entry>
         <content ... />
         <date ... />
         ... <!-- usual atom:entry elements -->
         <Signature ... />
         <annotation by="pubsub.com">
             <Signature ... />
             <!-- stuff which the atom spec says won't be
                  included in the signature calculation for the ENTRY -->
         </annotation>
     </entry>
</feed>

<annotation> could also be useful as a means of tracking where 
annotations to an entry came from.  Only the original publisher might 
be allowed to add data outside of an annotation element.  Applications 
merging entries might do so and put everything outside of annotation 
elements, but they could be required to generate a new ID for the 
entry, thus not asserting that it was an instance of one of the source 
entries.

[1] http://www.imc.org/atom-syntax/mail-archive/msg09534.html