idnits 2.17.1 draft-eastlake-proto-doc-pov-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 567. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** 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: '... "style sheet" [CSS], MUST be considered part of the document....' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (June 2004) is 7245 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) -- Looks like a reference, but probably isn't: '2802' on line 492 == Unused Reference: 'RFC 2802' is defined on line 602, but no explicit reference was found in the text == Unused Reference: 'RFC 3076' is defined on line 611, but no explicit reference was found in the text == Unused Reference: 'RFC 3275' is defined on line 613, but no explicit reference was found in the text == Unused Reference: 'RFC 3741' is defined on line 616, but no explicit reference was found in the text == Unused Reference: 'XMLENC' is defined on line 630, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 2411 (Obsoleted by RFC 6071) -- Obsolete informational reference (is this intentional?): RFC 2630 (Obsoleted by RFC 3369, RFC 3370) -- Obsolete informational reference (is this intentional?): RFC 2821 (Obsoleted by RFC 5321) -- Obsolete informational reference (is this intentional?): RFC 2822 (Obsoleted by RFC 5322) Summary: 12 errors (**), 0 flaws (~~), 7 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Donald Eastlake 3rd 2 INTERNET-DRAFT Motorola Laboratories 3 Expires: December 2004 June 2004 5 The Protocol versus Document Points of View in Computer Protocols 6 --- -------- ------ -------- ------ -- ---- -- -------- --------- 7 9 Status of This Document 11 By submitting this Internet-Draft, I certify that any applicable 12 patent or other IPR claims of which I am aware have been disclosed, 13 or will be disclosed, and any of which I become aware will be 14 disclosed, in accordance with RFC 3668. 16 This draft is intended to become an Informational RFC. It's 17 distribution is unlimited. Please send comments to the author. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than a "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/1id-abstracts.html 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 Abstract 37 Two points of view are contrasted: the "document" point of view, 38 where digital objects of interest are like pieces of paper written 39 and viewed by people, and the "protocol" point of view where objects 40 of interest are composite dynamic network messages. While each point 41 of view has a place, adherence to a document point of view can be 42 damaging to protocol design. By understanding both of these points 43 of view, conflicts between them may be clarified and reduced. 45 Table of Contents 47 Status of This Document....................................1 48 Abstract...................................................1 50 Table of Contents..........................................2 52 1. Introduction............................................3 53 2. Points of View..........................................3 54 2.1 The Basic Points of View...............................3 55 2.2 Questions of Meaning...................................4 56 2.2.1 Core Meaning.........................................4 57 2.2.2 Adjunct Meaning......................................5 58 2.3 Processing Models......................................5 59 2.3.1 Amount of Processing.................................5 60 2.3.2 Granularity of Processing............................6 61 2.3.3 Extensibility of Processing..........................6 62 2.4 Security and Canonicalization..........................7 63 2.4.1 Canonicalization.....................................7 64 2.4.2 Digital Authentication...............................8 65 2.4.3 Canonicalization and Digital Authentication..........9 66 2.4.4 Encryption..........................................10 67 2.5 Unique Internal Labels................................10 68 3. Examples...............................................11 69 4. Resolution of the Points of View.......................12 70 5. Conclusion.............................................13 72 Copyright and Disclaimer..................................14 74 Informative References....................................15 76 Author's Address..........................................17 77 Expiration and File Name..................................17 79 1. Introduction 81 This document contrasts two points of view: the "document" point of 82 view, where digital objects of interest are like pieces of paper 83 written and viewed by people, and the "protocol" point of view where 84 objects of interest are composite dynamic network messages. Those 85 accustomed to one point of view frequently have great difficulty in 86 appreciating the other. Even after they understand the other, they 87 almost always start by consider things from their accustomed point of 88 view, assume that most of the universe of interest is best viewed 89 from their perspective, and commonly slip back into thinking about 90 things entirely from that point of view. While each point of view 91 has a place, adherence to a document point of view can be damaging to 92 protocol design. By understanding both of these points of view, 93 conflicts between them may be clarified and reduced. 95 Much of the IETF's traditional work has concerned low level binary 96 protocol constructs. These are almost always viewed from the protocol 97 point of view. But as higher level application constructs and 98 syntaxes are involved in the IETF and other standards processes, 99 difficulties can arise due to participants who have the document 100 point of view. These two different points of view defined and 101 explored in Section 2 below. 103 Section 3 gives some examples. Section 4 tries to synthesize the 104 views and give general design advice in areas which can reasonably be 105 viewed either way. 107 2. Points of View 109 The following subsections contrast the document and protocol points 110 of view. Each viewpoint is EXAGGERATED for effect. 112 The document point of view is indicated in paragraphs headed "DOCUM" 113 while the protocol point of view is indicated in paragraphs headed 114 "PROTO". 116 2.1 The Basic Points of View 118 DOCUM: What is important are complete (digital) documents, analogous 119 to pieces of paper, viewed by people. A major concern is to be 120 able to present such documents as directly as possible to a court 121 or other third party. Since what is presented to the person is all 122 that is important, anything which can effect this, such as a 123 "style sheet" [CSS], MUST be considered part of the document. 124 Sometimes the fact that the "document" originates in a computer, 125 may travel over, be processed in, and stored in computer systems, 126 and is viewed on a computer and that such operations may involve 127 transcoding, enveloping, or data reconstruction, is forgotten. 129 PROTO: What is important are bits on the wire generated and consumed 130 by well defined computer protocol processes. No person ever sees 131 the full message as such; it is only viewed as a whole by a geek 132 when debugging and even then they see some translated visible 133 form. If you actually ever have to demonstrate something about 134 such a message in a court or to a third party, there isn't any way 135 to avoid having coomputer experts interpret it. Sometimes the fact 136 that pieces of such messages may end up being included in or 137 influencing data displayed to a person is forgotten. 139 2.2 Questions of Meaning 141 The document and protocol points of view have radically different 142 concepts of the "meaning" of data. The document oriented tend to 143 consider "meaning" to a human reader to be extremely important but 144 this is something the protocol oriented rarely think about at all. 146 This difference in point of view extends beyond the core meaning to 147 the meaning of addenda to data. Both core and addenda meaning are 148 discussed below. 150 2.2.1 Core Meaning 152 DOCUM: The "meaning" of a document is a deep and interesting human 153 question related to volition. It is probably necessary for the 154 document to include or reference human language policy and/or 155 warranty / disclaimer information. At an absolute minimum, some 156 sort of semantic labeling is required. The assumed situation is 157 always a person interpreting the whole "document" without other 158 context. Thus it is reasonable to consult attorneys during message 159 design, require human readable statements to be "within the four 160 corners" of the document, etc. 162 PROTO: The "meaning" of a protocol message should be clear and 163 unambiguous from the protocol specification. It is frequently 164 defined in terms of the state machines of the sender and recipient 165 processes and may have only the most remote connection with human 166 volition. Such processes have additional context and the message 167 is usually only meaningful with that additional context. Adding 168 any human readable text that is not functionally required is 169 silly. Consulting attorneys during design is a bad idea that 170 complicates the protocol and could tie a design effort in knots. 172 2.2.2 Adjunct Meaning 174 Adjunct items can be added or are logically addenda to a message. 176 DOCUM: From a document point of view, at the top level we have the 177 equivalent of a person looking at a document. So adjunct items 178 such as digital signatures, person's names, dates, etc., must be 179 carefully labeled as to meaning. Thus a digital signature needs to 180 include, in more or less human readable form, what that signature 181 means (is the signer a witness, author, guarantor, authorizer, or 182 what?). Similarly, a person's name needs to be accompanied by 183 what that person's role is, such as editor, author, subject, or 184 contributor. As another example, a date needs to be accompanied 185 by the meaning of the date, such as date of creation, 186 modification, distribution or other event. 187 Given the unrestrained scope of what can be documented, with 188 the document point of view there is a risk of trying to enumerate 189 and standardize all possible "semantic tags" for each kind of 190 adjunct data during in the design process. This can be a 191 difficult, complex, and essentially infinite task (i.e., a rat 192 hole). 194 PROTO: From a protocol point of view, the semantics of the message 195 and every adjunct in it are defined in the protocol specification. 196 Thus, if there is a slot for a digital signature, person's name, a 197 date, or whatever, the party that is to enter that data, the party 198 or parties that are to read it, and its meaning are all pre- 199 defined. Even if there are several possible meanings, the specific 200 meaning that applies can be specified by a separate enumerated 201 type field. There is no reason to have such a field be directly 202 human readable. Only the "meanings" directly relevant to the 203 particular protocol need be considered. Another way to look at 204 this is that the "meaning" of each adjunct, instead of being 205 pushed into and coupled with the adjunct itself, as the document 206 point of view encourages, is commonly promoted to the level of the 207 protocol specification, resulting in simpler adjuncts. 209 2.3 Processing Models 211 The document oriented and protocol oriented have very different views 212 on what is likely to happen to an object. 214 2.3.1 Amount of Processing 216 DOCUM: The model is of a quasi-static object like a piece of paper. 217 About all you do to pieces of paper is transfer them as a whole, 218 from one storage area to another, or add signatures, date stamps, 219 or similar adjuncts. (Possibly you might want an extract from a 220 document or to combine multiple documents into a summary but this 221 isn't the common case.) 223 PROTO: The standard model of a protocol message is as an ephemeral 224 composite, multi-level object created by a source process and 225 consumed by a destination process. Such a message is constructed 226 from information contained in previously received messages, 227 locally stored information, local calculations, etc. It is normal 228 for there to be quite complex processing. 230 2.3.2 Granularity of Processing 232 DOCUM: The document view is generally of uniform processing or 233 evaluation of the object being specified. There may be an 234 allowance for attachments or addenda but if so they would probably 235 be simple, one level, self documenting attachments or addenda. 236 (Separate processing of an attachment or addenda is possible but 237 not usual.) 239 PROTO: Processing is complex and almost always affects different 240 pieces of the message differently. Some pieces may be intended for 241 use only by the destination process, and may be extensively 242 processed there. Others may be present so the destination process 243 can, at some point, do minimal processing and forward them in 244 other messages to yet other processes. The object's structure can 245 be quite rich and have multilevel or recursive aspects. Because 246 messages are processed in context, you can have things like a 247 signature which covers the combination of some date in the 248 message, some received in previous messages and stored, and some 249 locally calculated data. 251 2.3.3 Extensibility of Processing 253 DOCUM: The document oriented don't usually think of extensibility as 254 a major problem. They assume that their design, perhaps with some 255 simple version scheme, will meet all requirements. Or, coming from 256 an SGML/DTD world of closed systems, they may assume that 257 knowledge of new versions or extensions can be easily and 258 synchronously distributed to all participating sites. 260 PROTO: Those who are protocol oriented assume that protocols will 261 always need to be extended and that it will not be possible to 262 update all implementations as such extensions are deployed and/or 263 retired. This is a difficult problem but those from the protocol 264 point of view try to provide the tools need. For example, they 265 specify carefully defined versioning and extension/feature 266 labeling, include the ability to negotiate version and features 267 where possible and at least a specification of how parties running 268 different levels should interact, providing length/delimiting 269 information for all data so it can at least be skipped if not 270 understood, and provide destination labeling so that a process can 271 tell that it should ignore data except for passing it through to a 272 later player. 274 2.4 Security and Canonicalization 276 Security is a subtle area. Some of the problems can be solved in a 277 general way, and those solutions are typically incorporated into 278 standard security syntaxes such as those for ASN.1 [RFC 2630] and XML 279 [RFC 3275. XMLENC]. But there are application specific questions, 280 particularly questions of exactly what information for which 281 protocols need to provide authentication or confidentiality. 282 Questions of exactly what needs to be secured and how to do so 283 robustly are deeply entwined with canonicalization. They are also 284 somewhat different for authentication and encryption, as discussed 285 below. 287 2.4.1 Canonicalization 289 Canonicalization is the transformation of the "significant" 290 information in a message into a "standard" form, discarding 291 "insignificant" information. For example, encoding into a standard 292 character set or changing line endings into a standard encoding and 293 discarding the information as to what the original character set or 294 line ending encodings were. Obvious, what is "significant" and what 295 is "insignificant" varies with the application or protocol and can be 296 tricky to determine. However, it is common that for each particular 297 syntax, such as ASCII [ASCII], ASN.1 [ASN.1], or XML [XML], a 298 standard canonicalization or canonicalizations are specified or 299 developed through practice. This leads to the design of applications 300 that assume one of such standard canonicalizations thus reducing the 301 need for per-application canonicalization. (See also [RFC 3076, 302 3741].) 304 DOCUM: From the document point of view, canonicalization is suspect 305 if not outright evil. After all, if you have a piece of paper with 306 writing on it, any modification to "standardize" its format can be 307 an unauthorized change in the original message as created by the 308 "author" who is always visualized as a person. From the document 309 point of view, digital signatures are like authenticating 310 signatures or seals or time stamps on the bottom of the "piece of 311 paper". They do not justify and should not depend on changes in 312 the message appearing above them. Similarly, from the document 313 point of view, encryption is just putting the "piece of paper" in 314 a vault that only certain people can open, and does not justify 315 any standardization or canonicalization of the message. 317 PROTO: From the protocol point of view, canonicalization is simply a 318 necessity. It is just a question of exactly what canonicalization 319 or canonicalizations to apply to a pattern of bits that are 320 calculated, processed, stored, communicated, and finally parsed 321 and acted on. Most of these bits have never been seen and never 322 will be seen by a person. In fact, many of the parts of the 323 message will be artifacts of encoding, protocol structure, and 324 computer representation rather than anything intended for a person 325 to see. 326 Perhaps in theory, the "original", idiosyncratic form of any 327 digitally signed part could be conveyed unchanged through the 328 computer process, storage, and communications channels which 329 implement the protocol and usefully signed in that form. But in 330 practical systems of any complexity, this is unreasonably 331 difficult, at least for most parts of messages. And if it were 332 possible, it would be virtually useless, because to authenticate 333 messages you would still have to determine their equivalence with 334 the preserved original form. 335 Thus, signed data must be canonicalized as part of signing and 336 verification to compensate for insignificant changes made in 337 processing, storage, and communication. Even if, miraculously, an 338 initial system design avoids all cases of signed message 339 reconstruction based on processed data or re-encoding based on 340 character set or line ending or capitalization or numeric 341 representation or time zones or whatever, later protocol revisions 342 and extensions are certain to eventually require such 343 reconstruction and/or re-encoding. If such "insignificant" changes 344 are not ameliorated by canonicalization, signatures won't work, as 345 descussed in more detail in 2.4.3 below. 347 2.4.2 Digital Authentication 349 DOCUM: The document-oriented view on authentication tends to be a 350 "digital signature" and "forms" point of view. (The "forms" point 351 of view is a subset of the document point of view which believes 352 that a principle activity is presenting forms to human beings so 353 they can fill out and sign portions of those forms [XForms].) 354 Since the worry is always about human third parties and viewing 355 the document in isolation, those who are document oriented always 356 want "digital signature" (asymmetric key) authentication with its 357 characteristics of "non-repudiability", etc. As a result, they 358 reject secret key based message autentication codes, which provide 359 the verifier with the capability of forging an authentication 360 code, as useless. (See any standard reference on the subject for 361 the usual meaning of these terms.) 362 From their point of view, you have a piece of paper or form 363 which a person signs. Sometimes a signature covers only part of a 364 form, but that's usually because a signature can only cover data 365 which is already there. And normally at least one signature covers 366 the "whole" document/form. Thus they want to be able to insert 367 digital signatures into documents without changing the document 368 type and even "inside" the data being signed, which requires a 369 mechanism to skip the signature so that it does not try to sign 370 itself. 372 PROTO: From a protocol point of view, the right kind of 373 authentication to use, whether "digital signature" or symmetric 374 keyed authentication code (or biometric or whatever), is just 375 another engineering decision affected by question of efficiency, 376 desired security model, etc. Furthermore, the concept of signing a 377 "whole" message seems very peculiar (unless it is a copy being 378 saved for archival purposes in which case you might be signing a 379 whole archive at once anyway). Typical messages are made up of 380 various pieces with various destinations, sources, and security 381 requirements. Furthermore, there are commonly fields you can't 382 sign because they change as the message is communicated and 383 processed, such as hop counts, routing history, or local 384 forwarding tags. Certainly, different kinds of authentication are 385 commonly mixed in one message. 387 2.4.3 Canonicalization and Digital Authentication 389 For authenticating protocol system messages of practical complexity, 390 you are faced with the choice of 391 (1) doing "too little canonicalization" and having brittle 392 authentication, useless due to verification failures caused by 393 surface representation changes without significance, or 394 (2) doing the sometimes difficult and tricky work of selecting or 395 designing an appropriate canonicalization or canonicalizations to be 396 used as part of authentication generation and verification, producing 397 robust and useful authentication, or 398 (3) doing "too much canonicalization" and having insecure 399 authentication, useless because it still verifies even when 400 significant changes are made in the signed data. 402 The only useful option above is number 2. 404 2.4.4 Encryption 406 In terms of processing, transmission, and storage, encryption turns 407 out to be much easier than signatures to get working. Why? Because 408 the output of encryption is essentially random bits. It is clear from 409 the beginning that those bits need to be transferred to the 410 destination in some absolutely clean way that does not change even 411 one bit. Because the encrypted bits are meaningless to a human being, 412 there is no temptation from the document oriented to try to make them 413 more "readable". So appropriate techniques of encoding at the source, 414 such as Base64 [RFC 2045], and decoding at the destination, are 415 always incorporated to protect or "armor" the encrypted data. 417 While the application of canonicalization is more obvious with 418 digital signatures, it may also apply to encryption, particularly 419 encryption of parts of a message. Sometimes elements of the 420 environment where the plain text data is found may affect its 421 interpretation. For example, interpretation can be affected by the 422 character encoding or bindings of dummy symbols. When the data is 423 decrypted, it may be into an environment with a different character 424 encoding or dummy symbol bindings. With a plain text message part, it 425 is usually clear which of these environmental elements need to be 426 incorporated in or conveyed with the message. But an encrypted 427 message part is opaque. Thus some canonical representation that 428 incorporates such environmental factors may be needed. 430 DOCUM: Encryption of the entire document is usually what is thought 431 of. Because signatures are always thought of as human assent, 432 people with a document point of view tend to vehemently assert 433 that encrypted data should never be signed unless you know what 434 the plain text of it was. 436 PROTO: Messages are complex composite multi-level structures some 437 pieces of which are forwarded multiple hops. Thus the design 438 question is what fields should be encrypted by what techniques to 439 what destination or destinations and with what canonicalization. 440 It sometimes makes perfect sense to sign encrypted data you don't 441 understand; for example, the signature could just be for integrity 442 protection or as a time stamp, as specified in the protocol. 444 2.5 Unique Internal Labels 446 It is desirable to be able to reference parts of structured messages 447 or objects by some sort of "label" or "id" or "tag". The idea is that 448 this forms a fixed "anchor" that can be used "globally", at least 449 within an application domain, to reference the tagged part. 451 DOCUM: From the document point of view, it seems logical to just 452 provide for a text tag. The concept would be that users or 453 applications could easily come up with short readable tags. These 454 would probably be meaningful to a person if humanly generated 455 (e.g., "Susan") and at least fairly short and systematic if 456 automatically generated (i.e., "A123"). The ID attribute type in 457 XML [XML] appears to have been thought of this way, although it 458 can be used in other ways. 460 PROTO: From a protocol point of view, unique internal labels look 461 very different than they do from a document point of view. Since 462 this point of view assumes that pieces of different protocol 463 messages will later be combined in a variety of ways, previously 464 unique labels can conflict. There are really only three 465 possibilities if you need such tags, as follows: 466 (1) Have a system for dynamically rewriting such tags to maintain 467 uniqueness. This is usually a disaster as it (a) invalidates 468 any stored copies of the tags that are not rewritten, and it 469 is usually impossible to be sure there aren't more copies 470 lurking somewhere you failed to update, and (b) invalidates 471 digital signatures that cover a changed tag. 472 (2) Use some form of hierarchical qualified tags. Thus the total 473 tag can remain unique even if a part is moved, because its 474 qualification changes. This avoids the digital signature 475 problems of the above possibility. But it destroys the concept 476 of a globally-unique anchor embedded in and moving with the 477 data. And stored tags may still be invalidated by data moves. 478 Nevertheless, within the scope of a particular carefully 479 designed protocol, such as IOTP [RFC 2801], this can work. 480 (3) Construct a lengthy globally-unique tag string. This can be 481 done successfully by using a good enough random number 482 generator and big enough random tags (perhaps about 24 483 characters) or more sequentially as in the way email messages 484 IDs are created [RFC 2822]. 485 Thus, from a protocol point of view, such tags are difficult but 486 if you really need them, choice 3 works best. 488 3. Examples 490 IETF protocols are replete with examples of the protocol viewpoint 491 such as TCP [RFC 793], IPSEC [RFC 2411], SMTP [RFC 2821], and IOTP 492 [RFC 2801, 2802]. 494 The eXtensible Markup Language [XML] is an example of something that 495 can easily be viewed both ways and where the best results frequently 496 result from attention to both the document and the protocol point of 497 view. 499 Computerized court documents, human-to-human email, and the X.509v3 500 Certificate [X509v3], particularly the X509v3 policy portion, are 501 examples primarily designed from the document point of view. 503 4. Resolution of the Points of View 505 There is some merit to each point of view. Certainly the document 506 point of view has some intuitive simplicity and appeal and is OK for 507 applications where it meets their needs. 509 The protocol point of view can come close to encompassing the 510 document point of view as a limiting case. In particular, it does so 511 under the following circumstances: 513 1. As the complexity of messages declines to a single payload 514 (perhaps with a few attachments). 516 2. As the mutability of the payload declines to some standard format 517 that needs little or no canonicalization. 519 3. As the number of parties and amount of processing as messages are 520 transferred declines. 522 4. As the portion of the message intended for more or less direct 523 human consumption increases. 525 Under the above circumstances, the protocol point of view would be 526 narrowed to something quite close to the document point of view. 527 Even when the document point of view is questionable, the addition of 528 a few options to a protocol will usually mollify the perceived needs 529 of those looking at things from that point of view. For example, 530 adding optional non-canonicalication or an optional policy statement, 531 or inclusion of semantic labels, or the like. 533 On the other hand, the document point of view is hard to stretch to 534 encompass the protocol case. From a strict piece of paper 535 perspective: canonicalization is wrong; inclusion of human language 536 policy text within every significant object and a semantic tag with 537 every adjunct should be mandatory; and so on. Objects designed in 538 this way are rarely suitable for protocol use as they tend to be 539 improperly structured to accommodate hierarchy and complexity, 540 inefficient (due to unnecessary text and self-documenting 541 inclusions), and insecure (due to brittle signatures). 543 Thus, to produce usable protocols, it is best to start with the 544 protocol point of view and add such document point of view items as 545 are necessary to achieve consensus. 547 5. Conclusion 549 I hope that this document will help explain to those of either point 550 of view where those with the other view are coming from. It is my 551 hope that this will decrease conflict, shed some light -- in 552 particular on the difficulties of security design -- and lead to 553 better protocol designs. 555 Copyright and Disclaimer 557 Copyright (C) The Internet Society 2004. This document is subject to 558 the rights, licenses and restrictions contained in BCP 78, and except 559 as set forth therein, the authors retain all their rights. 561 This document and the information contained herein are provided on an 562 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 563 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 564 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 565 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 566 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 567 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 569 Informative References 571 [ASCII] - "USA Standard Code for Information Interchange", X3.4, 572 American National Standards Institute: New York, 1968. 574 [ASN.1] - 575 ITU-T Recommendation X.680 (1997) | ISO/IEC 8824-1:1998, 576 "Information Technology - Abstract Syntax Notation One (ASN.1): 577 Specification of Basic Notation". 578 ITU-T Recommendation X.690 (1997) | ISO/IEC 8825-1:1998, 579 "Information Technology - ASN.1 Encoding Rules: Specification of 580 Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and 581 Distinguished Encoding Rules (DER)". 582 . 584 [CSS] - "Cascading Style Sheets, level 2 revision 1 CSS 2.1 585 Specification", B. Bos, T. Gelik, I. Hickson, H. Lie, W3C Candidate 586 Recommendation, 25 February 2004. 588 [RFC 793] - "Transmission Control Protocol", J. Postel, Sep-01-1981. 590 [RFC 2045] - "Multipurpose Internet Mail Extensions (MIME) Part One: 591 Format of Internet Message Bodies", N. Freed & N. Borenstein, 592 November 1996. 594 [RFC 2411] - "IP Security Document Roadmap", R. Thayer, N. Doraswamy, 595 R. Glenn, November 1998. 597 [RFC 2630] - "Cryptographic Message Syntax", R. Housley, June 1999. 599 [RFC 2801] - "Internet Open Trading Protocol - IOTP Version 1.0", D. 600 Burdett, April 2000. 602 [RFC 2802] - "Digital Signatures for the v1.0 Internet Open Trading 603 Protocol (IOTP)", K. Davidson, Y. Kawatsura, April 2000. 605 [RFC 2821] - "Simple Mail Transfer Protocol", J. Klensin, Editor, 606 April 2001. 608 [RFC 2822] - "Internet Message Format", P. Resnick, Editor, April 609 2001. 611 [RFC 3076] - "Canonical XML Version 1.0", J. Boyer, March 2001. 613 [RFC 3275] - "(Extensible Markup Language) XML-Signature Syntax and 614 Processing", D. Eastlake, J. Reagle, D. Solo, March 2002. 616 [RFC 3741] - "Exclusive XML Canonicalization Version 1.0", J. Boyer, 617 D. Eastlake 3rd, J. Reagle, March 2004. 619 [X509v3] - "ITU-T Recommendation X.509 version 3 (1997), Information 620 Technology - Open Systems Interconnection - The Directory 621 Authentication Framework", ISO/IEC 9594-8:1997. 623 [XForms] - "XForms 1.0", M. Dubinko, L. Klotz, R. Merrick, T. Raman, 624 W3C Recommendation 14 October 2003. 626 [XML] - "Extensible Markup Language (XML) 1.0 Recommendation (2nd 627 Edition)". T. Bray, J. Paoli, C. M. Sperberg-McQueen, E. Maler, 628 October 2000. 630 [XMLENC] - "XML Encryption Syntax and Processing", J. Reagle, D. 631 Eastlake, December 2002. 634 Author's Address 636 The author of this document is: 638 Donald E. Eastlake 3rd 639 Motorola Laboratories 640 155 Beaver Street 641 Milford, MA 01757 USA 643 Phone: +1 508-786-7554 (w) 644 +1 508-634-2066 (h) 645 Fax: +1 508-786-7501 (w) 646 EMail: Donald.Eastlake@motorola.com 648 Expiration and File Name 650 This draft expires December 2004. 652 Its file name is .