idnits 2.17.1 draft-hallambaker-entity-00.txt: -(37): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(89): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(155): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(163): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(185): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(187): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(198): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(254): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Found some kind of copyright notice around line 606 but it does not match any copyright boilerplate known by this tool. Expected boilerplate is as follows today (2024-03-28) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page == There are 9 instances of lines with non-ascii characters in the document. == 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 183 instances of too long lines in the document, the longest one being 6 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 2004) is 7196 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: '1' on line 45 == Missing Reference: 'TBS' is mentioned on line 545, but not defined == Missing Reference: 'Optional' is mentioned on line 402, but not defined == Unused Reference: 'SMIME' is defined on line 589, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2633 (ref. 'SMIME') (Obsoleted by RFC 3851) -- Possible downref: Non-RFC (?) normative reference: ref. 'XKMS' Summary: 7 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SMIME Working Group 2 Internet Draft P. Hallam-Baker 3 Document: draft-hallambaker-entity-00.txt VeriSign Inc. 4 Expires: October 2004 July 2004 6 Entity-to-Entity S/MIME 8 Status of this Memo 10 This document is an Internet-Draft and is NOT offered in accordance 11 with Section 10 of RFC2026, and the author does not provide the 12 IETF with any rights other than to publish as an Internet-Draft 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet-Drafts 22 as reference material or to cite them other than as "work in 23 progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 This document describes a set of related protocol extensions to 33 S/MIME, SMTP and DNS that collectively simplify deployment of 34 S/MIME. Particular attention is given to ensuring that S/MIME 35 authenticated content is only received by end user clients capable 36 of presenting the content in an acceptable manner. The proposal 37 extends the �end-to-end� security model of traditional S/MIME to 38 support end-to-edge, edge-to-end and edge-to-edge use cases. 40 Conventions used in this document 42 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 43 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 44 this document are to be interpreted as described in RFC-2119 [1]. 46 Table of Contents 48 1. Introduction...................................................2 49 1.1 Brick Wall Deployment Model................................2 50 1.2 Beyond "End-to-End"........................................4 51 1.3 Do no harm.................................................5 52 1.4 The S/MIME Sender Problem..................................5 53 1.5 Support for S/MIME Without Cryptography....................5 54 1.6 Locating Public Keys.......................................6 55 1.7 Validating Public Keys.....................................7 56 2. Architecture...................................................7 57 2.1 Authentication.............................................8 58 2.1.1 Originator 8 59 2.1.2 Outgoing Edge Server 8 60 2.1.3 Incoming Edge Server 8 61 2.1.4 Receiver 8 62 3. SMTP Extensions................................................9 63 4. DNS Extension..................................................9 64 4.1 Policy Element.............................................9 65 4.2 Key Element...............................................10 66 4.3 X509 Element..............................................10 67 4.4 Authentication Policy.....................................11 68 4.5 Encryption Policy.........................................12 69 5. S/MIME Extensions.............................................13 70 5.1 Signed Attribute OIDs.....................................14 71 5.2 MIME Header...............................................14 72 6. Client User Interface.........................................14 73 7. Key Management................................................15 74 References.......................................................15 75 Author's Addresses...............................................16 77 1. Introduction 79 Despite years of effort S/MIME use lags far behind deployment. This 80 document examines the reasons behind the failure of S/MIME to 81 become ubiquitous and proposes a small number of very minor changes 82 to protocols and user interfaces to remedy these problems. 84 The proposal is entirely backwards compatible with the legacy base 85 of email infrastructure, whether S/MIME aware or not. 87 1.1 Brick Wall Deployment Model 88 Like many cryptographic security protocols, S/MIME has suffered 89 from a �brick wall� deployment model that insists that the security 90 provided must be all or nothing. This approach refuses to accept 91 deployment strategies that are perceived as detrimental to 92 security, even when the security benefits are not actually relevant 93 to the party making the choice to deploy. 95 A particular problem in this respect has been security 96 architectures driven largely by ideological concerns rather than a 97 realistic approach to controlling and mitigating risk. 99 Deployment of network protocols and in particular security 100 protocols takes significant time and effort. This often leads to a 101 belief that a security protocol must be absolutely secure against 102 all imaginable forms of attack before deployment begins. In some 103 cases this belief has deployed release of an agreed specification 104 for over a decade. 106 Yet this concern for perfection should be compared to the clear 107 success of SSL and WiFi security protocols. Even though the initial 108 implementation of these protocols was deeply flawed these errors 109 were quickly corrected. Today more email messages are secured 110 using the SSL protocol than by any of the security protocols 111 designed specifically for use with email. Even the deployment of 112 large numbers of WiFi hardware devices, which only provide support 113 for a weak security protocol, has not resulted in disaster. This 114 situation is certainly undesirable, but there is little doubt that 115 almost all WiFi users will be using devices that support genuinely 116 secure protocols long before deployment of IP-Sec achieves close to 117 the same level of ubiquity. 119 Far from precluding subsequent deployment of strong cryptographic 120 protocols, the earlier weak systems paved the way for the strong. 121 System administrators were used to the fact that these applications 122 required security configuration. When they discovered that the 123 security protocols were flawed they insisted that vendors provide 124 an expeditious correction. 126 The traditional argument that weak security is worse than no 127 security at all must be re-evaluated. Over the past ten years 128 consumers have increasingly relied upon the Internet infrastructure 129 and made little distinction between those parts secured by 130 cryptography and those that are insecure. Nor is there any reason 131 to believe that consumer habits are likely to change through 132 education. Security is a means of controlling risk and in most 133 cases consumers have been effective in controlling their risk 134 exposure by transferring it to other parties. 136 Since security is risk control, not risk elimination, a protocol 137 enhancement that can be deployed immediately and mitigate a risk is 138 attractive even if another possible protocol enhancement might 139 become available that eliminates that risk. 141 A distinction must be made between the presence of protocol errors 142 that entirely eliminate the security of a protocol and understood 143 limitations of a protocol that mean that it does not provide 144 protection against every possible attack. 146 1.2 Beyond "End-to-End" 148 S/MIME, like PEM before it and also PGP is a product of the end-to- 149 end security doctrine. The security of a message should be unbroken 150 from origin through to reception. 152 The origins of this doctrine are surprisingly difficult to find. 153 Almost none of the invocations of the end-to-end security principle 154 contain any form of citation. Those that do contain a citation 155 usually refer to one of David Clark�s paper describing the end-to- 156 end argument in general. Unfortunately these papers deal with 157 complexity of protocol design and not security. 159 The end-to-end security principle appears to be the result of 160 subsequent efforts to adopt the end-to-end argument as a universal 161 truth. Unfortunately this claim is simply not substantiated, 162 particularly in respect of Internet security architecture. The fact 163 that no true �end-to-end� security architecture has been deployed 164 to date despite ten years of continuous effort requires that this 165 doctrine be re-examined. 167 Re-examination of end-to-end is particularly critical when the 168 widespread success of edge security measures such as VPNs and 169 Firewalls is considered. Edge security measures have provided 170 security benefits that are both significant and measurable. 172 In the case of a personal email sent from one individual to another 173 the end-to-end principle offers a clear security advantage. In this 174 case the risk that network administrators at either end of the 175 communication might read or modify the contents or of an email 176 message is certainly significant. But this circumstance represents 177 only one of the many situations in which email is used. 179 1.3 Do no harm 181 Sending an S/MIME message today involves an element of risk. 182 Despite the fact that S/MIME has been an IETF draft standard for 183 many years, a significant number of email clients do not support 184 S/MIME and of those that do support S/MIME several provide a user 185 experience that can only be described as �user-hostile�. Instead of 186 providing the email recipient with confidence that the message sent 187 is secure, several email clients �warn� the user when a signed 188 message is received. 190 An Internet user should never be placed at a disadvantage when they 191 choose to enable security. 193 1.4 The S/MIME Sender Problem 195 The patchy nature of S/MIME support is a significant factor in 196 reducing the willingness of users to sign outgoing messages. Unless 197 the sender knows (and remembers) the capabilities of the 198 recipient�s email client it is usually best to avoid use of S/MIME 199 in case this causes annoyance. 201 1.5 Support for S/MIME Without Cryptography 203 The S/MIME specification provides developers with instructions for 204 implementing cryptographic security. Unfortunately the 205 specification does not provide guidelines for applications that do 206 not support cryptography but may nevertheless receive signed 207 messages. 209 While support for cryptographic processing inevitably requires the 210 application developer to spend considerable time and effort, 211 unpacking a multipart/signed container to display the contents 212 requires no more effort than the processing of any other MIME type 213 and developers should be encouraged to provide this minimal level 214 of support. 216 1.6 Locating Public Keys 218 Location of public keys has been a longstanding problem in PKI 219 deployments. First the client must discover the public key of the 220 party they wish to communicate with, secondly a trust path must be 221 constructed that establishes the key as trustworthy. 223 Location of a signing key is often simplified by including the 224 certificate of the signing key in the signed message itself. This 225 is also desirable for security reasons since it ensures that the 226 certificate subject and any attributes associated with the signing 227 certificate are strongly bound to the message certificate. If this 228 is not done there is the potential for a certificate substitution 229 attack. 231 Discovery of the trust path is a considerably harder problem, 232 particularly when cross certification is involved. The sender of a 233 signed message cannot know the trustworthiness criteria that will 234 be applied by the recipient. In a cross certification environment 235 the trust graph is a heterarchy with multiple roots, the sender 236 cannot know which roots the receiver trusts. It is therefore 237 necessary for the receiver to perform discovery of the trust path. 239 Directories based on the X.500 data model have been widely promoted 240 as a solution to the problem of discovering X.509 certificates. In 241 practice neither LDAP nor X.500 have provided much value outside 242 deployment in closed environments. Paradoxically it is the value of 243 the directory as the central hub of the enterprise information 244 infrastructure that constrains its use. Enterprises recognize the 245 value of perimeter security and resist proposals to expose internal 246 directory services to external parties, whether through a border 247 directory or any form of data connector. The consensus amongst 248 network security administrators is that LDAP is not a protocol that 249 should be allowed to traverse firewalls. This consensus is unlikely 250 to change at any time. 252 As with any other routing problem, the trust path discovery problem 253 is tractable provided the necessary data is available. In the 254 Internet �end-to-end� architecture, routing functions are actually 255 performed in the network itself and not at the end points. The 256 trust path discovery problem is tractable when it can be delegated 257 to a service that maintains the complete 259 1.7 Validating Public Keys 261 Once a public key has been located the application should determine 262 whether it is trustworthy before treating the corresponding 263 communication as secure. 265 While X.509 path validation is considerably simpler than path 266 discovery, a device that cannot perform this service for itself 267 should have the capability of delegating validation. 269 2. Architecture 271 The entity-to-entity security model is entirely pragmatic and 272 opportunistic in the application of security enhancements. 274 Any entity in the communication path may apply a security 275 enhancement provided that the entity knows that a subsequent entity 276 in the communication path will ensure that the message is delivered 277 to the recipient in an acceptable form. 278 Any entity in the communication path may remove any security 279 enhancement for any reason provided that the enhancement is not 280 marked as being specifically intended for a subsequent entity in 281 the communication path. 282 Any entity in the communication path may remove any security 283 enhancement if it is known that this is necessary to ensure that 284 the message is delivered to the recipient in an acceptable form. 286 2.1 Authentication 288 A signature may be opportunistic or explicit. An explicit signature 289 is added by means of explicit user intervention 291 2.1.1 Originator 293 An originator may add a signature opportunistically or by means of 294 explicit user intervention. An opportunistic signature may be added 295 automatically whenever the incoming edge server or the receiver is 296 known to provide acceptable support for an end user signature. 298 End to end security is achieved in the case that the end user is 299 known to provide acceptable signature support. 301 2.1.2 Outgoing Edge Server 302 An outgoing edge server may add a signature opportunistically or by 303 means of explicit user intervention. An opportunistic signature may 304 be added automatically whenever the incoming edge server or the 305 receiver is known to provide acceptable support for a domain 306 signature. 308 An outgoing edge server may remove a signature if it is not known 309 that the incoming edge server provides acceptable support for the 310 type of signature present. 312 2.1.3 Incoming Edge Server 314 An incoming edge server may remove a signature if it is not known 315 that the receiver provides acceptable support for the type of 316 signature present. 318 An incoming edge server may verify the signature and pass this 319 information on to the receiver using a discretionary header 320 encoding scheme. 322 2.1.4 Receiver 324 A receiver may verify a signature if present. 326 3. SMTP Extensions 328 The SMTP option SMIME is used to advertise support for S/MIME 329 messages. 331 A server that returns the SMIME option in response to the SMTP EHLO 332 command undertakes to ensure that any message containing S/MIME 333 enhancements will be delivered to the user in an acceptable 334 fashion. In particular: 336 . The server undertakes to ensure that an S/MIME message is 337 delivered in an acceptable manner regardless of the 338 capabilities of the end users MUA. 339 . Messages that carry an S/MIME signature will be treated as if 340 they were unsigned if the recipient is unable to verify the 341 signature for any reason. 343 A server that returns the SMIME option in response to the SMTP EHLO 344 command does NOT undertake to verify the signature on any signed 345 message in any way. In particular: 347 . A compliant server MAY simply strip the S/MIME package and 348 deliver the message content. 350 4. DNS Extension 352 The MARID policy extension SMIME may be used to specify the email 353 authentication and encryption policy for all mail originating from 354 a domain. 356 4.1 Policy Element 358 The Policy element specifies the security policy for a DNS domain. 360 The Policy element may contain the following elements. 362 Key [Any number] 363 A signature key that may be used to sign messages from the 364 domain. 365 X509 [Any number] 366 An X.509 cdertificate that may be used to sign messages from 367 the domain 369 AuthenticationPolicy [Any number] 370 An authentication policy corresponding to the domain 371 Encryption Policy [Any number] 372 An encryption policy corresponding to the domain 374 The following schema defines the Policy element: 376 [TBS] 378 4.2 Key Element 380 The Key element specifies a signature key that may be used to sign 381 messages from the domain. 383 The Key element contains the following attributes: 385 Algorithm [required] 386 The signature algorithm corresponding to the key 387 Value [required] 388 The key value (base 64 encoded) 390 The following schema defines the Key element: 392 [TBS] 394 4.3 X509 Element 396 The X509 element is used to authenticate an X509 certificate that 397 is used to sign messages from the domain by means of a message 398 digest function. 400 The X509 element contains the following attributes: 402 X509IssuerAndSerial[Optional] 403 Specifies the X509 Issuer and Serial number of the 404 certificate in the same format used in XML Signature. 405 Type [required] 406 The type of certificate, valid values are: EndEntity, CA 407 DigestAlgorithm [required] 408 The digest algorithm as specified by the S/MIME specification 410 DigestValue [required] 411 The result of applying the specified message digest function 412 to the certificate (base64 encoded) 413 Locator [optional] 414 A URI that resolves to the certificate 416 The following schema defines the Key element: 418 [TBS] 420 4.4 Authentication Policy 422 The AuthenticationPolicy element specifies the authentication 423 policy of the domain. 425 If an email message is received that is in violation of the 426 specified authentication policy for the domain it SHOULD be 427 rejected. A security notice may be returned to the corresponding 428 domain. 430 The following authentication protocols are defined: 432 SMIME 433 SMIME security. 434 PGP 435 PGP security. 436 Other 437 Any other security protocol. 439 The following authentication policies are defined: 441 EHLO 442 The specified authentication protocol will always be applied 443 whenever the receiving server advertises support in response 444 to EHLO. 445 Always 446 The specified authentication protocol will always be applied. 447 Never 448 The specified authentication protocol will never be applied. 450 Undefined 451 The specified authentication protocol may or may not be 452 applied. 454 The AuthenticationPolicy element contains the following attributes: 456 Protocol [required] 457 The authentication protocol, valid values include SMIME and 458 PGP. 459 Policy [required] 460 The authentication policy identifier, valid values include 461 EHLO, Always, Never and Undefined. If a different policy 462 identifier is specified it MUST be treated as if it was 463 Undefined. 465 The following schema defines the AuthenticationPolicy element: 467 [TBS] 469 4.5 Encryption Policy 471 The EncryptionPolicy element specifies the authentication policy of 472 the domain. 474 If an email message is received that is in violation of the 475 specified authentication policy for the domain it SHOULD be 476 accepted if the policy would require that the message be sent 477 encrypted but SHOULD be rejected if the policy would require that 478 the message be sent plaintext. A security notice SHOULD be returned 479 to the corresponding domain in either case. 481 The following encryption protocols are defined: 483 TLS 484 TLS security by means of the SMTP STARTTLS command. 485 SMIME 486 SMIME security. 487 PGP 488 PGP security. 490 Other 491 Any other security protocol. 493 The following encryption policies are defined: 495 EHLO 496 The specified encryption protocol will always be applied 497 whenever the receiving server advertises support in response 498 to EHLO. 499 XKMS 500 The specified encryption protocol will always be applied 501 whenever the receiving domain advertises the existence of a 502 corresponding XKMS server by means of the SRV record 503 specified in the XKMS 2.0 specification. 504 Always 505 The specified encryption protocol will always be applied. 506 Never 507 The specified encryption protocol will never be applied. 508 Undefined 509 The specified encryption protocol may or may not be applied. 511 The EncryptionPolicy element contains the following attributes: 513 Protocol [required] 514 The authentication protocol, valid values include STATLS, 515 SMIME and PGP. 516 Policy [required] 517 The encryption policy identifier, valid values include EHLO, 518 XKMS, Always, Never and Undefined. If a different policy 519 identifier is specified it MUST be treated as if it was 520 Undefined. 522 The following schema defines the EncryptionPolicy element: 524 [TBS] 526 5. S/MIME Extensions 527 Entity to entity signatures MAY be added automatically or through 528 the explicit intervention of the user. It is important that 529 applications are able to distinguish between these cases. 531 5.1 Signed Attribute OIDs 533 The use of the following OIDs as signed attributes allows the 534 status of the signature to be included within the scope of the 535 signature itself. 537 [TBS] 539 5.2 MIME Header 541 The following MIME header SHOULD be used to allow servers to 542 determine the status of the signature without decoding the S/MIME 543 signature package. 545 [TBS] 547 6. Client User Interface 549 All clients should tolerate multipart/signed messages of any form 550 without negatively impacting the user experience. 552 Should treat a message with an invalid signature as if it were 553 unsigned. 555 Should only warn users of invalid signature if it is known that the 556 message should have been signed. Rejecting the message is the 557 preferred course. 559 Should support the logotypes extension to present trust paths in a 560 graphical fashion. Important to display CA logos since these serve 561 as surrogate brands for companies that do not have a well known 562 logo. Logo display MUST be unspoofable. 564 Should support the automatic discovery of path discovery and key 565 registration services. In addition, why not discover the outgoing 566 MTA and the connection to the incoming MTA automatically? 567 Should support the use of delegated path discovery. May support 568 delegated path delegation. 570 Should support simple registration process using the existing 571 client credentials used to access the email host to register a key 572 pair. 574 7. Key Management 576 For mechanisms for locating and validating keys see the XKMS 577 specification [XKMS]. 579 XKMS is a key centric public key infrastructure exposed as a Web 580 Service. We observe that as far as an application client is 581 concerned all public key operations involve a question of the form 582 �what is the public key that should be used for cryptographic 583 operation X when attempting to communicate using protocol Y to 584 entity Z. The XML Key Information Service Specification (X-KISS) 585 allows such a client to delegate this question to a Web Service. 587 References 589 [SMIME] B. Ramsdell, S/MIME Version 3 Message Specification RFC 590 2366, http://www.ietf.org/rfc/rfc2633.txt 592 [XKMS] Hallam-Baker, XML Key Management Specification Version 2.0 593 (XKMS 2.0), W3C Candidate Recommendation 5 April 2004, 594 http://www.w3.org/TR/2004/CR-xkms2-bindings-20040405/ 596 1 Bradner, S., "Key words for use in RFCs to Indicate Requirement 597 Levels", BCP 14, RFC 2119, March 1997 599 Acknowledgments 601 The author acknowledges the contributions made to this proposal by 602 Nico Popp, Alex Deacon and Jeff Burstein. 604 Copyright Statement 606 Copyright (C) The Internet Society (year). This document is subject 607 to the rights, licenses and restrictions contained in BCP 78, and 608 except as set forth therein, the authors retain all their rights." 610 "This document and the information contained herein are provided on an 611 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 612 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 613 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 614 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 615 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 616 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 618 Author's Addresses 620 Phillip Hallam-Baker 621 VeriSign Inc. 622 Email: pbaker@verisign.com