Subject: Atom protocol and digital signatures

From: Sam Hartman <[email-masked]>
Date: Sun, 17 Jun 2007 15:20:47 -0400

[atom-syntax copied because while it seems inappropriate for this discussion it is the working group's official list of record according to the charter]

Hi.  I'm one of the security area directors and I currently have a
blocking discuss comment on the atom protocol document.  Lisa has
suggested fixes that address almost all of my concerns.  There is one
concern remaining that I would like to discuss with the working group.

Section 15.4 of the document basically says that digital signatures
may break and says little more.

That's problematic .  I certainly understand that sometimes a server
might choose to do something that has to break digital signatures like
say translating content from one language into another.

However there are many cases where it is unnecessary for digital
signatures to break.  If I post a blog post and the server doesn't
reformat or otherwise change my post, it seems that the signature on
the entry could remain.  The spec does not prohibit this, but it seems
that the working group should think more about the issue.

Here are some examples of questions I think should be answered:

1) I'm implementing a server; I don't want to break digital
    signatures.  What should I be careful of?  As an example, what
    changes that do not change the meaning of the XML can I make; what
    must I avoid?  If this can be answered by a reference to a
    specific section of another document that would be great.

2)  Should I strip a digital signature if I'm going to invalidate it?  

3) Should I provide a mechanism for a client to indicate that it would
    prefer a post fail than that digital signatures be broken?  (This
    especially seems potentially useful for encryption)?

4) It's probably desirable to recommend that servers not break digital
   signatures unless they are modifying content.

Sam Hartman
Security Area Director

---

From: Tim Bray <[email-masked]>
Date: Sun, 17 Jun 2007 12:57:14 -0700

I think Sam's perception that the WG didn't do much work on this is  
correct.  Probably for reasons having to do with server/client  
asymmetry, see below.

>     specific section of another document that would be great.

This turns out to be pretty hard.  It is the server's responsibility:
- to ensure that each entry has a globally unique atom:id element
- to ensure that each entry has an accurate atom:updated timestamp

So to preserve dig-sig, the client would be required to generate a  
globally-unique ID and be real careful about time-stamping, and the  
server would have to trust it.  Practically speaking, I think you'd  
need an out-of-band signal saying that the client is trying to  
achieve this effect.

More generally, in APP, the relationship between client and server is  
really unequal.  Basically, a client hands some data to the server  
and requests a best effort to store it in a useful and minimally- 
surprising way.  This is based on observation of real-world web  
publishing systems; server implementors are typically flatly  
unwilling to promise too much.  My perception is that of all the APP  
server implementations I've seen (and as the author of a testing  
tool, I've seen lots) exactly none would have any chance of  
preserving dig-sigs.

I haven't thought this through fully, but it may be the case that APP  
is inherently unsuited for publishing activities where client  
signature preservation is a requirement.  Hmm, now I'm thinking about  
special arrangements for preserving signatures on "payload" elements:  
title/category/summary/content.

> 2)  Should I strip a digital signature if I'm going to invalidate it?

I would think so.

>     especially seems potentially useful for encryption)?

I don't think we understand the problem well enough yet to specify a  
solution.

>    signatures unless they are modifying content.

The trouble is that at the moment, *every* server implementation  
modifies content.  -Tim

---

From: Lisa Dusseault <[email-masked]>
Date: Sun, 17 Jun 2007 13:17:59 -0700

I did some thinking about this since it came up in IESG evaluation  
and concluded that for the moment, there's no way for the client to  
reliably and interoperably publish client-signed entries.  We should  
start by stating that in atompub (because I am guessing we're going  
to standardize a mechanism right now).

If there is a requirement that clients understand signed entries,  
then we can interoperably have the *server* sign entries and that may  
be slightly useful.  Not only is it slightly useful if the server  
signs with its own key, it also allows for some non-standard  
backchannel between publishing clients and servers, in which clients  
sign with their own keys.  Although the signing mechanism would be  
non-standard in that case, all existing clients would be required to  
understand signatures  so this optional authoring feature  would not  
break general publishing interoperability.

One way to do client signing in the future is for clients to start by  
POSTing signed entries.  If this is how it is likely to work in the  
future, then today we probably want to decide what "older" servers  
should do in the future -- reject signed entries, accept them  
unchanged and still signed (unlikely),  strip the signature or  
invalidate the signature.

Another way to do client signing in the future is for clients to POST  
unsigned entries, allow the server to assign timestamps and atomIDs  
and make other changes, and then sign the result.  The server could  
allow PUT or some other mechanism to overwrite an unsigned entry with  
a signed entry provided that the server-controlled content remains  
the same (need to think about updated value, of course).  If this is  
the way we expect things to work in the future, then there's less  
interop requirements to think about today.

Lisa

On Jun 17, 2007, at 12:57 PM, Tim Bray wrote:

> More generally, in APP, the relationship between client and server  
> is really unequal.  Basically, a client hands some data to the  
> server and requests a best effort to store it in a useful and  
> minimally-surprising way.  This is based on observation of real- 
> world web publishing systems; server implementors are typically  
> flatly unwilling to promise too much.  My perception is that of all  
> the APP server implementations I've seen (and as the author of a  
> testing tool, I've seen lots) exactly none would have any chance of  
> preserving dig-sigs.
>
> I haven't thought this through fully, but it may be the case that  
> APP is inherently unsuited for publishing activities where client  
> signature preservation is a requirement.  Hmm, now I'm thinking  
> about special arrangements for preserving signatures on "payload"  
> elements: title/category/summary/content.
>
> I don't think we understand the problem well enough yet to specify  
> a solution.
>

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Sun, 17 Jun 2007 22:21:24 +0200

>    specific section of another document that would be great.

This might not be a good question to answer. What is more interesting is
what servers are likely to change, so clients can filter those parts out
when creating the signature. Some things like choice of quote marks for
attribute values are universally understood to be irrelevant in XML pro-
cessing, and you cannot make any changes beyond that without risking to
break the signature unless you understand the signature method. I do not
think it would be useful to point that out, and saying much more might
be more confusing than useful.

On the other hand, it might be that server implementations leave, say,
author information, title, and textual content of an entry untouched,
knowing that clients might just sign those bits and leave the rest free
to change by the server. I am not sufficiently familiar with this to say
whether there is some good recommendation to make though, or whether it
might be better to put this into a later document when we have more im-
plementation experience. If there is nothing to recommend yet, it would
be best to not address this question.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: James M Snell <[email-masked]>
Date: Sun, 17 Jun 2007 13:41:10 -0700

Tim Bray wrote:
> [snip]
> server would have to trust it.  Practically speaking, I think you'd need
> an out-of-band signal saying that the client is trying to achieve this
> effect.

Unless the server is storing the exact XML sent to it by the client
preserving the integrity of any included digital signatures becomes damn
near impossible.  For instance, I have several implementations that
accept an entry from a client, shred the content out into a relational
database, and reconstructs the entry when requested.  While the entry
that is returned to the client will generally have the same content,
title, etc, there will be enough changes that any digital signature
included in the original post would be worthless -- elements will be
presented in a different order; the atom:id, atom:updated: atom:author
information will be different; extension elements may have been added or
removed; attributes may be added or removed or shifted around; the
server may apply content filters to the text; etc.

In effect, a digital signature in an entry being sent from the client to
 the server is only guaranteed to cover that specific representation --
that is, only the representation is signed, and not the resource.

> [snip]
> My perception is that of all the APP server implementations I've seen
> (and as the author of a testing tool, I've seen lots) exactly none would
> have any chance of preserving dig-sigs.

Unless there is an explicit promise by the server that dsig's will be
preserved there is no reasonable assumption a client can make other than
 they will not be preserved.

> [snip]
> I haven't thought this through fully, but it may be the case that APP is
> inherently unsuited for publishing activities where client signature
> preservation is a requirement.  Hmm, now I'm thinking about special
> arrangements for preserving signatures on "payload" elements:

I think it depends entirely on the scenario.  It is easy to imagine a
case where a dsig in the entry is used by the server to verify the
integrity of the PUT/POST operation rather than as some piece of
metadata to be preserved.

>> 2)  Should I strip a digital signature if I'm going to invalidate it?

Absolutely.

> I don't think we understand the problem well enough yet to specify a

This is a general problem that applies for more than just dsigs.  Should
we provide a mechanism for a client to indicate that it would prefer a
post fail if a particular extension cannot be supported?  Or if a
particular content type cannot be supported? We have the APP features
draft as a way of allowing the server to signal it's capabilities.
Would it not be enough for the server to state whether or not dsigs will
be preserved?  The client could look at that and make a determination
about what to do.

> The trouble is that at the moment, *every* server implementation

This would be an absolutely terrible recommendation.  In APP, the server
is control. It can change whatever it wants any time it wants.  The
client needs to be aware of that make and make decisions accordingly.
What we need is a way of allowing the server to tell the client what it
will do, which is why the features draft exists.

- James

---

From: Sylvain Hellegouarch <[email-masked]>
Date: Sun, 17 Jun 2007 21:47:33 +0100

Lisa Dusseault a écrit :
>
> I did some thinking about this since it came up in IESG evaluation and 
> concluded that for the moment, there's no way for the client to 
> start by stating that in atompub (because I am guessing we're going to 
> standardize a mechanism right now).
>
> If there is a requirement that clients understand signed entries, then 
> we can interoperably have the *server* sign entries and that may be 
> slightly useful.  Not only is it slightly useful if the server signs 
> with its own key, it also allows for some non-standard backchannel 
> between publishing clients and servers, in which clients sign with 
> their own keys.  Although the signing mechanism would be non-standard 
> in that case, all existing clients would be required to understand 
> signatures  so this optional authoring feature  would not break 
> general publishing interoperability.

That'd be easier for sure but how to deal with potential server to 
server exchange?

- Sylvain

---

From: James M Snell <[email-masked]>
Date: Sun, 17 Jun 2007 13:51:11 -0700

Lisa Dusseault wrote:
> concluded that for the moment, there's no way for the client to reliably
> and interoperably publish client-signed entries.  We should start by
> stating that in atompub (because I am guessing we're going to

It depends entirely on what you mean by "publish".  If you mean have the
server store exactly what the client sent and serve it back up with
perfect fidelity, then you're right.  Thing is, that's not what APP was
intended to do.

Because of Atom's must-ignore semantics, all APP servers should be able
to work with digitally signed entries sent by a client on PUT or POST.
What it does with those signatures is completely up the server.  Whether
or not those signatures and the content they cover is preserved in a way
that does not invalidate the signature is completely up to the server
implementation.  This is not an interoperability problem.  It's a client
expectation problem.  If the client expects to have the digital
signatures preserved, it better darn well know what the server will do
with 'em before it sends 'em.

> between publishing clients and servers, in which clients sign with their
> own keys.  Although the signing mechanism would be non-standard in that
> case, all existing clients would be required to understand signatures 
> so this optional authoring feature  would not break general publishing
> interoperability.

There is no need for such a requirement.  RFC4287 already states that
entries and feeds can be digitally signed.  It also already states that
unknown extensions MUST be ignored.  That's enough.  A server can sign
an entry, a client must either know how to deal with the signature or
must know how to ignore it.  There's nothing else APP needs to say on
the matter.

> should do in the future -- reject signed entries, accept them unchanged
> and still signed (unlikely),  strip the signature or invalidate the
> signature.
> 
> unsigned entries, allow the server to assign timestamps and atomIDs and
> make other changes, and then sign the result.  The server could allow
> PUT or some other mechanism to overwrite an unsigned entry with a signed
> entry provided that the server-controlled content remains the same (need
> to think about updated value, of course).  If this is the way we expect
> things to work in the future, then there's less interop requirements to
> think about today.

What exactly are you trying to achieve with this?

- James

---

From: Lisa Dusseault <[email-masked]>
Date: Sun, 17 Jun 2007 21:47:08 -0700

On Jun 17, 2007, at 1:51 PM, James M Snell wrote:

>> unchanged

Trying to figure out if there are any additional requirements or  
decisions or clarifications to make now, that would make design and  
interoperability much easier when (if) a group gets around to  
standardizing a way to do client signatures.  It's not worth much  
work now (present value of money/time and all that) but it's worth a  
bit of thought.

Lisa

---

From: James M Snell <[email-masked]>
Date: Sun, 17 Jun 2007 23:14:01 -0700

Sorry, I wasn't clear. I was asking what the technical objective would
be behind your suggestions. When a client POSTs a digitally signed entry
to the server, what is the intent?  Is the dsig part of the  content
that the client would like to have preserved? Or is the dsig some form
of message level integrity check the server can use to make sure the
entry has not been messed with in transit?  Or is the dsig something
else?  So far this discussion seems to be focusing on the idea that the
dsig is part of the content.  This group has well established that when
it comes to the content of an entry, the server is in complete control
and can make any change it wants to make, period, which would presumably
include invalidating signatures.

Or, are digital signatures in an entry some kind of special entity that
MUST be treated differently than other kinds of extensions?  Does the
presence of a signature in an entry hold some kind of special meaning
that the server MUST be capable of understanding and dealing with?

>>> and still signed (unlikely),  strip the signature or invalidate the

If dsig's are treated as Just-Another-Extension, there is already an
established processing model that is more than adequate.  RFC4287 states
that unknown extensions MUST be ignored.  A client could choose to
digitally sign every entry is produces; a server that receives those
entries could simply ignore the signature if it is not capable of doing
anything with it.  If some other server chooses to do something with
those signatures, then cool. "Older" servers would just continue
ignoring those signatures leaving the responsibility on the client to
decide if that's an acceptable behavior.

>>> things to work in the future, then there's less interop requirements to

Again, the current must-ignore model provides a perfectly adequate
approach to dealing with all this.   None of this becomes an issue
unless you want to assign some kind of special meaning to a digital
signature in an entry -- that is, making it more than
Just-Another-Extension.

- James

> standardizing a way to do client signatures.  It's not worth much work
> now (present value of money/time and all that) but it's worth a bit of
> thought.
> 
> Lisa

---

From: Tim Bray <[email-masked]>
Date: Sun, 17 Jun 2007 23:34:25 -0700

The more I think about this, the more the right answer seems  
obvious.  The notion of a client signing a whole Atom entry is just  
fundamentally bogus, because some parts of it are actually owned by  
the server (id, update-timestamp).  On the other hand, the notion of  
a client signing the payload (title/author/categories/summary/ 
content) is interesting and worth exploring.  Fortunately, Atom & APP  
are flexible enough that anyone can try a few things out without  
breaking any implementations.  Unfortunately, nobody has ever  
implemented anything like this that I know of, and I don't even know  
of any applications that need it, so it''s *way* too early to try to  
specify The Right Thing To Do.

So.... I would address Sam's points like so:

Expand 15.5 to point out all the problems that have emerged in this  
discussion and which make client-originated dig-sig a non-starter for  
APP.  Further point out that server-side dig-sig, per RFC4287 rules,  
might make all sorts of sense in certain apps and is perfectly  
technically feasible; I now think it's a bug that the spec leaves you  
with the impression that something about server-side digsig might not  
work.  Further point out that signature elements can freely be  
inserted in to-be-posted entries by clients and are guaranteed not to  
break the server because of our MustIgnore rule, and make it clear  
that the door is open to payload signing.

The idea is that down the road, when there's a body of experience and  
we know what the Best Practices are, someone can spec an APP  
Extension to capture them.  -Tim

---

From: James M Snell <[email-masked]>
Date: Sun, 17 Jun 2007 23:47:06 -0700

FWIW, I have implemented a prototype in which a server only accepts
entries with valid digital signatures.  The server used those signatures
to verify the integrity of the payload but did not attempt to preserve
the signature.  That said, however, you are definitely right about it
being too early to specify the Right Thing To Do.

- James

Tim Bray wrote:
> [snip]
> Unfortunately, nobody has ever implemented anything like this that I
> know of, and I don't even know of any applications that need it, so
> it''s *way* too early to try to specify The Right Thing To Do.
> [snip]

---

From: Antone Roundy <[email-masked]>
Date: Mon, 18 Jun 2007 09:15:06 -0500

Yeah, I'm still lurking here.

First, let me state the obvious: a signature enables you to verify that 
the data you received hasn't been changed since it was signed by a 
particular entity.  It seems to me that there are a few things we might 
want to do with that ability:

1) Verify the integrity of data on a "single hop" (no need to preserve 
the signature).

2) Verify that the data is as it was when produced by the original 
creator (would require preservation of the signature).

3) #1 PLUS allow whoever signed the data to claim that what it received 
was signed and that it validated the signature.

 From what others have said, #2 doesn't sound possible.  #1 clearly is 
possible.  So what about #3?  Might something like this be done?

A) The client signs the data and sends it to the server.

B) The server validates and discards the signature, and adds an element 
like this:

<ext:i-got-this-signed-from who="some sort of identifier" who-am-i="some 
sort of identifier" seq="1" />

I don't know enough about digital signatures to know what an appropriate 
identifier might be -- perhaps a URL from which their public key could 
be retrieved or something?  @seq is there to identify who got the data 
from whom in what order.

C) The server signs the whole package including the added element and 
sends it on to whoever's next.

D) Whoever gets the data next repeats B & C, and so on, so that at any 
point, whoever receives the data can verify that the entire package came 
from some specific entity, and also trace the data's route backwards to 
its source.

The obvious weakness of this approach is that the 
"i-got-this-signed-from" elements could be forged.  But if you trust 
that the entity that signed the data that you received wouldn't forge 
them, and if you happen to know and trust all the other entities who's 
@who-am-i's are in there, then you should be able to establish SOME 
level of trust in the data.

Additionally, whoever inserts an "i-got-this-signed-from" COULD sign it 
and that signature could be carried forward. But that might be better 
not done than done since it may give a false sense of security, since 
all that it would really verify is that whoever inserted that 
"i-got-this-signed-from" and its signature has at some point seen an 
"i-got-this-signed-from" created by @who-am-i for @who with that 
particular @seq value.

Antone

---

From: James M Snell <[email-masked]>
Date: Mon, 18 Jun 2007 08:07:33 -0700

> possible.  So what about #3?  Might something like this be done?

#2 is possible so long as the server is implemented to do it.  The
client cannot make any blind assumptions about what the server will do.
 Before the client attempts to interact with the server, it had better
know what the server will do.

- James

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 18 Jun 2007 08:10:58 -0700

At 11:34 PM -0700 6/17/07, Tim Bray wrote:
>the server (id, update-timestamp).

Given some of the other comments in this thread, I disagree. A server 
might want to only accept a signed entry in order to be sure that the 
content was generated by someone the server trusts. This can be 
orthogonal to the authentication used in order to post to the server.

>discussion and which make client-originated dig-sig a non-starter 
>for  APP.

Disagree; see above.

---

From: James M Snell <[email-masked]>
Date: Mon, 18 Jun 2007 08:55:33 -0700

This is very rough but is this at least a step in the right direction?

15.5.  Digital Signatures and Encryption

   Atom Entry and Feed Documents might contain XML Digital Signatures
   [REC-xmldsig-core] and might be encrypted using XML Encryption
   [REC-xmlenc-core] as specified in Section 5 of [RFC4287].

   When servers or clients receive digitally signed or encrypted Entry
   Documents, they are under no obligation to preserve the integrity of
   the signatures or the encryption. They are allowed to modify member
   resources in ways that can invalidate signatures.  If such
   modifications are made, it is recommended that any invalid signatures
   be removed.

   A server can require that Entry Documents received from a client,
   either via POST or PUT, be digitally signed with a valid
   signature or are encrypted, or both.  How such requirements are
   communicated to the client are considered out of scope for this
   specification.

   Signatures and encrypted elements are considered to be foreign markup
   within an Atom document and are required to be handled according to
   the rules specified in Sections 5 and 6.3 of [RFC4287].

- James

Tim Bray wrote:
> 
> The more I think about this, the more the right answer seems obvious. 
> The notion of a client signing a whole Atom entry is just fundamentally
> bogus, because some parts of it are actually owned by the server (id,
> update-timestamp).  On the other hand, the notion of a client signing
> the payload (title/author/categories/summary/content) is interesting and
> worth exploring.  Fortunately, Atom & APP are flexible enough that
> anyone can try a few things out without breaking any implementations. 
> work.  Further point out that signature elements can freely be inserted
> in to-be-posted entries by clients and are guaranteed not to break the
> server because of our MustIgnore rule, and make it clear that the door
> is open to payload signing.
> 
> The idea is that down the road, when there's a body of experience and we
> know what the Best Practices are, someone can spec an APP Extension to
> capture them.  -Tim
> 
>

---

From: Tim Bray <[email-masked]>
Date: Mon, 18 Jun 2007 08:49:02 -0700

On Jun 18, 2007, at 8:10 AM, Paul Hoffman wrote:

>> obvious.  The notion of a client signing a whole Atom entry is  
>> just fundamentally bogus, because some parts of it are actually  
>> owned by the server (id, update-timestamp).
>
> Given some of the other comments in this thread, I disagree. A  
> server might want to only accept a signed entry in order to be sure  
> that the content was generated by someone the server trusts. This  
> can be orthogonal to the authentication used in order to post to  
> the server.

OK, let me re-phrase slightly.  The idea of a client expecting a  
digital signature on a whole entry to survive the publishing process  
is bogus.

>> Expand 15.5 to point out all the problems that have emerged in  
>> this discussion and which make client-originated dig-sig a non- 
>> starter for  APP.
>
> Disagree; see above.

I think that most of what I wanted to put in makes sense; time to  
stop hand-waving and draft some language.  -Tim

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Mon, 18 Jun 2007 18:16:15 +0200

>   modifications are made, it is recommended that any invalid signatures

This should be "Servers should remove invalidated signatures". However,
this may give the false impression that support for signatures is re-
quired, and does not address what to do if the server does not know if
a signature has been invalidated. The phrasing of "the integrity of the
signatures or the encryption" is also easily misread.

>   communicated to the client are considered out of scope for this

s/are con/is con/.

>   the rules specified in Sections 5 and 6.3 of [RFC4287].

I don't think it's useful to repeat this information here, "Handling of
signatures and encrypted elements in Atom documents is discussed in
sections 5 and 6.3 of [RFC4287]" would be better.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: James M Snell <[email-masked]>
Date: Mon, 18 Jun 2007 09:43:21 -0700

Slightly better?

   Atom Entry and Feed Documents might contain XML Digital Signatures
   [REC-xmldsig-core] and might be encrypted using XML Encryption
   [REC-xmlenc-core] as specified in Section 5 of [RFC4287]. Handling of
   signatures and encrypted elements in Atom documents is discussed in
   sections 5 and 6.3 of [RFC4287].

   When servers or clients receive digitally signed or encrypted Entry
   Documents, they are under no obligation to preserve signatures or
   encrypted elements. They are allowed to modify member resources in
   ways that can invalidate signatures.  If such modifications are made,
   it is strongly recommended that invalid signatures be removed.

   A server can require that Entry Documents received from a client,
   either via POST or PUT, be digitally signed with a valid
   signature or are encrypted, or both.  How such requirements are
   communicated to the client is considered out of scope for this
   specification.

- James

---

From: Lisa Dusseault <[email-masked]>
Date: Mon, 18 Jun 2007 09:52:32 -0700

On Jun 18, 2007, at 9:16 AM, Bjoern Hoehrmann wrote:

> a signature has been invalidated.

If there's any doubt about whether support for signatures is required  
-- James says yes, and Bjoern says no -- we need to be clearer in the  
publishing protocol document.

Otherwise, a server implementor could decide that "since I don't sign  
entries I don't need any code to handle signatures".

Lisa

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Mon, 18 Jun 2007 19:28:11 +0200

* Julian Reschke wrote:
>As far as I can tell, APP doesn't require support for signatures, nor 
>did James say so (pointer?).

The text said that servers SHOULD remove invalidated signatures. You can
not do that unless you can determine that a signature has indeed been
invalidated and know how to remove such a signature. So support would be
required unless <rfc 2119 exceptions>.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 18 Jun 2007 10:57:33 -0700

At 9:43 AM -0700 6/18/07, James M Snell wrote:
>    If such modifications are made,

We have gone out of our way in APP not to tell servers what to do 
with received content. Why should we start here? Also, why should a 
server have to figure out whether the content was changed?

Can this sentence be removed?

---

From: James M Snell <[email-masked]>
Date: Mon, 18 Jun 2007 11:02:42 -0700

I've got no problem with that.

- James

Paul Hoffman wrote:
> We have gone out of our way in APP not to tell servers what to do with
> received content. Why should we start here? Also, why should a server
> have to figure out whether the content was changed?
>

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Mon, 18 Jun 2007 20:13:48 +0200

>server have to figure out whether the content was changed?

I am not sure I understand the second question. If the server receives a
signed document and does not modify the document there is no problem. If
it does modify it, then it knows the content has been changed. The first
question is easy to answer, if you have neither of

  * clients don't send signed documents unless server supports them
  * servers don't keep signatures unless they don't modify documents

as policy, a client might optimistically send a signed document and the
server ends up serving documents with invalidated signatures. That'd be
bad as recieving clients would give false alarms, reducing the overall
utility of digital signatures.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Julian Reschke <[email-masked]>
Date: Mon, 18 Jun 2007 19:20:51 +0200

Lisa Dusseault wrote:
> If there's any doubt about whether support for signatures is required -- 
> James says yes, and Bjoern says no -- we need to be clearer in the 
> ...

Best regards, Julian

---

From: "Hilarie Orman" <[email-masked]>
Date: Mon, 18 Jun 2007 12:40:44 -0600

The client can use signatures for two purposes: to convince the server
that the data is authentic, and/or to convince a third-party that the data*
is authentic.  In the first case, the "data" might be considered to be
the entirety of the message/entry/etc.  In the second case, the
"data*" might be a subset of the "data".  So, one could envision
something like

  SIG1 = DSIG(Kclient, some_data | data* | some_more_data)  
  SIG2 = DSIG(Kclient, data*)

The server may want to use its own signature for what it publishes,
so it might publish

  SIG3 = DSIG(Kserver, modified(some_data, some_more_data))
but it might also publish
  client_identity, data* and SIG2 
so that a third party could validate the authenticity of data* wrt to
the client (assuming that the client wants his identity associated
with data*).

It can be tricky to keep data* and SIG2 in a form that allows a third-party
to validate it, and thus, it is probably necessary to keep data* and SIG2
as opaque blobs and let the third-party tackle the problem of verifying
that displayed(data*) has some reasonable relationship to data* itself.

Hilarie

---

From: "Joe Gregorio" <[email-masked]>
Date: Mon, 18 Jun 2007 16:54:11 -0400

> digital signature on a whole entry to survive the publishing process

Agreed. I never considered the signing and encrypting of Atom
Entries or Feeds to last beyond a one way trip between
the client and the server. If that's going to be a common
misunderstanding then we should add
more verbiage to clear up that point.

   -joe

-- 
Joe Gregorio        http://bitworking.org

---

From: "A. Pagaltzis" <[email-masked]>
Date: Mon, 18 Jun 2007 23:17:46 +0200

> Slightly better?

How about something along these lines:

    Atom Entry and Feed Documents can contain XML Digital
    Signatures [REC-xmldsig-core] and can be encrypted using XML
    Encryption [REC-xmlenc-core] as specified in Section 5 of
    [RFC4287]. Handling of signatures and encrypted elements in
    Atom documents is discussed in sections 5 and 6.3 of [RFC4287].

    Neither servers nor clients are under any obligation to
    support XML Digital Signatures and XML Encryption, although a
    server MAY require that Entry Documents received from a client
    be digitally signed with a valid signature or be encrypted, or
    both.

    Servers are free to modify the contents of an Entry Document
    in any way, which can lead to inadvertent invalidation of
    signatures. If the server can detect a thusly invalidated
    signature, it is strongly encouraged that it be discarded
    prior to publishing.

    In all cases, it is considered out of scope for this
    specification how support and/or requirements for digital
    signing and encryption are communicated between server and
    client.

And a tentative addition I wanted to include above the last
paragraph, but which I’m not yet quite sure about:

    Clients wishing to publish digitally signed and/or encrypted
    content should consider that servers are especially likely to
    modify particular aspects of an Entry Document, such as
    "atom:id" and "atom:updated", but not necessarily others,
    such "atom:title" or "atom:content". Signing and/or
    encrypting selectively may therefore be a better strategy
    than doing so for the Entry Document as a whole.

I’m rather unhappy with the wording and length of that, though.

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

---

From: Julian Reschke <[email-masked]>
Date: Mon, 18 Jun 2007 23:35:30 +0200

> utility of digital signatures.

Björn,

in this case I think we'd need to define what "changing" a document 
means. What aspects need to be preserved? Comments? PIs? Namespace 
prefixes? Whitespace?

Best regards, Julian

---

From: James M Snell <[email-masked]>
Date: Mon, 18 Jun 2007 14:28:36 -0700

I'm happy with everything here except your last proposed addition, which
I do not believe is necessary or appropriate.

- James

---

From: Julian Reschke <[email-masked]>
Date: Mon, 18 Jun 2007 23:36:55 +0200

> required unless <rfc 2119 exceptions>.

I don't see a SHOULD, but maybe I'm not looking at the same proposal 
you're looking it.

Best regards, Julian

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Tue, 19 Jun 2007 00:04:01 +0200

>means. What aspects need to be preserved? Comments? PIs? Namespace 

Changing a document means changing it in a way that allows RFC 3275
implementations to generate a different signature after the change.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Julian Reschke <[email-masked]>
Date: Tue, 19 Jun 2007 10:27:14 +0200

> entries I don't need any code to handle signatures".

I was just going to note that *if* we make it mandatory to do something 
wrt signatures, we need to reference xml-dsig & friends as normatively. 
Turns out, we already do. Is this really intended & correct?

Best regards, Julian

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 19 Jun 2007 12:28:40 -0700

The following is my take, as document shepherd, of a proposed answer 
to Sam's original request. I'm taking into account his example 
questions (which elicited some good discussion on the list), a few 
sets of proposed wording, and some very good commentary about the 
problems. This suggested text tries to be concise and, because it is 
Security Considerations, tries to help implementers understand the 
security issues of APP.

Please say whether or not this wording works for you. Thanks!

--Paul Hoffman

Atom Entry and Feed Documents can contain XML Digital Signatures 
[REC-xmldsig-core] and can be encrypted using XML Encryption 
[REC-xmlenc-core] as specified in Section 5 of [RFC4287]. Handling of 
signatures and encrypted elements in Atom documents is discussed in 
sections 5 and 6.3 of [RFC4287].

Neither servers nor clients are under any obligation to support 
encryption and digital signature of entries or feeds, although it is 
certainly possible that in some installations, clients or servers may
require signing or encrypting of the documents exchanged in the Atom protocol.

Because servers are allowed (and in some cases required) to modify 
the contents of an Entry Document before publishing it, a client that 
signs a Entry Document should only do so with the intention of the 
server possibly validating the submission; the client cannot assume 
that the signature will be valid when viewed by a third party, or 
that the server will even publish the client's signature.

A server is allowed to strip client-applied signatures, to strip 
client-applied signatures and then re-sign with its own public key, 
and to oversign an entry with its own public key. The meaning to a 
third party of a signature applied by a server is the same as a 
signature from anyone, as described in [RFC4287]. The method for a 
server to indicate to a third party whether or not the client signed 
an Entry Document is by including the client's signature in the 
published entry, even though that signature is likely to be invalid.

---

From: James M Snell <[email-masked]>
Date: Tue, 19 Jun 2007 12:42:54 -0700

> require signing or encrypting of the documents exchanged in the Atom

Fine up to here.

> 
> Because servers are allowed (and in some cases required) to modify the
> contents of an Entry Document before publishing it, a client that signs
> a Entry Document should only do so with the intention of the server
> possibly validating the submission; the client cannot assume that the
> signature will be valid when viewed by a third party, or that the server
> will even publish the client's signature.
> 

This gets too close to dictating implementation behavior.  There may be
many reasons for having a client sign an entry that goes beyond
validating the submission.

> client-applied signatures and then re-sign with its own public key, and
> to oversign an entry with its own public key. The meaning to a third
> party of a signature applied by a server is the same as a signature from
> anyone, as described in [RFC4287]. The method for a server to indicate
> to a third party whether or not the client signed an Entry Document is
> by including the client's signature in the published entry, even though
> that signature is likely to be invalid.
> 

I preferred Aristotle's suggested text (posted 6/18)

- James

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Tue, 19 Jun 2007 21:56:07 +0200

>that the server will even publish the client's signature.

Could you point out where the draft requires making changes? I so far
assumed you can make a conforming implementation that does little but
passing through the content I want to publish as-is, your text seems
to rule that out. If it is possible to make an APP implementation that
almost always keeps my content unmodified, clients that know they are
talking to such a server should not violate the "should only".
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Tim Bray <[email-masked]>
Date: Tue, 19 Jun 2007 13:17:08 -0700

On Jun 19, 2007, at 12:42 PM, James M Snell wrote:

>> the

Huh?  Why would you go to the (nontrivial) trouble of doing a  
signature if you didn't want someone to check it?  And who other than  
the server could?  The phrase "client" here clearly means "software  
behavior in the context of the Atom Protocol", and if you're signing  
it in the context of the Atom Protocol, the signature couldn't  
possibly be useful, in the context of the protocol, to any party  
other than the server you're sending it to.  -Tim

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 19 Jun 2007 13:21:47 -0700

>validating the submission.

Does changing "should only do so" to "can do so" help alleviate that 
concern? If not, alternate wording would be appreciated.

>I preferred Aristotle's suggested text (posted 6/18)

It did not hit all the points that I thought Sam was asking for. The 
exercise at the moment is to come up with wording that is both useful 
to the reader and covers the concerns of the AD who brought up the 
point.

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Tue, 19 Jun 2007 22:33:49 +0200

* Tim Bray wrote:
>Such an implementation would be possible, but would be an exotic  
>corner case.  Client implementers SHOULD NOT expect digsigs to  
>survive the operation of a typical Atom server implementation, and  
>Sam Hartman is correct that we need to be clear about this.  -Tim

I agree, but then it seems "should only do so with the intention of the
server possibly validating the submission" can safely be extended by
saying clients may do so for other reasons if the server is known to
support that. Saying what you say above, clients should not expect this
to work unless they have specific information about the server would be
sufficient.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Tim Bray <[email-masked]>
Date: Tue, 19 Jun 2007 13:19:48 -0700

On Jun 19, 2007, at 12:56 PM, Bjoern Hoehrmann wrote:

> Could you point out where the draft requires making changes?

The atom:id has to be globally unique, and the server has to manage  
app:edited.

> I so far
> to rule that out.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 19 Jun 2007 13:34:25 -0700

>Could you point out where the draft requires making changes?

First, let me point out that the contrapositive is covered in Section 10:

    Clients MUST NOT assume that an Atom Entry returned in the Feed is a
    full representation of an Entry Resource and SHOULD perform a GET on
    the URI of the Member Entry before editing it.

>passing through the content I want to publish as-is, your text seems

It is ruled out if publishing a feed would create an invalid feed, 
such as one with non-unique atom:id values. That is, the server is 
responsible for following the MUST rules of the Atom format when it 
is publishing, even if the client gives it something that would not 
follow those MUSTs.

---

From: James M Snell <[email-masked]>
Date: Tue, 19 Jun 2007 13:50:07 -0700

My problem is with the "should only do so" and "validating the
submission" text.

I agree that, for the most part, the a client-signed signature is likely
only going to be useful for the server but we honestly do not have
enough experience to say that for certain -- at least not enough to
justify a "should".

I'd be more comfortable with something along these lines:

  Because servers allow allowed (and in some cases required) to modify
  the contents of an Entry Document before publishing it, signatures
  within an entry will likely only be useful to the server to which it
  is being sent. Clients cannot assume that the signature will be valid
  when viewed by a third part, or that the server will event publish
  client's signature.

- James

Tim Bray wrote:
> Huh?  Why would you go to the (nontrivial) trouble of doing a signature
> if you didn't want someone to check it?  And who other than the server
> could?  The phrase "client" here clearly means "software behavior in the
> context of the Atom Protocol", and if you're signing it in the context
> of the Atom Protocol, the signature couldn't possibly be useful, in the
> context of the protocol, to any party other than the server you're
> sending it to.  -Tim
>

---

From: Tim Bray <[email-masked]>
Date: Tue, 19 Jun 2007 13:59:50 -0700

>   when viewed by a third part, or that the server will event publish

I think that's an improvement.  -T

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Tue, 19 Jun 2007 23:14:47 +0200

>concern? If not, alternate wording would be appreciated.

It seems to me we are just trying to say: because ... clients should not
sign entry documents unless the server is known to be able to handle the
signed document in a manner consistent with the client's expectations
[specifically, it cannot assume ...].
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 19 Jun 2007 15:31:10 -0700

>[specifically, it cannot assume ...].

So far, you are the only one who has suggested that the client needs 
to know whether the server can handle the signed document. Unless 
others agree with you, we should stay with the current wording.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 19 Jun 2007 15:21:12 -0700

>I think that's an improvement.  -T

s/third part/third party/
s/event publish/even publish the/

---

From: James M Snell <[email-masked]>
Date: Tue, 19 Jun 2007 15:54:57 -0700

> s/event publish/even publish the/

s/allow allowed/are allowed/

damn... who typed this :-)

- james

---

From: "A. Pagaltzis" <[email-masked]>
Date: Wed, 20 Jun 2007 01:26:09 +0200

>   when viewed by a third part, or that the server will event publish

Sounds good.

Regards,

---

From: "A. Pagaltzis" <[email-masked]>
Date: Wed, 20 Jun 2007 01:43:34 +0200

* Paul Hoffman <[email-masked]> [2007-06-19 21:40]:
> The method for a server to indicate to a third party whether or
> not the client signed an Entry Document is by including the
> client's signature in the published entry, even though that
> signature is likely to be invalid.

I strongly disagree with this. As a consumer, I have no possible
way to know whether an invalid signature is there because

• the publishing client included it
• the server made up a signature to feign signing by the client
• a third party tampered with the entry between the server and me

Therefore as a consumer I would never ever assume that an invalid
signature meant anything else than that the signature on this
entry is not valid.

Encouraging servers to knowingly include signatures they have
invalidated is

Just.

Wrong.

It dilutes the value of signatures as a whole by making it harder
for the consumer to decide what an invalid signature means, which
by extension also blurs the trust conferred by a valid signature.

It’s fine for the server to be signature-agnostic.

If the server is not, though, then it really should strip the
signature if it knows it has invalidated it. Note that my
proposed text said “strongly encouraged”, not “SHOULD”. After
all, it is not an interop concern, nor do I desire to dictate
server behaviour.

However, I do think this particular implementation choice
makes a lot of sense and should be the default choice for
server implementors who don’t have specific reason to do
things otherwise. And I think the spec should nudge them in
that direction.

Regards,

---

From: "Bob Wyman" <[email-masked]>
Date: Tue, 19 Jun 2007 19:43:16 -0400

I think it should be remembered that signed Atom entries *do* make a
great deal of sense within the context of the Atom formatted documents
-- whatever difficulties that they may cause in the protocol
discussion.

One important use-case discussed during the definition of the Atom
syntax was that of aggregate or synthetic feeds. (i.e. feeds that are
composed of entries taken from more than one other feed).  The current
syntax allows one to preserve a signed entry in an aggregate feed --
as long as the signed entry had an atom:source element when it was
originally signed.

If the protocol can't preserve the signature associated with an entry
provided by a client, then it would seem that the protocol can't be
used to construct an aggregated feed that preserves the integrity of
properly signed atom entries extracted from other feeds. That is
unfortunate and seems extremely non-optimal.

bob wyman

---

From: "A. Pagaltzis" <[email-masked]>
Date: Wed, 20 Jun 2007 01:45:08 +0200

* Paul Hoffman <[email-masked]> [2007-06-20 00:40]:
> >>  Because servers allow allowed (and in some cases required)
> >>  to modify the contents of an Entry Document before
> >>  publishing it, signatures within an entry will likely only
> >>  be useful to the server to which it is being sent. Clients
> >>  cannot assume that the signature will be valid when viewed
> >>  by a third part, or that the server will event publish
> >>  client's signature.
> >

Also:

:-)

Regards,

---

From: James M Snell <[email-masked]>
Date: Tue, 19 Jun 2007 17:02:47 -0700

The main point of this discussion is that what happens is completely up
to the server implementation.  It is entirely possible for a particular
server to do exactly what you are suggesting.  However, it is impossible
for a client to make any assumptions about how a server will treat
signed entries without prior specific knowledge of that server.

- James

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 19 Jun 2007 17:40:09 -0700

At 1:43 AM +0200 6/20/07, A. Pagaltzis wrote:
>* the publishing client included it
>* the server made up a signature to feign signing by the client
>* a third party tampered with the entry between the server and me
>

Fully agree so far.

>Encouraging servers

Stop right there. Nothing in the quoted text *encourages* anyone. We 
said that there was a method, which is completely true. We also said 
that this is "the" method, which is also completely true (we didn't 
create another method). That is a far cry from encouragement.

>proposed text said "strongly encouraged", not "SHOULD". After

The WG has gone out of its way to put as few restrictions on servers 
as possible, and to minimize the number of "encouragements" (much 
less strong encouragements). I took that earlier direction to heart 
in the above paragraph.

If the WG wants to make a strong encouragement here, that's fine, but 
we do so against our earlier trend.

>server implementors who don't have specific reason to do

Given that this is the Security Considerations section, we should 
have a security reason for the nudge. I don't think we have one. 
There is no security problem with publishing a known-bad signature.

---

From: Tim Bray <[email-masked]>
Date: Tue, 19 Jun 2007 17:35:15 -0700

> way to know whether an invalid signature is there because

I have to agree with Aristotle on this one.  I think we should simply  
drop that last sentence.  -Tim

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 19 Jun 2007 18:13:10 -0700

At 5:35 PM -0700 6/19/07, Tim Bray wrote:
>I have to agree with Aristotle on this one.  I think we should 
>simply drop that last sentence.  -Tim

Not to be picky, but you are not agreeing with Aristotle. He wants to 
change this sentence to a strong encouragement to strip the signature.

---

From: "A. Pagaltzis" <[email-masked]>
Date: Wed, 20 Jun 2007 04:20:02 +0200

Hi Paul,

* Paul Hoffman <[email-masked]> [2007-06-20 02:50]:
> >> The method for a server to indicate to a third party whether
> >> or not the client signed an Entry Document is by including
> >> the client's signature in the published entry, even though
> Stop right there. Nothing in the quoted text *encourages*
> anyone. We said that there was a method, which is completely
> true.

No, it is entirely false, because cryptographically, a consumer
has no way whatsoever to know whether the signature was
originally valid and where that once supposedly valid signature
originally came from.

A consumer cannot assume *anything* about an entry with an
invalid signature other than that it is an entry with an invalid
signature.

> We also said that this is "the" method, which is also
> completely true (we didn't create another method).

This is false, by extension from the previous sentence being
false; and so we didn’t create any method for this at all, which
makes this claim doubly false.

> That is a far cry from encouragement.

I don’t understand how this first sentence doesn’t stand in
complete contradiction with the previous ones. Sure, servers
might not desire to signal to consumers that the entry was signed
by the client, in which case the paragraph in your proposed spec
text would not act as encouragement. But for those servers who
wish to do so, you are practically telling them to publish the
invalid signature.

Sure it doesn’t encourage all servers, but that seems like hair-
splitting. It does encourage a subset of servers, and more
importantly, the most significant subset of servers as far as
this issue is concerned. If you need me to thusly qualify my
claim that we’d be encouraging servers to publish invalid
signatures, that’s fine with me, but that’s still what we’d be
doing.

> Given that this is the Security Considerations section, we
> should have a security reason for the nudge. I don't think we
> have one. There is no security problem with publishing a
> known-bad signature.

Not a first-order effect, no. Certainly a second-order one,
though; no one is served by a situation where consumers can’t
unconditionally reject entries with broken signatures. Except
the bad guys, anyway.

> If the WG wants to make a strong encouragement here, that's
> fine, but we do so against our earlier trend.

If you want me to tone down the language and avoid
encouragements, I guess that’s fine. Just as well to spell out
the rationale and leave the conclusion to implementors:

    A server is allowed to strip client-applied signatures, to
    strip client-applied signatures and then re-sign with its own
    public key, and to oversign an entry with its own public key.
    The meaning to a third party of a signature applied by a
    server is the same as a signature from anyone, as described
    in [RFC4287]. Third parties may choose to unconditionally
    reject entries with invalid signatures as they cannot
    possibly make any assumption about the origin of such a
    signature and its validity at any previous point in time.

Regards,

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 20 Jun 2007 08:46:06 -0700

>originally valid and where that once supposedly valid signature

It is not "entirely false", it is still true that this is a method 
for saying it was signed. However, you are completely correct that it 
is not a method for saying that it was a valid signature. That is 
quite relevant.

>invalid signature other than that it is an entry with an invalid

Fully agree. And I can see how even talking about leaving invalid 
signatures in can be considered an encouragement, even if it is a 
light encouragement.

Given this, I propose changing the paragraph to:

A server is allowed to strip client-applied signatures, to strip 
client-applied signatures and then re-sign with its own public key, 
and to oversign an entry with its own public key. The meaning to a 
third party of a signature applied by a server is the same as a 
signature from anyone, as described in [RFC4287]. It is recommended 
that a server that is aware that it has changed any part of an Entry 
Document that was signed by the client should strip that signature 
before publishing the entry in order to prevent third parties from 
trying to interpret a signature that cannot be validated.

---

From: "A. Pagaltzis" <[email-masked]>
Date: Wed, 20 Jun 2007 18:32:45 +0200

* Paul Hoffman <[email-masked]> [2007-06-20 17:55]:
> The meaning to a third party of a signature applied by a server
> is the same as a signature from anyone, as described in
> [RFC4287]. It is recommended that a server that is aware that
> it has changed any part of an Entry Document that was signed by
> the client should strip that signature before publishing the
> entry in order to prevent third parties from trying to
> interpret a signature that cannot be validated.

That is perfectly fine with me. Thank you.

Regards,

---

From: Tim Bray <[email-masked]>
Date: Wed, 20 Jun 2007 09:47:37 -0700

On Jun 20, 2007, at 8:46 AM, Paul Hoffman wrote:

> that a server that is aware that it has changed any part of an  
> Entry Document that was signed by the client should strip that  
> signature before publishing the entry in order to prevent third  
> parties from trying to interpret a signature that cannot be validated.

Works for me -T

---

From: James M Snell <[email-masked]>
Date: Wed, 20 Jun 2007 09:57:40 -0700

+1

---

From: John Kemp <[email-masked]>
Date: Wed, 20 Jun 2007 13:16:44 -0400

Hi,

Paul Hoffman wrote:

> signatures in can be considered an encouragement, even if it is a light
> encouragement.
> 
> anyone, as described in [RFC4287]. It is recommended that a server that
> is aware that it has changed any part of an Entry Document that was
> signed by the client should strip that signature before publishing the
> entry in order to prevent third parties from trying to interpret a
> signature that cannot be validated.
> 

What does it mean to "strip" a signature?

Might it be worth noting that in such cases, the server is recommended
to "remove the child element of the Entry Document with the namespace
URI http://www.w3.org/2000/09/xmldsig# and a local name of Signature"
(as specified for signature addition in RFC4287)?

Regards,

- John Kemp

---

From: Don Park <[email-masked]>
Date: Wed, 20 Jun 2007 16:50:29 -0700

Just a few passing comments/suggestions:

1. I think requiring signature-breaking servers to detect and remove  
invalidated signatures creates unnecessary chores as well as being a  
potential source of confusion in context of the must-ignore rule.

2. I think it might make more sense to create an extension designed  
to enhanced digital-signature support. Such an extension would  
include a 'marker' element to indicate that signatures within, if  
any, are likely damaged. A feed processing agent downstream can then  
use the marker to avoid alarming the user unnecessarily.

Best,

Don Park

---

From: James M Snell <[email-masked]>
Date: Wed, 20 Jun 2007 19:18:05 -0700

> potential source of confusion in context of the must-ignore rule.

Require no, recommend yes.

> 2. I think it might make more sense to create an extension designed to
> enhanced digital-signature support. Such an extension would include a
> 'marker' element to indicate that signatures within, if any, are likely
> damaged. A feed processing agent downstream can then use the marker to
> avoid alarming the user unnecessarily.
> 

Hmmm. I can't see how that would be any easier.

- James

---

From: "A. Pagaltzis" <[email-masked]>
Date: Thu, 21 Jun 2007 04:53:16 +0200

Hi Don,

* Don Park <[email-masked]> [2007-06-21 02:05]:
> 2. I think it might make more sense to create an extension
> designed to enhanced digital-signature support. Such an
> extension would include a 'marker' element to indicate that
> signatures within, if any, are likely damaged. A feed
> processing agent downstream can then use the marker to avoid
> alarming the user unnecessarily.

would that really be any gain? It seems to me that it’s just
shifting the complexity around. It’s real easy for a server to
detect that a signature appears to be present even if it lacks
digsig validation code.

Regards,

---

From: Don Park <[email-masked]>
Date: Wed, 20 Jun 2007 20:33:34 -0700

It depends on what the server is doing but injecting an element can  
be easily hard-coded into output templates where removing calls for  
parsing. Anyway, it's nice having an alternate design strategy to  
kick around. :-)

BTW, re problem of server changing element order, you probably know  
this but the common solution is to store the membership and order of  
signed elements elsewhere so scrambled element order in XML won't  
matter much.

- Don

On Jun 20, 2007, at 7:18 PM, James M Snell wrote:

>> designed to