idnits 2.17.00 (12 Aug 2021) /tmp/idnits30180/draft-rsalz-atom-adv-sec-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 22 instances of too long lines in the document, the longest one being 60 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 123: '... or APP dcoument MUST NOT have more th...' RFC 2119 keyword, line 132: '...ecurity" element SHOULD be the first c...' RFC 2119 keyword, line 153: '... certificate SHOULD NOT be used....' RFC 2119 keyword, line 177: '... element MUST NOT be used....' RFC 2119 keyword, line 204: '...atomsec:credentials" element SHOULD be...' (7 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 11, 2009) is 4659 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) No issues found here. Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 atompub F. Chen 3 Internet-Draft M. Hondo 4 Expires: February 12, 2010 R. Salz 5 IBM 6 August 11, 2009 8 Advanced Security Processing for Atom and APP Documents 9 draft-rsalz-atom-adv-sec-00.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on February 12, 2010. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 The Atom and APP specifications specify simple uses of cryptography 48 to sign and encrypt their documents. Each document is processed 49 completely, and in isolation. This document specifies additional 50 uses that enable selective protection or encryption of content, and 51 allow a "trust path" to be created across "atom:link" elements. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Notational Conventions and Terminology . . . . . . . . . . 3 57 2. Using WS-Security . . . . . . . . . . . . . . . . . . . . . . 4 58 3. The "atomsec:credentials" element . . . . . . . . . . . . . . 6 59 4. Selectively Signing parts of an Atom document . . . . . . . . 8 60 5. Selectively Encrypting parts of an Atom document . . . . . . . 11 61 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 62 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 63 8. Normative References . . . . . . . . . . . . . . . . . . . . . 15 64 Appendix A. Crypto and Security Primer . . . . . . . . . . . . . 16 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 67 1. Introduction 69 The Atom and APP specifications define how to use XML Digital 70 Signature [W3C.REC-xmlenc-core-20021210], and XML Encryption 71 [W3C.REC-xmlenc-core-20021210] to prevent the contents of a document 72 from being modified or inadvertently disclosed. This specification 73 profiles how to use WS-Security [oasis-wssec-v1.1] to provide 74 selective protection and encryption of a document and allow a single 75 document to be encrypted for multiple recipients. 77 Linking is a key point of Atom and APP, and this document defines a 78 new element that can be used to establish a chain of trust, from the 79 document with the "atom:link" to the content being referred-to. 81 1.1. Notational Conventions and Terminology 83 The conventions and terminology of both The Atom Syndication Format 84 [RFC4287] and The Atom Publishing Protocol [RFC5023], known as Atom 85 and APP respectively, are incorporated here by reference. Within 86 this document, the phrase "Atom document" is used to refer to any 87 document defined by either RFC. 89 The following namespace prefixes are used in this document: 91 +-------+-----------------------------------------------------------+ 92 | Prefi | Namespace URI | 93 | x | | 94 +-------+-----------------------------------------------------------+ 95 | atom | http://www.w3.org/2005/Atom | 96 | | | 97 | app | http://www.w3.org/2007/app | 98 | | | 99 | atoms | http://www.ibm.com/xmlns/stdwip/atomext/security | 100 | e | | 101 | c | | 102 | | | 103 | dsig | http://www.w3.org/2000/09/xmldsig# | 104 | | | 105 | xenc | http://www.w3.org/2001/04/xmlenc# | 106 | | | 107 | wsse | http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-w | 108 | | ssecurity-secext-1.0.xsd | 109 | | | 110 | wsu | "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss- | 111 | | wssecurity-utility-1.0.xsd | 112 +-------+-----------------------------------------------------------+ 114 2. Using WS-Security 116 The "wsse:Security" element is part of a specification informally 117 known as WS-Security. The element is defined as a container for 118 security information, including security tokens, XML encryption keys, 119 and/or XML digital signatures for SOAP message security. This 120 specification uses the semantics of WS-Security processing to achieve 121 the goals . 123 An Atom or APP dcoument MUST NOT have more than one "wsse:Security" 124 child element. While compatible with [oasis-wssec-v1.1] processing, 125 the schema for the "wsse:Security" element is taken from 126 [oasis-wssec-v1.0]. 128 One feature of the WS-Security header is that it should be possible 129 to process in a forward-streaming manner. That is, security tokens 130 appear before they are used (such as in signatures), and encipherment 131 keys appear before the encrypted data. Therefore, if present, the 132 "wsse:Security" element SHOULD be the first child of the Atom 133 document. 135 The "wsse:SecurityTokenReference" element can be used to help enable 136 streaming processing, and to reduce multiple occurrences of the same 137 credentials. To do this, each credential is made the child of a 138 "wsse:BinarySecurityToken" element, which in turn is a child of the 139 "wsse:Security" element. For example: 141 142 145 MII... 146 . 147 ... 148 150 Note that [W3C.REC-xmlenc-core-20021210] specifies many ways to 151 identify key material, including Distinguished Name, Issuer/ 152 SerialNumber, etc. Any method other than embedding the entire 153 certificate SHOULD NOT be used. 155 In this document, anywhere a certificate is referenced, the content 156 may instead be a "wsse:SecurityTokenReference" to a token in the 157 "wsse:Security" element. For example, the following two document 158 fragments are semantically equivalent: 160 161 162 163 164 165 166 168 169 170 171 MII... 172 173 174 176 A reference other than a direct reference using the "wsse:Reference" 177 element MUST NOT be used. 179 3. The "atomsec:credentials" element 181 The "atomsec:credentials" element is a child element of an "atom: 182 link" element. It specifies one or more security tokens that may be 183 used to validate the provenance of the data being linked-to. The 184 "use" attribute specifies how the credentials are to be used. Two 185 values are specified, "content" and "transport". If the attribute is 186 not present, it is equivalent to providing it with the value 187 "content". 189 atomSecCredentials = 190 element atomsec:credentials { 191 atomCommonAttributes*, 192 attribute use { "content" | "transport" } ?, 193 (extensionElement*) 194 } 196 The "transport" value specifies that the credentials can be used to 197 validate the SSL certificate of the server containing the linked-to 198 data. The "content" value specifies that the credentials can be used 199 to validate any digital signatures on the linked-to data. 201 An "atom:link" element can have no more than two "atom:credentials" 202 elements, one for each of content and transport credentials. 204 The child elements of the "atomsec:credentials" element SHOULD be 205 "dsig:KeyInfo" elmenents used to locate X.509 certificate data. 206 These certificates can be used by the relying party to verify the 207 specified trust chain. 209 A party that has out of band knowledge MAY ignore this element. 211 Here is an example of an Atom document pointing to signed content: 213 214 215 217 218 219 220 MII... 221 222 223 224 225 226 Here is another example, one that specifies the CA that issued the 227 SSL/TLS certificate used by the server for the host www.example.com: 229 230 231 232 233 234 235 MII... 236 237 238 239 240 242 4. Selectively Signing parts of an Atom document 244 A "dsig:Signature" element in the "wsse:Security" element may be used 245 to sign one or more elements of an Atom document. The signature 246 should be detached, with one "dsig:Reference" for each item being 247 signed. 249 The processing rules are defined by sections 8.2 and 8.4 of 250 [oasis-wssec-v1.1] with the following additions: 252 o The SOAP message envelope is not used and the "wsse:Security" 253 element MUST be the first element of the root document. 255 o Each element being signed MUST have a unique "xml:id" attribute if 256 not already present. 258 o The enveloped-signature transform as defined by 259 [W3C.REC-xmlenc-core-20021210] SHOULD be used to sign the root 260 document. If there are additional signed elements, they MUST be 261 signed first so that the root signature will include its 262 descendant's signatures. 264 Here is an example: 266 268 270 271 XXXX-XX-XXT02:41:15Z 272 XXXX-XX-XXT02:46:15Z 273 275 277 MII... 278 279 280 281 282 283 284 285 286 287 288 cHt... 289 290 291 292 293 294 295 Oj2... 296 297 298 SWz... 299 300 301 302 303 304 306 309 310 311 312 313 314 315 316 317 318 319 cRY... 320 321 322 QAw... 323 324 325 327 328 329 330 332 Example Feed 333 334 2003-12-13T18:30:02Z 335 336 John Doe 337 338 urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6 340 341 Atom-Powered Robots Run Amok 342 343 urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a 344 2003-12-13T18:30:02Z 345 Some text. 346 347
348

[Update: The Atom draft is finished.]

349
350
352
353
354 5. Selectively Encrypting parts of an Atom document 356 The processing rules for encrypting parts of an Atom document are 357 defined by sections 9.4.1 and 9.4.2 of [oasis-wssec-v1.1] with the 358 following additions: 360 o The SOAP message envelope is not used and the "wsse:Security" 361 element MUST be the first element of the root document. 363 o Use WS-Security processing to encrypt the full document. If the 364 encrypted result does not have to be valid according to the Atom 365 schema's, then the [W3C.REC-xmlenc-core-20021210] standard SHOULD 366 be used. 368 Here is an example: 370 371 373 374 375 377 378 379 381 YPArt... 382 383 384 385 386 387 JG0... 388 389 390 391 392 393 394 395 397 Example Feed 398 399 2003-12-13T18:30:02Z 400 401 John Doe 403 404 urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6 406 407 409 410 411 412 Clm... 413 414 415 417 418 419 420 421 422 Clm... 423 424 425 427 428 6. IANA Considerations 430 None. 432 7. Security Considerations 434 This entire document is about securing Atom documents. 435 Authentication and authorization (e.g., to delete a update or delete 436 a posting via APP) are not discussed here. 438 8. Normative References 440 [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom 441 Syndication Format", RFC 4287, December 2005. 443 [RFC5023] Gregorio, J. and B. de hOra, "The Atom Publishing 444 Protocol", RFC 5023, October 2007. 446 [W3C.REC-xmldsig-core-20080610] 447 Hirsch, F., Roessler, T., Eastlake, D., Reagle, J., and D. 448 Solo, "XML Signature Syntax and Processing (Second 449 Edition)", World Wide Web Consortium Recommendation REC- 450 xmldsig-core-20080610, June 2008, 451 . 453 [W3C.REC-xmlenc-core-20021210] 454 Eastlake, D. and J. Reagle, "XML Encryption Syntax and 455 Processing", World Wide Web Consortium Recommendation REC- 456 xmlenc-core-20021210, December 2002, 457 . 459 [oasis-wssec-v1.0] 460 Nadalin, A., Kaler, C., Hallam-Baker, P., and R. Monzillo, 461 "Web Services Security: SOAP Message Security 1.0", OASIS 462 Standard 200401, March 2004, . 466 [oasis-wssec-v1.1] 467 Nadalin, A., Kaler, C., Hallam-Baker, P., and R. Monzillo, 468 "Web Services Security: SOAP Message Security 1.1", OASIS 469 Standard (WS-Security 2004), February 2006, . 473 Appendix A. Crypto and Security Primer 475 This section provides a very brief overview of common cryptographic 476 techniques and how they are used. It is intended only to provide the 477 smallest amount of information so that the rest of this document is 478 understandable. It is not normative. 480 Public-key cryptography is done using two numbers that are related to 481 each other. One of these numbers is public and can be known or used 482 by anyone, while the other is private and should only be known by its 483 "owner." The numbers have two very important properties. First, 484 anything encrypted with the public key can only be decrypted with the 485 private key. This means that anyone can generate text that is only 486 legible to the key's owner. The second is that anything that is 487 encrypted with the private key can be decrypted by anyone who has the 488 public key. This allows anyone receiving such an encrypted item to 489 know that it came from the key holder. The most common public-key 490 algorithms are RSA and Elliptic-Curve. 492 A message digest, or hash takes an arbitrary sequence of bytes and 493 returns a fixed-size identifier. The most important property is that 494 it is statistically unlikely for two different streams to result in 495 the same hash. The most useful hash algorithms are SHA-1 and SHA- 496 256. 498 A message digest encrypted with a private key is a signature. Anyone 499 with the original document can generate their own digest, decrypt the 500 received one, and compare them. If the values do not match, then the 501 document has been modified. The most common signature method is RSA/ 502 SHA-n. 504 In symmetric cryptography, the same key is used for encryption and 505 decryption. This means that both sender and receiver have to have 506 the same key. Common symmetric (or shared-secret) algorithms are AES 507 and triple-DES. 509 A common technique is to "wrap" a symmetric key by encyrpting it with 510 the recipient's public key. The bulk of the data is then encrypted 511 using the symmetric key. This allows multiple recipients to see the 512 data by only encrypting the symmetric key multiple times, rather than 513 the entire data. 515 An X.509 certificate is a datum that contains a name and other 516 identifying information, and a public key that can be associated with 517 that name. The certificate also contains information such as its 518 validity period, the ways in which the keys are to be used, and so 519 on. For details see the IETF PKI Profile, RFC XXX. A certificate is 520 signed by a CA, and common practice is for the entity receiving a 521 certificate to be configured to trust everything signed by the CA, or 522 perhaps the CA's CA, or further up the chain. 524 Authors' Addresses 526 Fred (Xiangfu) Chen 527 IBM 528 1 Rogers Street 529 Cambridge, MA 02142 530 USA 532 Phone: +1 617-693-6313 533 Email: chenfr@us.ibm.com 534 URI: http://www.ibm.com 536 Maryann Hondo 537 IBM 538 1 Rogers Street 539 Cambridge, MA 02142 540 USA 542 Phone: +1 617-693-1236 543 Email: mhondo@us.ibm.com 544 URI: http://www.ibm.com 546 Rich Salz 547 IBM 548 1 Rogers Street 549 Cambridge, MA 02142 550 USA 552 Phone: +1 617-693-3808 553 Email: rsalz@us.ibm.com 554 URI: https://www.ibm.com/developerworks/mydeveloperworks/blogs/soma/