Re: Clearing a discuss vote on the Atom format

2005-07-04 Thread Bob Wyman


James M Snell wrote:

b. recommended inclusion of a source element in signed entries.

   +1

   bob wyman




Re: FWD: I-D ACTION:draft-nottingham-atompub-feed-history-01.txt

2005-07-04 Thread Thomas Broyer


Mark Nottingham wrote:



This draft is based on comments received; thanks to everyone. Major  
changes;


* Removed 'this' link
* Changed link syntax
* Changed stateful syntax
* Clarified difference between 'subscription' and 'archive' feeds  
(note that they're just for the purposes of clarity in this spec)

* Added a bit to the state reconstruction process description
* Added examples


Really good work!


Comments and suggestions welcome as always,


Why not using an xs:boolean for fh:stateful? hence allowing values 0, 1, 
true and false.


With the -01 draft (it might have been the same within the -00 one too), 
one can't reuse the process to link to archives of Top Twenty Records 
or Most Popular Items (e.g. a monthly Top Twenty Records linking to 
the previous-month Top), because of the a subscription document whose 
fh:stateful element contains false MUST NOT contain a fh:prev element.
Why not just stating that if fh:stateful is false then the prev-linked 
archive feed doesn't not contain a subset of the previous entries but 
rather does contain the previous state of the subscription feed. I.e. 
the meaning of the fh:prev link depends on the value of fh:stateful.


Also, shouldn't there be a note to invite producers to provide an 
atom:[EMAIL PROTECTED]self referencing the subscription feed?


I also repeat my proposal for an identifier different from an URI for a 
reader/aggregator to know whether it has already retrieved an archive 
document, e.g. using the updated date-time of the fh:prev-linked 
archive feed.


Example:
  ?xml version=1.0 encoding=utf-8?
  feed xmlns=http://purl.org/atom/ns#draft-ietf-atompub-format-09;
xmlns:history=[TBD]
titleExample Feed/title
link href=http://example.org//
updated2003-12-13T18:30:02Z/updated
author
  nameJohn Doe/name
/author
idurn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6/id
history:statefultrue/history:stateful
!--
added an updated attribute with tha atom:updated value
of the http://example.org/2003/11/index.atom document.
--
history:prev updated=2003-11-24T12:00:00Z
  http://example.org/2003/11/index.atom/history:prev

entry
  titleAtom-Powered Robots Run Amok/title
  link href=http://example.org/2003/12/13/robots_here/
  idurn:uuid:1225c695-cfb8-4ebb--80da344efa6a/id
  updated2003-12-13T18:30:02Z/updated
  summarySome text in a new, fresh entry./summary
/entry

  /feed

If I retrieved the feed between 2003-11-24T12:00:00Z and 
2003-12-13T18:30:02Z, the fh:prev URI were probably equal to 
http://example.org/2003/10/index.atom (october, not november). However, 
I didn't miss any entry.
Using the fh:[EMAIL PROTECTED] value, I can know that I didn't miss any entry 
and that I then don't need to dereference 
http://example.org/2003/11/index.atom (november, the new fh:prev URI)


--
Thomas Broyer





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

2005-07-04 Thread Paul Hoffman


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



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

2005-07-04 Thread Bob Wyman


   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




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

2005-07-04 Thread Tim Bray



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