Re: Clearing a discuss vote on the Atom format
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
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
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
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
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