Subject: Signature wording

From: Paul Hoffman <[email-masked]>
Date: Wed, 22 Jun 2005 10:17:29 -0700

Greetings again. The recent thread on digital signatures has shown a 
few areas that need to be clarified. I propose the following and ask 
for discussion. That is, I am *not* stating this is consensus, 
although it would be grand if it was.

1) We made a mistake, and we really meant to allow signing of 
stand-alone feeds, stand-alone entries, *and* entries in feeds. 
Proposed change:

Current:
    The root of an Atom document (i.e., atom:feed in an Atom Feed
    Document, atom:entry in an Atom Entry Document) MAY have an Enveloped
    Signature, as described by XML-Signature and Syntax Processing
    [W3C.REC-xmldsig-core-20020212].
New:
    The root of an Atom document (i.e., atom:feed in an Atom Feed
    Document, atom:entry in an Atom Entry Document), or any atom:entry
    element, MAY have an Enveloped
    Signature, as described by XML-Signature and Syntax Processing
    [W3C.REC-xmldsig-core-20020212].

2) What you are signing is just the set of bits in the entry, or just 
the set of bits in the feed, with no interpretation of them. No 
pre-canonicalization is needed, and none is to be expected by the 
validating party.

I truly don't believe that any change is needed to the format 
document to reflect this. There is nothing in section 5 that the 
signature is over the "bits plus everything relevant at the time of 
the signature". Bear in mind that because of the compulsory presence 
of <atom:id> and <atom:updated> in every entry, some of the benefits 
of canonicalization (reducing ambiguity in comparisons) are not 
material.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Antone Roundy <[email-masked]>
Date: Wed, 22 Jun 2005 11:49:15 -0600

On Wednesday, June 22, 2005, at 11:32  AM, James M Snell wrote:
> Paul Hoffman wrote:
> Hmm... not sure about this one.  We've already demonstrated via 
> several examples that things like XML namespaces and the lack of a 
> source element can cause problems in aggregator scenarios and that 
> some form of atom-specific canonicalization may be required.  Can you 
> expand a bit on your assertion with a few examples?  Some angle 
> brackets would really help me understand exactly where you're coming 
> from.

I take it, Paul, that you're suggesting that we punt on ensuring that 
entries can be aggregated without breaking signatures.  If so, we might 
consider suggesting some guidelines for maximizing the probability of a 
signature remaining valid, such as including a <source> element in each 
signed <entry>, using the most commonly used namespace prefixes for any 
namespaces used in the entry, and using UTF-8 (or whatever is most 
common for the language the feed is published in).

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 22 Jun 2005 10:54:42 -0700

At 10:32 AM -0700 6/22/05, James M Snell wrote:
>Paul Hoffman wrote:
>>2) What you are signing is just the set of bits in the entry, or 
>>just the set of bits in the feed, with no interpretation of them. 
>>No pre-canonicalization is needed, and none is to be expected by 
>>the validating party.
>>
>>the signature". Bear in mind that because of the compulsory 
>>presence of <atom:id> and <atom:updated> in every entry, some of 
>>the benefits of canonicalization (reducing ambiguity in 
>>comparisons) are not material.
>>
>some form of atom-specific canonicalization may be required.

I don't feel like you have demonstrated that. You have demonstrated 
that an aggregator might need to change some signed entries when they 
aggregate: that will inherently break the signature, and the 
aggregator will need to sign the entry themselves. But that's part of 
the aggregator's business model, not the Atom model. "We found this 
entry, we cleaned it up so you can use it, and we sign this set of 
bits so you know it is exactly what we emitted". If they want, they 
can also include the signed-and-unchanged original.

>   Can you expand a bit on your assertion with a few examples?  Some 
>angle brackets would really help me understand exactly where you're 
>coming from.

But that's exactly the point: no angle brackets are needed to 
understand "the set of bits in the entry". The signature is over the 
exact characters being signed, not some understanding of them based 
on namespaces, source elements, and so on. That's the difference 
between "bits" and "bits plus everything relevant at the time of the 
signature".

--Paul Hoffman, Director

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 22 Jun 2005 11:46:06 -0700

At 11:49 AM -0600 6/22/05, Antone Roundy wrote:
>I take it, Paul, that you're suggesting that we punt on ensuring 
>that entries can be aggregated without breaking signatures.

Exactly right.

>If so, we might consider suggesting some guidelines for maximizing 
>the probability of a signature remaining valid, such as including a 
><source> element in each signed <entry>, using the most commonly 
>used namespace prefixes for any namespaces used in the entry, and 
>using UTF-8 (or whatever is most common for the language the feed is 
>published in).

Someone might want to work on a document that advises (not mandates) 
a way to canonicalize the heck out of an entry to reduce the 
likelihood that an aggregator would want to change any bits in the 
entry, regardless of whether or not the entry is signed. We cannot 
tell aggregators that they cannot change bits in an signed entry: 
they might choose to do so even though it would break the signature 
because the bits they are changing are more important than the 
signature. For example, the aggregator may know the end recipient 
can't validate the signature anyway, or the aggregator may know that 
the signature was broken before they got the entry.

Such a document would probably be useful, or it might just be a 
useful entry in the implementer's guide. Getting input from some 
currently-active aggregators would be really useful for that, of 
course.

--Paul Hoffman, Director

---

From: James M Snell <[email-masked]>
Date: Wed, 22 Jun 2005 11:55:11 -0700

Paul Hoffman wrote:

>>> just the set of bits in the feed, with no interpretation of them. No 
Ok, I think this clears up the disconnect a bit.  What I'm shooting for 
is a way of allowing aggregators to pass entries along as is without 
breaking the original signature -- something that you do not seem to 
think is important (correct?).  The demonstrations I've provided to this 
point have shown that an aggregator would almost certainly have to break 
the signature even if it is not adding any value or peforming any 
processing on the entry, which obviously misses the mark a bit. 

Three models:

1. Subscriber directly accesses a digitally signed source feed.
2. Subscriber receives entries via an aggregator that modifies entries, 
breaking any signatures that exist, potentially re-signs the entries
3. Subscriber receives entries via an aggregator that does not modify 
entries, aggregator wishes to pass those along in a way that does not 
break any of the original signatures

1 and 2 are easy.  They really don't require a lot of discussion.  #3 is 
where the problem appears to exists.

The only reason I've seen thus far to digitally sign individual entries 
within a feed is to enable aggregation scenarios so it really doesn't 
seem to make a lot of sense if the solution requires aggregators to 
break signatures within entries in order to aggregate those entries.  If 
breaking the signature is required, might as well just sign the source 
feed document and skip signing the entries at all. So your change in #1 
would be unnecessary

Note that I am not trying to change Atom's model or the core spec, I am 
trying to define an Atom extension that is capable of meeting a specific 
problem space that happens to include the types of things aggregators 
are going to want to be able to do.  I just don't want Atom to get in 
the way like it does now with not allowing Signatures on child <entry /> 
elements.  Adding any kind of language that precludes the ability to 
accomplish #3 unnecessarily gets in the way of the solution.  I'm not 
sure if the second item in your original note is suggesting that such 
language be added ???

> exact characters being signed, not some understanding of them based on 
> namespaces, source elements, and so on. That's the difference between 
> "bits" and "bits plus everything relevant at the time of the signature".
>
An example would be necessary to show how to accomplish #3 ONLY IF you 
agreed that providing an aggregators ability to pass along an entry 
unmodified with the original signature in tact was an important thing to 
do, which does not appear to be the case (please correct me if I'm wrong)

> --Internet Mail Consortium

- James

---

From: James M Snell <[email-masked]>
Date: Wed, 22 Jun 2005 12:03:40 -0700

Paul Hoffman wrote:

>> entries can be aggregated without breaking signatures.
>
>
> Exactly right.
>
In the core Atom spec, absolutely.

>> <source> element in each signed <entry>, using the most commonly used 
>> namespace prefixes for any namespaces used in the entry, and using 
>> UTF-8 (or whatever is most common for the language the feed is 
>> published in).
>
>
> Someone might want to work on a document that advises (not mandates) a 
> way to canonicalize the heck out of an entry to reduce the likelihood 
> that an aggregator would want to change any bits in the entry, 
> regardless of whether or not the entry is signed. We cannot tell 
> aggregators that they cannot change bits in an signed entry: they 
> might choose to do so even though it would break the signature because 
> the bits they are changing are more important than the signature. For 
> example, the aggregator may know the end recipient can't validate the 
> signature anyway, or the aggregator may know that the signature was 
> broken before they got the entry.
>
I'm planning to write a separate Internet-Draft that discusses digital 
signing of Atom feeds and entries.  Some parts of that document will 
includes mandates; other parts will include recommendations.  We can 
describe for entry producers a way of producing signed entries that can 
be aggregated with original signatures in tact and a set of 
recommendations to aggregators that wish to pass those signed entries 
around with signatures in tact.  Sure, it's all up to the aggregators 
and content providers to decide whether or not they want to support 
those methods -- which is the whole point of I'm working on this as a 
separate I-D and positioning it as an optional extension to Atom. :-)

> Such a document would probably be useful, or it might just be a useful 
> entry in the implementer's guide. Getting input from some 
> currently-active aggregators would be really useful for that, of course.
>
> --Paul Hoffman, Director
- James

---

From: Tim Bray <[email-masked]>
Date: Wed, 22 Jun 2005 12:20:47 -0700

On Jun 22, 2005, at 11:55 AM, James M Snell wrote:

>
> Note that I am not trying to change Atom's model or the core spec,

We do agree on Paul's suggested changed saying "it's OK to sign  
entries" though, I think.

> I am trying to define an Atom extension that is capable of meeting  
> a specific problem space that happens to include the types of  
> things aggregators are going to want to be able to do.

I think this is a good idea.  I'd be pretty strongly against us  
trying to write some sort of c14n language into the format spec  
because we have little prior art to draw on with respect to XML  
DigSig in general, and exactly zero (as far as I know) to draw on for  
digsig in a feed or aggregated-feed context.  So we just totally  
don't know how this is going to shake down in the market.

So I agree.  Remove the prohibition on signing entries, and let the  
engineers figure out what works. -Tim

---

From: Tim Bray <[email-masked]>
Date: Wed, 22 Jun 2005 12:22:29 -0700

On Jun 22, 2005, at 12:03 PM, James M Snell wrote:

> I'm planning to write a separate Internet-Draft that discusses  
> digital signing of Atom feeds and entries.  Some parts of that  
> document will includes mandates; other parts will include  
> recommendations.  We can describe for entry producers a way of  
> producing signed entries that can be aggregated with original  
> signatures in tact and a set of recommendations to aggregators that  
> wish to pass those signed entries around with signatures in tact.   
> Sure, it's all up to the aggregators and content providers to  
> decide whether or not they want to support those methods -- which  
> is the whole point of I'm working on this as a separate I-D and  
> positioning it as an optional extension to Atom. :-)

A man who spots a problem, then volunteers to do the work around  
fixing it!  We need more like that.  I suspect that there's an  
excellent chance that this might become a WG draft, but I remained  
concerned about our lack of hands-on experience. -Tim

---

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

Tim Bray wrote:

>> Sure, it's all up to the aggregators and content providers to  decide 
>> whether or not they want to support those methods -- which  is the 
>> whole point of I'm working on this as a separate I-D and  positioning 
>> it as an optional extension to Atom. :-)
>
>
The lack of hands on experience is a big issue.  What I'd like to see is 
a) I/we draft the I-D describing the details, b) get some aggregator 
folks (Bob?) to implement a prototype based on it, c) start iterating 
the I-D and implementations accordingly.  If we can get some committment 
from the aggregator folks to start doing some implementation work, our 
job is going to become much easier.

---

From: James M Snell <[email-masked]>
Date: Wed, 22 Jun 2005 10:32:31 -0700

>    [W3C.REC-xmldsig-core-20020212].
+1

> I truly don't believe that any change is needed to the format document 
> to reflect this. There is nothing in section 5 that the signature is 
> over the "bits plus everything relevant at the time of the signature". 
> Bear in mind that because of the compulsory presence of <atom:id> and 
> <atom:updated> in every entry, some of the benefits of 
> canonicalization (reducing ambiguity in comparisons) are not material.
>
Hmm... not sure about this one.  We've already demonstrated via several 
examples that things like XML namespaces and the lack of a source 
element can cause problems in aggregator scenarios and that some form of 
atom-specific canonicalization may be required.  Can you expand a bit on 
your assertion with a few examples?  Some angle brackets would really 
help me understand exactly where you're coming from.

- James