idnits 2.17.1 draft-snell-atompub-tombstones-18.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 20, 2012) is 4269 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Snell 3 Internet-Draft July 20, 2012 4 Intended status: Standards Track 5 Expires: January 21, 2013 7 The Atom "deleted-entry" Element 8 draft-snell-atompub-tombstones-18 10 Abstract 12 This specification adds mechanisms to the Atom Syndication Format 13 which publishers of Atom Feed and Entry documents can use to 14 explicitly identify Atom entries that have been removed. 16 Status of this Memo 18 This Internet-Draft is submitted to IETF in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on January 21, 2013. 33 Copyright Notice 35 Copyright (c) 2012 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3 52 3. The at:deleted-entry element . . . . . . . . . . . . . . . . . 3 53 4. Deleted Entry Document . . . . . . . . . . . . . . . . . . . . 6 54 5. Digital Signatures . . . . . . . . . . . . . . . . . . . . . . 7 55 6. Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . 7 56 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 57 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 58 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 59 10. Normative References . . . . . . . . . . . . . . . . . . . . . 10 60 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 62 1. Introduction 64 Atom [RFC4287] is an XML-based document format that describes lists 65 of related information known as "feeds". Feeds are composed of a 66 number of items, known as "entries", each with an extensible set of 67 attached metadata. The primary use case that Atom addresses is the 68 syndication of Web content such as weblogs and news headlines to Web 69 sites as well as directly to user agents. 71 In the base Atom format, when an entry is removed from a feed, but a 72 consumer has already received and processed that entry, perhaps 73 adding it to a local cache or display, there is no mechanism for 74 determining that the entry has been removed. This specification adds 75 a mechanism to the Atom Syndication Format that publishers of Atom 76 Feed and Entry documents can use to explicitly identify Atom entries 77 that have been removed. Atom consumers can use that information to 78 adjust such things as their document cache and user interfaces. 80 2. Notational Conventions 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 84 document are to be interpreted as described in [RFC2119]. 86 This specification uses XML Namespaces [W3C.REC-xml-names-19990114] 87 to uniquely identify XML element names. It uses the following 88 namespace prefix for the indicated namespace URI; 90 "at": "http://purl.org/atompub/tombstones/1.0" 92 3. The at:deleted-entry element 94 The at:deleted-entry element represents an Atom Entry that has been 95 removed. 97 deletedEntry = 98 element at:deleted-entry { 99 atomCommonAttributes, 100 attribute ref { atomUri }, 101 attribute when { atomDateConstruct }, 102 ( element at:by { atomPersonConstruct }? 103 & element at:comment { atomTextConstruct }? 104 & element atom:link { atomLink }* 105 & element atom:source { atomSource }? 106 & anyElement* ) 107 } 109 The at:deleted-entry element MUST contain a ref attribute whose value 110 specifies the value of the atom:id of the entry that has been 111 removed. 113 The at:deleted-entry element MUST contain a when attribute whose 114 value is an [RFC3339] "date-time" specifying the instant the entry 115 was removed. An uppercase "T" character MUST be used to separate 116 date and time, and an uppercase "Z" character MUST be present in the 117 absence of a numeric time zone offset 119 The at:deleted-entry element MAY contain one at:by element used to 120 identify the entity that removed the entry. The at:by element is an 121 Atom Person Construct as defined by Section 3.2 of [RFC4287]. 123 The at:deleted-entry element MAY contain one at:comment element whose 124 value provides additional, language-sensitive information about the 125 deletion operation. The atom:comment element is an Atom Text 126 Construct as defined by Section 3.1 of [RFC4287]. 128 The at:deleted-entry element MAY contain any number of atom:link 129 elements as specified by Section 4.2.7 of [RFC4287]. 131 The at:deleted-entry element MAY contain one atom:source element as 132 defined by Section 4.2.11 of [RFC4287]. Within the context of an at: 133 deleted-entry element, the atom:source element is intended to allow 134 the aggregation of at:deleted-entry element from different feeds 135 while retaining information about an at:deleted-entry's source feed. 136 When an at:deleted-entry element appears in a Feed document other 137 than it's source Feed or when an at:deleted-entry element that has a 138 source Feed document is used in the context of a Deleted Entry 139 Document, it MUST contain an atom:source element. 141 An Atom feed MAY contain any number of at:deleted-entry elements, but 142 MUST NOT contain more than one with the same combination of ref and 143 when attribute values. 145 147 ... 148 149 153 154 157 158 John Doe 159 jdoe@example.org 160 161 Removed comment spam 162 163 ... 164 166 An Atom feed MAY contain atom:entry elements and at:deleted-entry 167 elements sharing the same atom:id value. In such cases, the 168 implication is that the particular atom:entry has either been 169 published to the feed and then subsequently removed; or that a 170 previously removed entry has been republished to the feed following a 171 previous deletion. To determine which condition applies, the 172 processor needs to compare the value of the at:deleted-entry 173 element's when attribute to the value of the corresponding atom:entry 174 element's atom:updated value: 175 o If the when attribute specifies a value equal to or more recent 176 than that specified by the atom:updated element, the atom:entry is 177 assumed to have been published then subsequently removed. 178 Processors SHOULD ignore the older atom:entry element. 179 o If the when attribute specifies a value older than that specified 180 by the atom:updated element, the atom:entry is assumed to have 181 been republished to the feed following a prior removal. 182 Processors SHOULD ignore the older at:deleted-entry element. 184 Publishers of feeds containing at:deleted-entry elements should note 185 that the at:deleted-entry element is advisory in nature only and may 186 be ignored by Atom processors. The presence of an at:deleted-entry 187 element does not guarantee that the atom:entry to which it is 188 referring will no longer be available. For example, if an entry was 189 published to a feed document that was published and processed 190 yesterday by an aggregator application, then is subsequently deleted 191 today, with a corresponding at:deleted-entry element added to the 192 feed as a signal that the entry was deleted, there is no guarantee 193 that the aggregator application will pay any attention to the at: 194 deleted-entry element during subsequent processing operations. 196 Elements and attributes from any XML vocabulary MAY be used within an 197 at:deleted-entry element. Processors encountering such markup MUST 198 NOT stop processing or signal an error. It might be the case that 199 the Processor is able to process the foreign markup correctly and 200 does so. When unknown markup is encountered as a child of at: 201 deleted-entry, Processors MAY bypass the markup and any textual 202 content and MUST NOT change their behavior as a result of the 203 markup's presence. 205 This specification allows the use of IRIs [RFC3987] in precisely the 206 same manner specified in Section 2 of [RFC4287]. 208 Any element defined by this specification MAY have an xml:base 209 attribute [W3C.REC-xmlbase-20010627]. When xml:base is used, it 210 serves the function described in section 5.1.1 of [RFC3986], 211 establishing the base URI (or IRI) for resolving any relative 212 references found within the effective scope of the xml:base 213 attribute. 215 Any element defined by this specification MAY have an xml:lang 216 attribute, whose content indicates the natural language for the 217 element and its descendents. Requirements regarding the content and 218 interpretation of xml:lang are specified in XML 1.0 219 [W3C.REC-xml-20040204], Section 2.12. 221 4. Deleted Entry Document 223 A "Deleted Entry Document" represents exactly one at:deleted-entry 224 element outside the context of an Atom feed. It's root is the at: 225 deleted-entry element. 227 namespace at = "http://purl.org/atompub/tombstones/1.0" 228 start = at:deleted-entry 230 Deleted Entry Documents are specified in terms of the XML Information 231 Set, serialized as XML 1.0 [W3C.REC-xml-20040204] and identified with 232 the "application/atomdeleted+xml" media type. Deleted Entry 233 Documents MUST be well-formed XML. This specification does not 234 define a DTD for Deleted Entry Documents, and hence does not require 235 them to be valid (in the sense used by XML). 237 5. Digital Signatures 239 The at:deleted-entry element MAY have an Enveloped Signature, as 240 described by XML-Signature and Syntax Processing 241 [W3C.REC-xmldsig-core-20020212]. 243 Processors MUST NOT reject an at:deleted-entry containing such a 244 signature because they are not capable of verifying it; they MUST 245 continue processing and MAY inform the user of their failure to 246 validate the signature. 248 In other words, the presence of an element with the namespace URI 249 "http://www.w3.org/2000/09/xmldsig#" and a local name of "Signature" 250 as a child of the document element MUST NOT cause an Processor to 251 fail merely because of its presence. 253 Section 6.5.1 of [W3C.REC-xmldsig-core-20020212] requires support for 254 Canonical XML [W3C.REC-xml-c14n-20010315]. However, many 255 implementers do not use it because signed XML documents enclosed in 256 other XML documents have their signatures broken. Thus, Processors 257 that verify signed at:deleted-entry elements MUST be able to 258 canonicalize with the exclusive XML canonicalization method 259 identified by the URI "http://www.w3.org/2001/10/xml-exc-c14n#", as 260 specified in Exclusive XML Canonicalization 261 [W3C.REC-xml-exc-c14n-20020718]. 263 Intermediaries such as aggregators may need to add an atom:source 264 element to an at:deleted-entry that does not contain its own atom: 265 source element. If such an entry is signed, the addition will break 266 the signature. Thus, a publisher of individually-signed at:deleted- 267 entry's should strongly consider adding an atom:source element to 268 those elements before signing them. Implementers should also be 269 aware of the issues concerning the use of markup in the "xml:" 270 namespace as it interacts with canonicalization. 272 Section 4.4.2 of [W3C.REC-xmldsig-core-20020212] requires support for 273 DSA signatures and recommends support for RSA signatures. However, 274 because of the much greater popularity in the market of RSA versus 275 DSA, Atom Processors that verify signed Atom Documents MUST be able 276 to verify RSA signatures, but do not need be able to verify DSA 277 signatures. Due to security issues that can arise if the keying 278 material for message authentication code (MAC) authentication is not 279 handled properly, Atom Documents SHOULD NOT use MACs for signatures. 281 6. Encryption 283 The root of a Deleted Entry Document (the at:deleted-entry element) 284 MAY be encrypted, using the mechanisms described by XML Encryption 285 Syntax and Processing [W3C.REC-xmlenc-core-20021210]. 287 Section 5.1 of [W3C.REC-xmlenc-core-20021210] requires support of 288 TripleDES, AES-128, and AES-256. Processors that decrypt Deleted 289 Entry Documents MUST be able to decrypt with AES-128 in Cipher Block 290 Chaining (CBC) mode. 292 Encryption based on [W3C.REC-xmlenc-core-20021210] does not ensure 293 integrity of the original document. There are known cryptographic 294 attacks where someone who cannot decrypt a message can still change 295 bits in a way where part or all the decrypted message makes sense but 296 has a different meaning. Thus, Processors that decrypt Deleted Entry 297 Documents SHOULD check the integrity of the decrypted document by 298 verifying the hash in the signature (if any) in the document, or by 299 verifying a hash of the document within the document (if any). 301 When a Deleted Entry Document is to be both signed and encrypted, it 302 is generally a good idea to first sign the document, then encrypt the 303 signed document. This provides integrity to the base document while 304 encrypting all the information, including the identity of the entity 305 that signed the document. Note that, if MACs are used for 306 authentication, the order MUST be that the document is signed and 307 then encrypted, and not the other way around. Further, if MACs are 308 used along with a symmetric encryption algorithm, the same key SHOULD 309 NOT be used in the generation of the MAC and the encryption. 311 7. Security Considerations 313 As specified in [RFC4287], Atom processors should be aware of the 314 potential for spoofing attacks where an attacker publishes atom:entry 315 or atom:deleted-entry elements using the same atom:id values as 316 entries from other Atom feeds. An attacker may attempt to trick an 317 application into believing that a given entry has either been removed 318 from or added to a feed. To mitigate this issue, Atom processors are 319 advised to ignore at:deleted-entry elements referencing entries that 320 have not previously appeared within the containing Feed document and 321 should take steps to verify the origin of the Atom feed before 322 considering the entries to be removed. 324 The at:deleted-entry element can be encrypted and signed using 325 [W3C.REC-xmlenc-core-20021210] and [W3C.REC-xmldsig-core-20020212], 326 respectively, and are subject to the security considerations implied 327 by their use. 329 Digital signatures provide authentication and message integrity with 330 proof of origin. Encryption provides data confidentiality. 332 An application supporting the use of digitally signed atom:entry and 333 at:deleted-entry elements should be aware of the potential issues 334 that could arise if a at:deleted-entry element indicating the 335 deletion of an atom:entry element has been signed using a different 336 key than what was used to sign the atom:entry, or when an unsigned 337 at:deleted-entry is used to indicate the deletion of a signed atom: 338 entry. Either case can potentially indicate a form of spoofing 339 attack. Processors must take steps to verify the validity of the at: 340 deleted-entry element. 342 8. IANA Considerations 344 A Deleted Entry Document, when serialized as XML 1.0, can be 345 identified with the following media type: 347 Type name: application 348 Subtype name: atomdeleted+xml 349 Required parameters: None 350 Optional parameters: "charset" : This parameter has semantics 351 identical to the charset parameter of the "application/xml" media 352 type as specified in [RFC3023]. 353 Encoding considerations: Identical to those of "application/xml" 354 as described in [RFC3023], Section 3.2. 355 Security considerations: As defined in this specification. In 356 addition, as this media type uses the "+xml" convention, it shares 357 the same security considerations as described in [RFC3023], 358 Section 10. 359 Interoperability considerations: There are no known 360 interoperability issues. 361 Published specification: This specification. 362 Applications that use this media type: Undefined. As an extension 363 to the Atom Syndication Format ([RFC4287]), this specification may 364 be used within any application that uses the Atom Format. 365 Additional information: 366 Magic number(s): As specified for "application/xml" in 367 [RFC3023], Section 3.2 368 File extension(s): .atomdeleted 369 Macintosh file type code(s): TEXT 370 Person & email address to contact for further information: James M 371 Snell 372 Intended usage: COMMON 373 Restrictions on usage: None. 374 Author: James M Snell 375 Change controller: IESG 377 9. Acknowledgements 379 The author gratefully acknowledges the feedback from the members of 380 the Atom Publishing Format and Protocol working group during the 381 development of this specification. 383 10. Normative References 385 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 386 Requirement Levels", BCP 14, RFC 2119, March 1997. 388 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 389 Types", RFC 3023, January 2001. 391 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 392 Internet: Timestamps", RFC 3339, July 2002. 394 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 395 Resource Identifier (URI): Generic Syntax", STD 66, 396 RFC 3986, January 2005. 398 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 399 Identifiers (IRIs)", RFC 3987, January 2005. 401 [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom 402 Syndication Format", RFC 4287, December 2005. 404 [W3C.REC-xml-20040204] 405 Yergeau, F., Maler, E., Sperberg-McQueen, C., Paoli, J., 406 and T. Bray, "Extensible Markup Language (XML) 1.0 (Third 407 Edition)", World Wide Web Consortium FirstEdition REC-xml- 408 20040204, February 2004, 409 . 411 [W3C.REC-xml-c14n-20010315] 412 Boyer, J., "Canonical XML Version 1.0", World Wide Web 413 Consortium Recommendation REC-xml-c14n-20010315, 414 March 2001, 415 . 417 [W3C.REC-xml-exc-c14n-20020718] 418 Reagle, J., 3rd, D., and J. Boyer, "Exclusive XML 419 Canonicalization Version 1.0", World Wide Web Consortium 420 Recommendation REC-xml-exc-c14n-20020718, July 2002, 421 . 423 [W3C.REC-xml-names-19990114] 424 Hollander, D., Bray, T., and A. Layman, "Namespaces in 425 XML", World Wide Web Consortium FirstEdition REC-xml- 426 names-19990114, January 1999, 427 . 429 [W3C.REC-xmlbase-20010627] 430 Marsh, J., "XML Base", World Wide Web Consortium 431 FirstEdition REC-xmlbase-20010627, June 2001, 432 . 434 [W3C.REC-xmldsig-core-20020212] 435 Solo, D., Reagle, J., and D. Eastlake, "XML-Signature 436 Syntax and Processing", World Wide Web Consortium 437 FirstEdition REC-xmldsig-core-20020212, February 2002, 438 . 440 [W3C.REC-xmlenc-core-20021210] 441 Eastlake, D. and J. Reagle, "XML Encryption Syntax and 442 Processing", World Wide Web Consortium Recommendation REC- 443 xmlenc-core-20021210, December 2002, 444 . 446 Author's Address 448 James M Snell 450 Email: jasnell@us.ibm.com 451 URI: http://ibm.com