|
As Robert Sayre recently wrote: >DSig and XMLEnc are in
core. >http://atompub.org/2004/10/20/draft-ietf-atompub-format-03.html#rfc.section.7 However, the text says: “The document element of an Atom
document (i.e., atom:feed in an Atom Feed Document, atom:entry in an Atom Entry
Document) MAY have an Enveloped Signature” … “Other elements
in an Atom document MUST NOT be signed unless their definitions explicitly
specify such a capability.” The
definition of atom:entry does not “explicitly specify” that
signatures can be used on an atom:entry that appears within an Atom Feed Document
(i.e. as a child of atom:feed). This would seem to imply that I cannot compose
an Atom Feed Document by collecting together Atom Entry Documents and wrapping
them in a atom:feed – unless I strip out any signatures that might have
been in the Atom Entry Documents prior to inserting them in the Atom Feed
Document. This is a significant problem for a system like PubSub.com’s
that composes feeds by combining entries found in Atom Feed Documents or Atom
Entry Documents. It also prevents the use of Atom Feed Documents as a means of “logging”
a sequence of Atom Entry Documents that may be delivered over time –
perhaps via a mechanism like “Atom over XMPP”. Additionally, this
constraint would prevent “search engines” from delivering up
unmodified Atom Entry Documents as elements of result sets that are presented
as Atom Feed Documents. (i.e. the search engine might receive signed atom Entry
Documents but would be forced to remove the signatures if it returns results as
an Atom Feed.) I can’t
remember if this has been discussed before. I’m tempted to write a Pace
which would specify that any atom:entry can be signed – whether it is
found in an Atom Feed Document or an Atom Entry Document. Before doing so, I
would appreciate if someone could explain if the constraint in the current
specification is intentional. Why would a signature not be permitted on an
atom:entry found in an Atom Feed Document? bob
wyman |
