Subject: feed or entry

From: Dave Pawson <[email-masked]>
Date: Thu, 16 Jun 2005 18:44:18 +0100

I'm not having much luck working
out how I can write (daily or there abouts)
an entry, without having to duplicate
feed metadata.

Am I alone in this?

Xinsert isn't common yet.. is it?

-- 
Regards, 

Dave Pawson
XSLT + Docbook FAQ
http://www.dpawson.co.uk
http://www.dpawson.co.uk/blog/

---

From: James M Snell <[email-masked]>
Date: Thu, 16 Jun 2005 11:57:05 -0700

I am preparing to write up some thoughts on an initial I-D for XML 
Digital Signatures and Encryption in Atom and wanted to get some initial 
thoughts from the group on a few syntax issues starting first with some 
encryption thoughts:

Below are a few snippets of feeds with different encryptions each with 
their own distinct issues.

1. No encryption  (potentially encrypted in transport using SSL/TLS)
  <feed>
    <entry>
      <content type="text">this is some content</content>
    </entry>
  </feed>

2. Text content of #1 is encrypted.
  <feed>
    <entry>
      <content type="???">
        <EncryptedData xmlns="http://www.w3.org/2001/04/xmlenc#"
                       type="http://www.w3.org/2001/04/xmlenc#Content">
          <CipherData>
            <CipherValue><!-- cipher of "this is some content" 
--></CipherValue>
          </CipherData>
        </EncryptedData>
      </content>
    </entry>
  </feed>

  What should the value of the type attribute be in this case?  A strict 
reading of the Atom spec would dictate a value of "xml", but doing so 
would cause us to lose the content type of the unencrypted content.  A 
simple solution would be to introduce a new extension attribute on the 
content element that captures the type of the unencrypted content.

    e.g. <content type="xml" enc:type="text"><EncryptedData 
...>...</EncryptedData></content>

3. Content metadata element is encrypted 
  <feed>
    <entry>
        <EncryptedData xmlns="http://www.w3.org/2001/04/xmlenc#"
                       type="http://www.w3.org/2001/04/xmlenc#Element">
          <CipherData>
            <CipherValue><!-- cipher of "<content type="text">this is 
some content</content>" --></CipherValue>
          </CipherData>
        </EncryptedData>
    </entry>
  </feed>

  In this case, the metadata elements themselves are encrypted opening 
the obvious issue that all of the encrypted elements need to be 
decrypted in order to perform the processing of the Atom elements.  In 
other words, you wouldn't be able to validate that an entry is 
conformant until you decrypted everything.

4. Entry element is encrypted
  <feed>
         <EncryptedData xmlns="http://www.w3.org/2001/04/xmlenc#"
                       type="http://www.w3.org/2001/04/xmlenc#Element">
          <CipherData>
            <CipherValue><!-- cipher of "<entry>...</entry>" 
--></CipherValue>
          </CipherData>
        </EncryptedData>
  </feed>
 
  Same basic issue as #3 only not so bad. 

5. Entire feed is encrypted
  <EncryptedData xmlns="http://www.w3.org/2001/04/xmlenc#"
                   type="http://www.w3.org/2001/04/xmlenc#Element">
       <CipherData>
         <CipherValue><!-- cipher of "<feed>...</feed>" --></CipherValue>
       </CipherData>
   </EncryptedData>

   Simple and too the point.  The only challenge is how we identify this 
as being an encrypted Atom feed.  It does not conform to the rules of 
the application/atom+xml media type.  Perhaps a new 
application/atomenc+xml media type could be used or is there a better way?

Thoughts?

- James

---

From: James Cerra <[email-masked]>
Date: Thu, 16 Jun 2005 12:09:06 -0700 (PDT)

Dave Pawson,

> an entry, without having to duplicate

I don't follow.  Could you give an example showing the duplicated metadata?

--
Jimmy Cerra
https://nemo.dev.java.net

__________________________________ 
Discover Yahoo! 
Use Yahoo! to plan a weekend, have fun online and more. Check it out! 
http://discover.yahoo.com/

---

From: Bill de hÓra <[email-masked]>
Date: Thu, 16 Jun 2005 20:14:12 +0100

> 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

---

From: Dave Pawson <[email-masked]>
Date: Thu, 16 Jun 2005 20:52:28 +0100

> I don't follow.  Could you give an example showing the duplicated metadata?

Process. I write an instance. document element is a:feed.

Each successive day (or thereabouts) I write an entry.
I'm processing via XSLT.

I don't want a single monolith of a file,
so I'm writing daily using a document element of a:entry.

The end product is an 'empty' a:feed element (i.e. no entry children)
and 101 orphan a:entry instances, each with a days content.

Possibly because I'm not autogenerating all the 
metadata (child to a:feed, ancestor to a:entry) daily
I'm not in a position to post a single a:feed instance.
Is that any clearer?

(www.dpawson.co.uk/blog is the outcome)

-- 
Regards, 

Dave Pawson
XSLT + Docbook FAQ
http://www.dpawson.co.uk

---

From: James M Snell <[email-masked]>
Date: Thu, 16 Jun 2005 14:25:21 -0700

> 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 <content />, 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).

> 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:

    <feed>
      <entry>
        <content type="text">This is some text</content>
      </entry>
    </feed>

Becomes

    <feed>
      <entry>
        <content type="application/xenc+xml">
          <EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Content
                                    
MimeType="text/plain">...</EncryptedData>
        </content>
      </entry>
    </feed>

Example 2:

    <feed>
        <entry>
            <content type="html">&lt;p>This is some HTML&lt;/p></content>
        </entry>
    </feed>

Becomes

    <feed>
      <entry>
        <content type="application/xenc+xml">
          <EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Content"
                                    MimeType="text/html">...</EncryptedData>
        </content>
      </entry>
    </feed>

(note to self: read the damn spec next time  ;-)     )

- James

---

From: "The Purple Streak, Hilarie Orman" <[email-masked]>
Date: Thu, 16 Jun 2005 22:07:32 -0600

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

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 16 Jun 2005 22:15:05 -0700

>    c) the content of content elements. (examples 2, 4 and 5 in my 

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

---

From: "A. Pagaltzis" <[email-masked]>
Date: Fri, 17 Jun 2005 11:59:20 +0200

* Dave Pawson <[email-masked]> [2005-06-16 22:05]:
> Each successive day (or thereabouts) I write an entry. I'm
> processing via XSLT.
> 
> I don't want a single monolith of a file, so I'm writing daily
> using a document element of a:entry.
> 
> The end product is an 'empty' a:feed element (i.e. no entry
> children) and 101 orphan a:entry instances, each with a days
> content.

I’m not sure I understand what you’re talking about, but would it
be a possibility to use the XPath document() function to slurp
the atom:entry documents into the atom:feed document using a
stylesheet? This is how my own blog works.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>

---

From: James M Snell <[email-masked]>
Date: Fri, 17 Jun 2005 08:58:19 -0700

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:

> 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

---

From: James M Snell <[email-masked]>
Date: Mon, 20 Jun 2005 14:15:52 -0700

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.

   <!-- Sign entire document -->
   <feed>
     <entry />
     <entry />
     <Signature />
   </feed>

   or

   <!-- Each entry could have it's own signature. -->
   <feed>
      <entry>
        <Signature /> <!-- covers the containing <entry />  -->
      </entry>
   </feed>

   or

   <!-- One signature for the feed, covering specific entries -->
   <feed>
      <entry>
        <id>urn:abc...</id>
      </entry>
      <Signature>
        <!-- use transform to select only the entry with id = urn:abc... -->
      </Signature>
   </feed>

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

---

From: Dan Sandler <[email-masked]>
Date: Mon, 20 Jun 2005 22:26:43 -0500

On Jun 20, 2005, at 4:15 PM, James M Snell wrote:

> 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 <feed/> level, the granularity 
at which these third parties may slice and dice content is constrained 
to that level also.  The <entry/> 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/

---

From: James M Snell <[email-masked]>
Date: Mon, 20 Jun 2005 21:17:24 -0700

Dan Sandler wrote:

>     (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
>
> 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.
>

The thought here then is that feeds would not be considered atomic units 
and that <entry /> elements can be pulled as is out of a containing 
<feed /> 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 <entry /> if the containing feed has an author... for 
example:

   <feed>
      ...
      <author>...</author>
      <entry>...</entry>
   </feed>

as oppose to

   <feed>
      ...
      <entry>
         <author>...</author>
      </entry>
   </feed>

In the first case, the <entry /> 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 <author /> element from its containing feed would 
need to be added to the entry element's collection of metadata... 
(<entry>...</entry> becomes <entry> .. .<author /> ... </entry>) 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:
    <feed xmlns="...">
       ...
       <entry>
          <id>urn:123</id>
          ...
          <Signature xmlns="..." />
       </entry>
    </feed>

  Feed 2:
    <x:feed xmlns:x="...">
      ...
      <x:entry>
        <x:id>urn:abc</x:id>
        ...
        <ds:Signature xmlns:ds="..." />
      </x:entry>
    </x:feed>

  Perfectly Legal Synthesized Aggregated Feed
    <a:feed xmlns:a="..." >
       <a:entry>
          <a:id>urn:123</a:id>
          ...
          <Signature xmlns="..." /> <!-- invalid signature !! -->
       </a:entry>
      <a:entry>
        <a:id>urn:abc</a:id>
        ...
        <Signature xmlns="..." /> <!-- invalid signature !! -->
      </a:entry>
    </a:feed>

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
    <?xml ...?>
    <entry>
       <id>urn:123</id>
       <link rel="self" href="http://myblog.com/entries/1" />
       <Signature xmlns="..."/>   <!-- signed by original source -->
    </entry>

  Synthesized Aggegate Feed @ http://someaggregator/feed
     <?xml ...?>
     <feed>
        ...
       <entry>
          <id>urn:123</id>
          <link rel="self" href="http://myblog.com/entries/1" />
       </entry>
       <Signature xmlns="..." />  <!-- signed by aggregator -->
     </feed>

With this approach, the referenced copy of the entry becomes the 
"authenticated" version (assuming you trust both the aggregator's and 
original source's signatures) while the version of the entry contained 
in the entry is "unauthenticated".  The key challenge with this approach 
is that one would really have to trust the aggregator in order for it to 
work.

Another challenge is the fact that the Atom specification only accounts 
for Signature elements at the document level -- e.g. as a child of the 
top level <feed /> or <entry /> elements -- and not on the child entry 
level.

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. 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

Thoughts?

- James

---

From: "Bob Wyman" <[email-masked]>
Date: Tue, 21 Jun 2005 00:57:07 -0400

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

---

From: Dan Sandler <[email-masked]>
Date: Tue, 21 Jun 2005 00:12:27 -0500

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 <entry /> elements can be pulled as is out of a 
> containing <feed /> 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 <entry /> 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 <entry>---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 <feed> 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 <feed> 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 <author /> element from 
> its containing feed would need to be added to the entry element's 
> collection of metadata... (<entry>...</entry> becomes <entry> .. 
> .<author /> ... </entry>) 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, 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.

That seems pretty complicated.  Also, it requires the client, having 
received an entry signed by an aggregator, to go fetch the entry from 
the original server in order to get the "authentic" version (signed by 
originator).  In that case, why bother distributing the content in the 
aggregator?  The aggregator could save some effort and just publish 
list of URLs for the clients to fetch.

> [...] The key challenge with this approach is that one would really 
> have to trust the aggregator in order for it to work.

Right, which is the kind of trust I'm trying to avoid relying on.

> Another challenge is the fact that the Atom specification only 
> accounts for Signature elements at the document level -- e.g. as a 
> child of the top level <feed /> or <entry /> elements -- and not on 
> the child entry level.

Yes.  This has always struck me as an unnecessary limitation in the 
spec.  I chalked it up to getting 1.0 out the door, and trying to hash 
out all the ugly details of signatures later (in which case, mission 
accomplished).

> for Atom capable of traversing any number of intermediaries is largely 
> a myth. 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).

If indeed end-to-end authenticity is unnecessary, then I agree: 
document-level trust is all you need.

However, providing only document-level authenticity locks Atom (as a 
data format) out of other distribution models.  In essence, you're 
stuck with either "client polls source for entire feed" or "client gets 
entire feed from somewhere else".  There's no opportunity to send 
deltas, and there's no opportunity to combine feeds.  (Unless security 
is unimportant to Atom applications, in which case there's no reason to 
sign feeds or entries at all.)

---dan, kicking in way more than his two-cent quota

---

From: James M Snell <[email-masked]>
Date: Mon, 20 Jun 2005 22:33:37 -0700

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:

  <feed xmlns:xhtml="..." xmlns="...">
     <author>...</author>
     <entry>
       <id>...</id>
     </entry>
  </feed>

The canonicalized version of the entry would look something like:

<entry xmlns="..." xmlns:xhtml="...">
   <id>...</id>
   <source>
      <author>...</author>
   </source>
</entry>

The digital signature would then be calculated over the canonicalized 
entry. 

What else would the canonicalization scheme have to do?

- James

Bob Wyman wrote:

>    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
>
>
>

---

From: "Bob Wyman" <[email-masked]>
Date: Tue, 21 Jun 2005 01:28:10 -0400

James M Snell wrote:
> the ability to omit the author element from a contained <entry /> 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

---

From: Antone Roundy <[email-masked]>
Date: Tue, 21 Jun 2005 09:16:38 -0600

On Monday, June 20, 2005, at 11:33  PM, James M Snell wrote:
> 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>

	<head><!--it's baaaack!-->
		[feed metadata]
		<Signature xmlns="..." /><!--the feed head is signed--the entire feed 
could be too, but this is for aggregation-->
	</head>

	<entry>
		[entry metadata and content]
		<feedsig><!--a copy of the feed's head's signature, so that the entry 
can be verifiably linked to the signed feed metadata--></feedsig>
		<Signature xmlns="..." /> <!--the entry is signed, including the 
local copy of the feed head signature-->
	</entry>

	<entry>
		[entry metadata and content]
		<feedsig>...</feedsig>
		<Signature xmlns="..." />
	</entry>

	[etc.]

</feed>

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>
	[aggregation metadata]

	<feed>
		<head>
			[feed metadata]
			<Signature xmlns="..." />
		</head>
		<entry>
			[entry metadata and content]
			<feedsig>...</feedsig>
			<Signature xmlns="..." />
		</entry>
	</feed>

	<feed>
		[etc.]
	</feed>

	[etc.]
</aggregation>

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 21 Jun 2005 08:39:23 -0700

>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 <author /> element from its containing feed would need 
>to be added to the entry element's collection of metadata... 
>(<entry>...</entry> becomes <entry> .. .<author /> ... </entry>) 
>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 
>* 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

---

From: James M Snell <[email-masked]>
Date: Tue, 21 Jun 2005 17:13:12 -0700

> There are many valid use cases for both: that's why the spec 
 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 <entry /> does not 
"explicitly specify" the capacity to be signed.

   <?xml ...?>
   <feed>
      <entry />
      <Signature />  <!-- is valid atom 1.0 -->
   </feed>

   <?xml ...?>
   <entry>
      <Signature />  <!-- is valid atom 1.0 -->
   </entry>

   <?xml ...?>
   <feed>
      <entry>
          <Signature /> <!-- does *not* appear to be valid atom 1.0 
given my interpretation of Section 5 -->
      </entry>
   </feed>

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. :-)

>> 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.
>
>
> 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.

> 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...

   <feed xmlns:xhtml="http://www.w3.org/1999/xhtml" xmlns="...">
      <entry>
         <id>...</id>
         <content type="xhtml">
            <xhtml:div>...</xhtml:div>
         </content>
         <Signature xmlns="..."/>
      </entry>
   </feed>

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.

   <!-- aggregate feed with previous entry copied unmodified and 
obviously wrong -->
   <a:feed xmlns:a="..." xmlns="http://www.w3.org/1999/xhtml">
      <entry>
         <id>...</id>
         <content type="xhtml">
            <xhtml:div>...</xhtml:div>
         </content>
         <Signature xmlns="..."/>
      </entry>
   </a:feed>

Am I missing something fundamental here?

>> feed) and for indicating that content is trustworthy* on the document 
>> level (as opposed to individual feed entry level).
?? I don't understand.  What part of my post "isn't Atom"?  My comment 
deals with potential security issues that are specifically discussed in 
the Security Considerations (Section 8) portion of the Atom spec. 

Specifically:

8.1 "... Many elements in these languages are considered 'unsafe' in 
that they open clients to one or
    more types of attack. Implementers of software which processes Atom 
should carefully consider
    their handling of every type of element when processing incoming 
(X)HTML in Atom documents.
    See the security sections of [RFC2854] and [HTML] for guidance."

8.4 "...Atom Processors should be aware of the potential for spoofing 
attacks where the attacker
    publishes an atom:entry with the atom:id value of an entry from 
another feed, perhaps with a falsified
    atom:source element duplicating the atom:id of the other feed."

---

From: Scott Wilson <[email-masked]>
Date: Tue, 21 Jun 2005 13:43:12 +1000

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:
>
> to be individually signed?  e.g.
>

---

From: Eric Scheid <[email-masked]>
Date: Wed, 22 Jun 2005 13:38:22 +1000

> entries without changing them.

I think the problem is with clashing xmlns prefixes. Consider these two
separate feeds containing signed entries:

----------------------------------------------------------------
<feed xml:ns1="http://example.com/" ...>
    [...]
    <entry>
        [...]
        <Signature ... />
        <ns1:example-element>foo!</ns1:example-element>
    </entry>
</feed>

<feed xml:ns1="http://foo.com/" ...>
    [...]
    <entry>
        [...]
        <Signature ... />
        <ns1:foo-element>foo!</ns1:foo-element>
    </entry>
</feed>
----------------------------------------------------------------

The problem is the xmlns prefix "ns1" is used for two different namespaces.

Question: is the <entry> element itself included in the signature?

If not, then we can declare the xmlns:ns1 on the <entry> element ... but
we'd also need to disallow any extension or foreign attributes on the
<entry> (and <feed>) elements.

e.

---

From: James M Snell <[email-masked]>
Date: Tue, 21 Jun 2005 22:14:53 -0700

>separate feeds containing signed entries:
Yes

><entry> (and <feed>) 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.

---

From: "Bob Wyman" <[email-masked]>
Date: Wed, 22 Jun 2005 11:25:04 -0400

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

---

From: James M Snell <[email-masked]>
Date: Wed, 22 Jun 2005 09:17:36 -0700

>Atom?" The question: "Is C14N required?" is rhetorical at best. The answer
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.

>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?

---

From: Dave Pawson <[email-masked]>
Date: Thu, 23 Jun 2005 17:55:04 +0100

> 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

---

From: James M Snell <[email-masked]>
Date: Wed, 29 Jun 2005 12:47:14 -0700

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. <frameset>, <frame>, <script>, <link>, <style>, <object>, 
<embed>, <meta>, etc.  Even in feeds signed with trusted keys, 
aggregators should handle these with care.  (ref: 
http://diveintomark.org/archives/2003/06/12/how_to_consume_rss_safely).

Like I said, I'll be trying to have the draft put together by this 
weekend. 

- James

---

From: Antone Roundy <[email-masked]>
Date: Wed, 29 Jun 2005 14:17:19 -0600

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 ... >
	[feed metadata]
	<ex:annotation entry-id="foo">
		<ex:entry-signature>the entry's signature goes 
here</ex:entry-signature>
		[this annotation could be signed here]
		<ex:some-annotation-element>...</ex:some-annotation-element>
		...
	</ex:annotation>
	...
	<entry>
		<id>foo</id>
		[entry's signature here if signed]
		...
	</entry>
</feed>

Notes:
1) <ex:entry-signature> 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 <ex:annotation> 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 </entry> 
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.

---

From: James M Snell <[email-masked]>
Date: Wed, 29 Jun 2005 13:27:13 -0700

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.

<entry>
   <annotations xmlns="...">
   </annotations>
   <Signature>
      <!-- enveloped signature transform + transform that excludes any 
child <annotation xmlns="..." elements />
   </Signature>
</entry>

I'm still thinking through this.

- James

Antone Roundy wrote:

> unsigned one but keep your annotations separate, you might do 
> something like this:
>
> <feed ... >
>     [feed metadata]

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 29 Jun 2005 18:14:27 -0700

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?

>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?

>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?

>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.

>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!

>feeds. e.g. <frameset>, <frame>, <script>, <link>, <style>, 
><object>, <embed>, <meta>, etc.  Even in feeds signed with trusted 
>keys, aggregators should handle these with care.  (ref: 

Disagree, for the same reasons as above. We are signing the bits 
only, not some representation of the universe at the time of signing.

>Like I said, I'll be trying to have the draft put together by this weekend.

Hopefully, my comments above cause you to put discussion of your 
reasoning in there. Please don't read my comments as "don't do this", 
but rather "if you're going to do this, you have to justify it". That 
will make the document stronger and more likely to be implemented 
properly.

--Paul Hoffman, Director

---

From: James M Snell <[email-masked]>
Date: Thu, 30 Jun 2005 11:58:49 -0700

Paul Hoffman 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 
>> 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 
> 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.

> 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?

> 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.

> 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.

> 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?

>> signature MUST cover the referenced resource.
Same as above.  Even though it is included-by-reference, the referenced 
content is still a part of the message. 

> 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"

> How will you assert that?
Not so much a normative assertion.  More of a "if you know who produced 
this feed/entry and you decide that you can trust their signature, you 
can make finer grained decisions about whether or not to trust the 
content". 

>> 10. The I-D will not introduce any new elements or attributes
;-)

> Disagree, for the same reasons as above. We are signing the bits only, 
> not some representation of the universe at the time of signing.
>
Absolutely.  I am by far not an expert in digital signatures and very 
much appreciate the feedback.  comments like these are precisely why I 
kicked off this thread in the first place.  I would especially like to 
hear more thoughts on the inc-c14n vs. ex-c14n issue.

- James

---

From: Antone Roundy <[email-masked]>
Date: Thu, 30 Jun 2005 15:16:08 -0600

On Thursday, June 30, 2005, at 12:58  PM, James M Snell wrote:
> 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 <link> 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.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 30 Jun 2005 18:42:41 -0700

At 3:16 PM -0600 6/30/05, Antone Roundy 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
>>>
>>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?
>>
>Where would that signature go?  Did we decide that <link> 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 
<here> have a hash of <value>". 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

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 30 Jun 2005 18:40:06 -0700

>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 
>     situation where a digital signature is verified by reference to 
>a token provided in the
>     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.

>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.

>>>that are not covered are considered untrusted and pose a potential 
>>>security risk
>>
>>
>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.

>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.
>>
>>
>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 be trusted 
>>>(e.g. binary enclosures, scripts, etc)
>>
>>
>Not so much a normative assertion.  More of a "if you know who 
>produced this feed/entry and you decide that you can trust their 
>signature, you can make finer grained decisions about whether or not 
>to trust the content".

Not unless you can define "trust the content". All you can trust is 
that it is part of the assertion made by the semantic content of the 
signed message. That might be "I saw this program", it might be "I 
wrote this program", it might be "this program erased my hard drive", 
and so on. I think you were suggesting that signatures over active 
content could be automatically parsed to mean something; that's not 
OK without a lot of additional words and a different type of 
signature.

Suggestion (and only a suggestion): don't go there.

--Paul Hoffman, Director