Subject: Roll-up of proposed changes to atompub-format section 5

From: Paul Hoffman <[email-masked]>
Date: Mon, 4 Jul 2005 18:59:01 -0700

Greetings again. The "clearing a discuss" thread has been productive, 
but the proposed wording has changed a few times. Here is what I 
suggest is good final wording that covers the issues brought up. 
Comments are welcome.

5.  Securing Atom Documents

    Because Atom is an XML-based format, existing XML security mechanisms
    can be used to secure its content.

[[ NEW ]]

    Producers of feeds and/or entries, and intermediaries who aggregate
    feeds and/or entries, may have sound business reasons for signing
    and/or encrypting otherwise-unprotected content. For example,
    a merchant might digitally sign a message that contains a discount
    coupon for its products. A bank that uses Atom to deliver customer
    statements is very likely to want to sign and encrypt those
    messages to protect their customers' financial information and to
    assure the customer of their authenticity. Intermediaries may want
    to encrypt aggregated feeds so that a passive observer cannot tell
    what topics the recipient is interested in. Of course, many other
    examples exist as well.

[[ NEW ]]

    The algorithm requirements in this section pertain to the Atom
    Processor. They require that a recipient, at a minimum, be able to
    handle messages that use the specified cryptographic algorithms.
    This does not limit the algorithms that the sender can choose: it
    only says that the sender can only assume the recipient can use
    the named algorithms unless they have other out-of-band knowledge.

5.1  Digital Signatures

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

    Atom Processors MUST NOT reject an Atom Document containing such a
    signature because they are not capable of verifying it; they MUST
    continue processing and MAY inform the user of their failure to
    validate the signature.

    In other words, the presence of an element with the namespace URI
    "http://www.w3.org/2000/09/xmldsig#" and a local name of "Signature"
    as a child of the document element MUST NOT cause an Atom Processor
    to fail merely because of its presence.

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

[[ NEW ]]

    Section 6.5.1 of [W3C.REC-xmldsig-core-20020212] requires support
    for Canonical XML. Atom Processors that verify signed Atom Documents
    MUST be able to canonicalize with Canonical XML.

[[ NEW ]]

    Section 4.4.2 of [W3C.REC-xmldsig-core-20020212] requires support
    for DSA signatures and recommends support for RSA signatures.
    However, because of the much greater popularity in the market of
    RSA versus DSA, Atom Processors that verify signed Atom Documents MUST
    be able to verify RSA signatures, but do not need be able to verify DSA
    signatures. Due to security issues that can arise if the keying material
    for MAC authentication is not handled properly, Atom documents SHOULD
    NOT use MACs for signatures.

5.2  Encryption

    The root of an Atom Document (i.e., atom:feed in an Atom Feed
    Document, atom:entry in an Atom Entry Document) MAY be encrypted,
    using the mechanisms described by XML Encryption Syntax and
    Processing [W3C.REC-xmlenc-core-20021210].

[[ NEW ]]

    Section 5.1 of [W3C.REC-xmlenc-core-20021210] requires support of
    TripleDES, AES-128, and AES-256. Atom Processors that decrypt Atom
    Documents MUST be able to decrypt with AES-128 in CBC mode.

[[ NEW ]]

    Encryption based on [W3C.REC-xmlenc-core-20021210] does not assure
    integrity of the original document. There are known cryptographic
    attacks where someone who cannot decrypt a message can still change
    bits in a way where part or all the decrypted message makes sense but
    has a different meaning. Thus, Atom Processors that decrypt Atom
    Documents SHOULD check the integrity of the decrypted document by
    verifying the hash in the signature (if any) in the document, or by
    verifying a hash of the document within the document (if any).

[[ NEW ]]

5.3 Signing and Encrypting

[[ NEW ]]

    When an Atom Document is to be both signed and encrypted, it is
    generally a good idea to first sign the document, then encrypt the
    signed document. This provides integrity to the base document while
    encrypting all the information, including the identity of the entity
    that signed the document. Note that, if MACs are used for authentication,
    the order MUST be that the signed document is encrypted, and not the
    other way around.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: "Bob Wyman" <[email-masked]>
Date: Mon, 4 Jul 2005 22:38:33 -0400

I believe it would be very useful to specify that signed entries should 
include a  source element. This can/should be considered part of entry 
canonicalization.
    The reason I suggest this is that signed entries are only really useful 
when extracted from their original source feeds. If entries are only read 
from their source feeds, then it is probably best for publishers to sign the 
feed, not the individual entries. (Note: It is my hope that feed publishers 
will anticipate that their entries will be extracted from the source feeds 
and will thus sign the individual entries rather than the feeds... i.e. 
Publishers should anticipate that intermediaries like PubSub and various 
other search/discovery services will aggregate their entries and republish 
them in non-source feeds.)
    When an entry is removed from its source, it SHOULD have a source 
element inserted if one is not already present. However, if a republisher 
inserts a source element into a signed entry that would break the signature. 
Thus, it seems reasonable that we should strongly encourage those who sign 
entries to anticipate the needs of subsequent processors by inserting the 
source elements in the original signed entries. By inserting the source 
elements, the requirement for others to break the signature will be 
drastically reduced. If an entry is signed, yet contains no source element, 
much of the utility of the signature (allowing verification of the original 
publisher) is eliminated.

    bob wyman

---

From: Tim Bray <[email-masked]>
Date: Mon, 04 Jul 2005 21:41:24 -0700

On Jul 4, 2005, at 7:38 PM, Bob Wyman wrote:

>
>    I believe it would be very useful to specify that signed entries  
> should include a  source element. This can/should be considered  
> part of entry canonicalization.

-1.  Leave it to the market.  I suspect that you're right, but I'd be  
unsurprised if an application for signed un-sourced applications  
turned up.  -Tim

>    The reason I suggest this is that signed entries are only really  
> useful when extracted from their original source feeds. If entries  
> are only read from their source feeds, then it is probably best for  
> publishers to sign the feed, not the individual entries. (Note: It  
> is my hope that feed publishers will anticipate that their entries  
> will be extracted from the source feeds and will thus sign the  
> individual entries rather than the feeds... i.e. Publishers should  
> anticipate that intermediaries like PubSub and various other search/ 
> discovery services will aggregate their entries and republish them  
> in non-source feeds.)
>    When an entry is removed from its source, it SHOULD have a  
> source element inserted if one is not already present. However, if  
> a republisher inserts a source element into a signed entry that  
> would break the signature. Thus, it seems reasonable that we should  
> strongly encourage those who sign entries to anticipate the needs  
> of subsequent processors by inserting the source elements in the  
> original signed entries. By inserting the source elements, the  
> requirement for others to break the signature will be drastically  
> reduced. If an entry is signed, yet contains no source element,  
> much of the utility of the signature (allowing verification of the  
> original publisher) is eliminated.
>
>    bob wyman
>
>
>

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 5 Jul 2005 08:19:36 -0700

At 9:41 PM -0700 7/4/05, Tim Bray wrote:
>-1.  Leave it to the market.  I suspect that you're right, but I'd 
>be unsurprised if an application for signed un-sourced applications 
>turned up.  -Tim

I'm with Tim on the -1. Bob's suggestion and explanation make good 
sense for the implementer's guide, but not for the base spec. There 
is not an interoperability issue that I can see for entries without 
sources being signed.

--Paul Hoffman, Director

---

From: "Bob Wyman" <[email-masked]>
Date: Tue, 5 Jul 2005 11:58:54 -0400

Paul Hoffman wrote:
> I'm with Tim on the -1. Bob's suggestion and explanation make
> good sense for the implementer's guide, but not for the base spec.
> There is not an interoperability issue that I can see for entries
> without sources being signed.

	Could we at least put in a sentence that states that including a
source element in signed entries is recommended? The implementer's guide
would then expand on that with more detail, discussion, etc. Note: I am not
suggesting use of the "should" word, although I would like it.
	We can debate what it means to have an "interoperability" issue,
however, my personal feeling is that if systems are forced to break and
discard signatures in order to perform usual and customary processing on
entries that falls very close to the realm of interoperability if not within
it. Deferring this issue until the implementer's guide is written is likely
to defer it beyond the point at which common practice is established. The
result is likely to be that intermediaries and aggregators end up discarding
most signatures that appear in source feeds.

		bob wyman

---

From: Tim Bray <[email-masked]>
Date: Tue, 05 Jul 2005 09:11:40 -0700

> most signatures that appear in source feeds.

Huh?!  Pardon my ignorance, could you please provide an explanation  
for the simple-minded as to how the absence of a source element in a  
signed entry will lead to signatures being discarded?  Also, it would  
be helpful to sketch in some of the surrounding scenario... -Tim

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 5 Jul 2005 09:09:40 -0700

At 11:58 AM -0400 7/5/05, Bob Wyman wrote:
>would then expand on that with more detail, discussion, etc.

It's quite late to do this. The IESG is looking at a particular 
version of the draft, and are making comments on that particular 
version. It is really important that we only make changes based on 
IESG members' input, not on yet-more things we find.

--Paul Hoffman, Director

---

From: James M Snell <[email-masked]>
Date: Tue, 05 Jul 2005 09:16:03 -0700

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

Are we going to be making the change specified in point 1 of [1] ?  That 
is, specifically allow for Signature on any atom:entry element?

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

[1] http://www.mail-archive.com/[email-masked]/msg04288.html

- James

---

From: James M Snell <[email-masked]>
Date: Tue, 05 Jul 2005 09:27:18 -0700

> be helpful to sketch in some of the surrounding scenario... -Tim
Bob can clarify exactly what he means but from my perspective it comes 
down to an aggregation problem.  If a signature is generated over an 
entry that does not contain an author element or a source element, that 
entry cannot be re-enveloped into an aggregate feed that does not 
contain a top level author element without breaking the signature as the 
intermediary would have to insert either the author element or the 
source element with author in order to produce compliant Atom. 

- James

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 5 Jul 2005 09:28:34 -0700

At 9:16 AM -0700 7/5/05, James M Snell wrote:
>Are we going to be making the change specified in point 1 of [1] ? 
>That is, specifically allow for Signature on any atom:entry element?

Yipes! Good catch. That was my mistake. I rolled-up from one thread, 
not both of them.

The beginning of 5.1 in the roll-up should have read:

5.1  Digital Signatures

[[ CHANGED ]]

--Paul Hoffman, Director

---

From: Antone Roundy <[email-masked]>
Date: Tue, 5 Jul 2005 10:54:42 -0600

> be helpful to sketch in some of the surrounding scenario... -Tim

If a signed entry doesn't have a source element and an aggregator 
inserts one, the signature will be broken--thus the aggregator will 
either discard the signature or republish the entry with a broken 
signature.

Perhaps language like this would work without being too much of a 
change at this late date:

"When signing individual entries that do not contain an atom:source 
element, be aware that aggregators inserting an atom:source element 
will be unable to retain the signature. For this reason, publishers 
might consider including an atom:source element in all individually 
signed entries."

---

From: "Bob Wyman" <[email-masked]>
Date: Tue, 5 Jul 2005 13:14:28 -0400

Tim Bray wrote:
> If I want to sign an entry and also want to make it available
> for aggregation then yes, I'd better put in an atom:source.  But 
> this is inherent in the basic definition of digsig; not something
> we need to call out.   -Tim
	Certainly, the chain of reasoning is as clear and logical as you
describe. However, it is also very clear that this is precisely the sort of
multi-step chain of reasoning that is often overlooked by even the most
earnest of implementers. We have many, many indications that significant
numbers of RSS/Atom implementers do not, in fact, think much beyond what it
takes to get their content into a file. Even the best implementers, and
valued participants in this working group, have regularly proved that they
don't remember to think out all the systemic issues of syndication. Perhaps
it is because there are so few of us that act as intermediaries... The
issues are not well understood by those who don't serve this function.
	Forgive me for suggesting that we call out the obvious. However,
this particularly bit of obviousness is not very obvious. In fact, it is
probably not "obvious" to most folk until *after* it has been called out. We
will help matters greatly by at least providing a recommendation that source
elements be inserted in signed entries...

		bob wyman

---

From: "Bob Wyman" <[email-masked]>
Date: Tue, 5 Jul 2005 13:20:13 -0400

Antone Roundy wrote:
> "When signing individual entries that do not contain an 
> atom:source element, be aware that aggregators inserting an 
> atom:source element will be unable to retain the signature. For this 
> reason, publishers might consider including an atom:source element in
> all individually signed entries."

	+1

		bob wyman

---

From: Tim Bray <[email-masked]>
Date: Tue, 05 Jul 2005 10:45:29 -0700

> might consider including an atom:source element in all individually  

Still -1, despite Bob's arguments, at least in part because we have  
no idea what kind of applications are going to be using signed  
entries and we shouldn't try to micromanage a future we don't  
understand. -Tim

---

From: Walter Underwood <[email-masked]>
Date: Tue, 05 Jul 2005 11:28:10 -0700

--On Tuesday, July 05, 2005 10:45:29 AM -0700 Tim Bray <[email-masked]> wrote:
>
> Still -1, despite Bob's arguments, at least in part because we have no idea
> what kind of applications are going to be using signed  entries and we shouldn't
> try to micromanage a future we don't  understand. -Tim

I'm +1, because this is a "when features collide!" issue for Atom.
We don't have to make it a SHOULD or a MUST, just point out that
signed entries need to be standalone if they will ever be used
outside of their feed context.

wunder
--
Walter Underwood
Principal Architect
Verity Ultraseek

---

From: "Bob Wyman" <[email-masked]>
Date: Tue, 5 Jul 2005 14:24:15 -0400

> entries and we shouldn't try to micromanage a future we don't
	We *DO* know that PubSub will support signed entries in the
future... And, we know that PubSub and any service like it will be forced to
discard signatures on any signed entries that do not have source elements in
them. Given that at least some would consider it likely that such services
will not only remain popular but grow in popularity in the future, why is it
such a terrible thing to provide an optional recommendation that people
address the needs of these services?
	I find it hard to imagine what harm could be done by providing this
recommendation. Any application written in the future is already forced to
handle entries with source elements since these elements are permitted by
the Atom specification as it stands now. Thus, simply recommending that
people do what they are already permitted to do just doesn't seem to
threaten harm to unspecified future applications -- yet, it would clearly
accomplish some good in the case of the known applications.

	What is the utility of signed entries if not to facilitate the
copying of entries between feeds? Why sign individual elements unless they
are likely to be removed from their original context? If entries are not to
be copied, then feed signatures are all that is necessary and would result
in smaller, more bandwidth-efficient feeds.

		bob wyman

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 5 Jul 2005 11:48:44 -0700

At 2:24 PM -0400 7/5/05, Bob Wyman wrote:
>recommendation.

Timing. If we change text other than because of an IESG note, there 
is a strong chance we will have to delay being finalized by two 
weeks, possibly more.

--Paul Hoffman, Director

---

From: "A. Pagaltzis" <[email-masked]>
Date: Tue, 5 Jul 2005 21:09:34 +0200

> > all individually signed entries."

+1 as well. It is one of those obvious-in-hindsight things that
the spec would do well to point out to implementors in advance.

If putting this into the spec would require a delay, then I
suppose we’ll have to end up living with a spec that could have
been more explicit. This clarification is not worth slowing
things down for.

But if we can get this in there as part of the parcel for
clearing the “discuss” vote without further delaying the process,
(after all, it doesn’t actually change the spec in any way, it
just explicates ramifications of the spec as it already stands,)
it would be a very worthwhile addition.

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

---

From: James M Snell <[email-masked]>
Date: Tue, 05 Jul 2005 12:12:15 -0700

Paul Hoffman wrote:

> Timing. If we change text other than because of an IESG note, there is 
> a strong chance we will have to delay being finalized by two weeks, 
> possibly more.
>
> --Paul Hoffman, Director
I definitely understand this particular concern, but in going back and 
reading the original discussion point note from Russ (as quoted in your 
"Clearing a "discuss" vote email), I would think that this particular 
point is an important step towards clarifying the potential interop 
issues when using digital signatures within Atom.  Furthermore, given 
that we're not introducing any new requirements into the spec, this is 
actually a far less impactful change than the modification we just made 
to adjust the spec text to explicitly allow Signatures in any atom:entry. 

- James

---

From: "Bob Wyman" <[email-masked]>
Date: Tue, 5 Jul 2005 15:12:06 -0400

Paul Hoffman wrote:
> Timing. If we change text other than because of an IESG note,
> there is a strong chance we will have to delay being finalized by
> two weeks, possibly more.
	I am aware of the issues with timing and I believe I am just as
concerned as you are with these issues. I was rather stunned to be at
Gnomedex recently and hear it said that after all the effort we've put into
Atom we still have "nothing to show for it." An approved RFC would make such
statements much less acceptable... 
	However, I think that this can be positioned as part of the response
to the IESG comments concerning canonicalization since including source
elements in signed entries will tend to cause those entries to be more
"canonical" or consistent in form. Also, given that the addition is merely a
recommendation and is thus non-normative, it shouldn't raise any review
issues.

	Please remember that this isn't an issue that I just pulled out of
the hat at the last moment. I first brought this up long ago -- long before
last call... The problem, as has often been the case with the issues I
raise, is that there aren't many people who seem to be terribly aware of or
concerned with the aggregation issues even though we've got reasonable
representation from those who build feed generators and clients. I'm trying
hard to do the right thing for Atom and really wish that other
intermediaries, search engines, etc. would participate more but for whatever
reason, most have chosen to remain silent on these issues... 

		bob wyman

---

From: Robert Sayre <[email-masked]>
Date: Tue, 5 Jul 2005 15:21:02 -0400

> > entries and we shouldn't try to micromanage a future we don't

-1 as well.
 
> in smaller, more bandwidth-efficient feeds.

Here are two uses:

1.) Calculate a signature for each entry once, but vary the number of
entries in a feed.

2.) Pass through a signature received via Atom Protocol.

Robert Sayre

---

From: Walter Underwood <[email-masked]>
Date: Tue, 05 Jul 2005 12:50:36 -0700

--On Tuesday, July 05, 2005 11:48:44 AM -0700 Paul Hoffman <[email-masked]> wrote:
> Timing. If we change text other than because of an IESG note, there is a strong
> chance we will have to delay being finalized by two weeks, possibly more.

I'm fine with the delay. Two or three weeks on top of 18 months is
not a big deal.

wunder
--
Walter Underwood
Principal Architect
Verity Ultraseek

---

From: Tim Bray <[email-masked]>
Date: Tue, 05 Jul 2005 12:59:21 -0700

> I'm fine with the delay. Two or three weeks on top of 18 months is

I am *not*.   It's not "two or three weeks", it's "some  
uncontrollable time in the future" versus "now".  We have spent way  
too long already. -Tim

---

From: Antone Roundy <[email-masked]>
Date: Tue, 5 Jul 2005 14:11:28 -0600

> been more explicit. This clarification is not worth slowing

Agreed.  If we can get it in without delaying things, I'm all for it.  
But if not, then I can live without it.  It doesn't actually change 
anything--just reduces the probability of the issue being overlooked.

---

From: David Powell <[email-masked]>
Date: Tue, 5 Jul 2005 21:05:43 +0100

> IESG members' input, not on yet-more things we find.

Will we still be fixing some of bugs raised since the last draft
though?

Specifically, what are the resolutions for the disputed ban on
composite MIME types [1], and some of the specific bugs in section 6
[2] (mismatches with the RelaxNG etc)?

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

-- 
Dave

---

From: Tim Bray <[email-masked]>
Date: Tue, 05 Jul 2005 14:24:04 -0700

> Will we still be fixing some of bugs raised since the last draft

Definitely.  A number of things have been pointed out as bugs,  
there's been no WG pushback on any of them, and since we were going  
to have to have a -10 draft anyhow for the namespace, we will roll in  
those fixes, as well as resolving any IESG-raised issues.  -Tim

---

From: Tim Bray <[email-masked]>
Date: Tue, 05 Jul 2005 09:53:42 -0700

On Jul 5, 2005, at 9:27 AM, James M Snell wrote:
>> Huh?!  Pardon my ignorance, could you please provide an  
>> explanation  for the simple-minded as to how the absence of a  
>> source element in a  signed entry will lead to signatures being  
>> discarded?  Also, it would  be helpful to sketch in some of the  
>> surrounding scenario... -Tim
>>
> Bob can clarify exactly what he means but from my perspective it  
> comes down to an aggregation problem.  If a signature is generated  
> over an entry that does not contain an author element or a source  
> element, that entry cannot be re-enveloped into an aggregate feed  
> that does not contain a top level author element without breaking  
> the signature

Well, yes.  Anyone who understands digsig, even someone such as  
myself with only a surface knowledge, can see this.  You can't change  
a signed object without breaking the sig, that's the point.  If I  
want to sign an entry and also want to make it available for  
aggregation then yes, I'd better put in an atom:source.  But this is  
inherent in the basic definition of digsig; not something we need to  
call out.   -Tim

---

From: [email-masked] (John Panzer)
Date: Tue, 05 Jul 2005 15:21:23 -0700

> might consider including an atom:source element in all individually 
+1.

I think this thread shows that the implications of signing individual 
entries sans atom:source elements are nonobvious and worth a 
(non-normative) note to help implementors, if this will not delay things.

-- 
John Panzer
Sr Technical Manager, AOL
http://journals.aol.com/panzerjohn/abstractioneer

---

From: Tim Bray <[email-masked]>
Date: Tue, 05 Jul 2005 16:56:19 -0700

On Jul 5, 2005, at 4:08 PM, Paul Hoffman wrote:

> Intermediaries such as aggregators may need to add an atom:source  
> element to an entry that does not contain its own atom:source  
> element. If such an entry was signed, the addition will break the  
> signature. Thus, a publisher of individually-signed entries should  
> strongly consider adding an atom:source element to those entries  
> before signing them.

Grumble grumble OK.  -Tim

---

From: "Bob Wyman" <[email-masked]>
Date: Tue, 5 Jul 2005 20:00:17 -0400

Paul Hoffman wrote:
> Intermediaries such as aggregators may need to add an 
> atom:source element to an entry that does not contain its own
> atom:source element. If such an entry was signed, the addition
> will break the signature. Thus, a publisher of individually-signed
> entries should strongly consider adding an atom:source element to
> those entries before signing them.

	It looks good to me. Thanks!

		bob wyman

---

From: James M Snell <[email-masked]>
Date: Tue, 05 Jul 2005 13:26:39 -0700

> anything--just reduces the probability of the issue being overlooked.
+1 on including it if and only if we can do so without causing any 
further delay.  -1 if we can't. 

- James

---

From: Walter Underwood <[email-masked]>
Date: Tue, 05 Jul 2005 10:31:17 -0700

--On July 5, 2005 9:53:42 AM -0700 Tim Bray <[email-masked]> wrote:
> Well, yes.  Anyone who understands digsig, even someone such as  myself with only a surface knowledge, can see this.  You can't change  a signed object without breaking the sig, that's the point.  If I  want to sign an entry and also want to make it available for  aggregation then yes, I'd better put in an atom:source.  But this is  inherent in the basic definition of digsig; not something we need to  call out.   -Tim

But it is an interoperability consequence of the Atom format and cascaded
values. It would be worth commenting that signed entries need to be standalone
in order to be aggregated in another feed and keep their signature.

wunder
--
Walter Underwood
Principal Architect, Verity

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 5 Jul 2005 16:08:26 -0700

OK, I'm backing off of my statement that it is too late to deal with 
this. Thank you to the people who pointed out that this is directly 
related to Russ' concern about interop of canonicalization. You are 
right, and I was being too narrow-minded.

Does anyone object to the following exact wording being added right 
after the new paragraph on canonicalizing:

--Paul Hoffman, Director

---

From: "Bob Wyman" <[email-masked]>
Date: Tue, 5 Jul 2005 19:01:43 -0400

How about a compromise on the source insertion thing...

Paul Hoffman's proposed text for the first paragraph in Section 5 starts off
with a set of examples of why one would want to sign or encrypt atom entries
or feeds. (Discount coupons, bank statements, etc.) These examples were
requested by the IESG. In my opinion, none of the examples really speaks to
current uses of Atom. Thus, I would suggest that we either replace one of
the existing examples or add a new one with wording something like:

	A publisher might digitally sign an entry, which included
	an atom:source element, in order to ensure that verifiable
	attribution for the entry was available if that entry was
	copied into another feed or distributed via some other means.

I believe this improves the existing proposed text by providing a much more
immediately probable example than those currently listed. Additionally, by
alluding to the issue of including the source element it may at least tend
to cause implementers to consider the wisdom of including source elements in
signed entries. Finally, since the provision of examples is something that
was explicitly requested as part of the IESG review, this should not cause
any delay beyond those that are already inevitable.

		bob wyman

---

From: James M Snell <[email-masked]>
Date: Tue, 05 Jul 2005 16:27:51 -0700

Paul Hoffman wrote:

> element to an entry that does not contain its own atom:source element. 
> If such an entry was signed, the addition will break the signature. 
> Thus, a publisher of individually-signed entries should strongly 
> consider adding an atom:source element to those entries before signing 
> them.
>
> --Paul Hoffman, Director
This text sounds good.

- James

---

From: "A. Pagaltzis" <[email-masked]>
Date: Wed, 6 Jul 2005 18:52:28 +0200

* Paul Hoffman <[email-masked]> [2005-07-06 01:20]:
> Does anyone object to the following exact wording being added
> right after the new paragraph on canonicalizing:

Not me. +1 to the addition.

Regards,