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/