idnits 2.17.1 draft-arnold-scmp-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** Bad filename characters: the document name given in the document, 'draft-arnold-scmp-02.txt)', contains other characters than digits, lowercase letters and dash. ** Missing revision: the document name given in the document, 'draft-arnold-scmp-02.txt)', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-arnold-scmp-02.txt)', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-arnold-scmp-02.txt)', but the file name used is 'draft-arnold-scmp-02' == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 612 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** 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 6 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** There are 14 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: A server MAY NOT guarantee serialized request processing. If requests must be serialized, it is expected that all of the serialized transactions will be received in a single message payload or that other content specific serialization systems will be used. == Unrecognized Status in 'Category: Application', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) ** Downref: Normative reference to an Historic RFC: RFC 2311 (ref. 'SMIME') ** Obsolete normative reference: RFC 1119 (ref. 'NTP') (Obsoleted by RFC 1305) ** Downref: Normative reference to an Informational RFC: RFC 2315 (ref. 'PKCS-7') Summary: 15 errors (**), 1 flaw (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet-Draft Tom Arnold (CyberSource) 2 Category: Application Jason Eaton (CyberSource) 3 March 19, 1999 Michael Jimenez (CyberSource) 4 Expires in six months Hubert Chen (CyberSource) 6 Simple Commerce Messaging Protocol (SCMP) 7 (draft-arnold-scmp-02.txt) 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance 12 with all provisions of Section 10 of RFC2026. 14 This document is an Internet-Draft. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its areas, 16 and working groups. Note that other groups may also distribute 17 working documents as Internet-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- 22 Drafts as reference material or to cite them other than as 23 "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 1. Introduction 33 The Simple Commerce Messaging Protocol (SCMP) is a general-purpose 34 commerce transport protocol for secure, real-time communication of 35 a set of data from a sending agent's application to a receiving 36 agent's server. Additionally the response by the receiving agent's 37 sever to the sending agent is the reply from the request represented 38 by the set of data in the message's payload. The intent of this 39 protocol is to define a method where trading partners can perform 40 on-line business requests in an environment where the sending partner 41 is fully authenticated, and the message cannot be repudiated. 43 The taxonomy of the SCMP message payload is not in the scope of this 44 document. The SCMP protocol does not specify payload definitions or 45 how trading partners are expected to process the payload, beyond basic 46 server-level functions related to processing SCMP headers. This intent 47 is to permit trading partners the flexibility to implement either a 48 standard commerce message format as in ANSI-X12 Electronic Data 49 Interchange (EDI) or some other non-standard payload format. 51 The only requirement on the message payload is that it be identified to 52 the receiver utilizing MIME naming and formatting [MIME] and is used to 53 identify the type of payload contained in the SCMP data area. 55 In this manner, SCMP fundamentally differs from many emerging 56 commerce message protocols. Beyond specifying the method for 57 encryption, authentication and handling, these other protocols 58 specify the contents of the message and details how a server is to 59 process and respond to a given message payload. 61 1.1. Document Overview 63 This document describes SCMP from the standpoint of how trading partners 64 would implement a client/server request processing system via an 65 untrusted network connection. 67 In a on-line, electronic commerce environment, trading partners require 68 a scalable, message handling system that will meet these minimum 69 requirements: 71 1.1.1 Real-time Request and Response 73 A single message containing all credential and payload data is 74 prepared by a sending agent and sent to a receiving agent. The 75 receiving agent, upon verification of sender's credentials, MUST 76 process the payload, format a reply, and respond to the sender as 77 the response to the inbound connection. 79 1.1.2 Message Privacy 81 Through use of cryptographic methods, the privacy of the sender's 82 message payload MUST be assured should a message payload be 83 intercepted. 85 1.1.2 Message Integrity 87 If a message arrives in an incomplete or tampered condition from a 88 sending agent, the receiving agent's server MUST detect the condition, 89 deny message payload processing, and respond with an appropriate 90 error message. 92 1.1.3 Authentication of Sending and Receiving Agents 94 Messages between trading partners, as represented by sending and 95 receiving agents, MUST contain attributes that assure a given request 96 could only be from a specific trading partner. 98 1.1.4 Non-repudiation 100 When a receiving agent's server receives a request to process a payload, 101 the receiving agent's application SHOULD guarantee that the sender 102 cannot, at some later time, refute having sent the request. 104 Non-repudiation is defined as, the inability of either trading partner 105 (sender or receiver) to refute the sending of an SCMP request or SCMP 106 reply. 108 An Electronic Commerce provider will typically provide financial based 109 functionality such as authorization, settlement, and crediting, of credit 110 card accounts and/or merchant accounts. This functionality requires that 111 the Electronic Commerce Provider execute financial transactions on behalf 112 of the merchant, or trading partner. Therefore it is desirable that the 113 transaction directives which are given in an SCMP message are 114 non-refutable. 116 1.1.5 Payload Independence 118 The messaging system MUST perform consistently for all payload formats. 120 1.1.6 Standards Based 122 The messaging protocol MUST be based on proven, existing cryptography 123 and Internet standards. 125 1.1.7 Use of Standard Credentials 127 Standard credential formats MUST be used to maximize interoperability of 128 common Public Key Infrastructures. 130 1.1.8 Transport Independent 132 The message MUST be transportable over the most common Internet transport 133 protocols. 135 1.1.9 Service Level Guarantee 137 The receiving agent MUST guarantee a response within the time designated by 138 the sender, or reject the message with an appropriate error message. 140 1.1.10 State Independence 142 There MUST be no state dependency by either a sender's or receiver's 143 application on the messaging protocol. 145 1.2. Terminology 147 Throughout this draft, the terms MUST, MUST NOT, SHOULD, and SHOULD NOT 148 are used in conformance to the definitions in [MUSTSHOULD]. 150 1.3. Definitions 152 Several terms will be used when specifying SCMP. 154 Trading Partners Two entities wishing to perform some on-line 155 request processing where authentication, 156 privacy, integrity and non-repudiation of the 157 requests are important. Trading partners have 158 established a trusted relationship between each 159 other. 161 Client An application program that executes on a remote 162 system, used by a trading partner to request 163 services from a server via an untrusted or 164 publicly switched packet network, like the 165 Internet. 167 Server An application program used to process SCMP 168 messages received from a client, and generate 169 appropriate replies which are sent back to the 170 client. 172 Sending Agent An entity that operates or uses a Client for 173 requesting on-line services from a server. 175 Receiving Agent An entity that operates a Server, receives and 176 processes requests from a plurality of Clients. 178 Request A discrete unit of service embodied in a single 179 SCMP message/reply pair. 181 Payload The meaningful content provided by a client to a 182 server, encapsulated in an SCMP message. Similarly 183 the meaningful content provided by a server to a 184 client, encapsulated in an SCMP message. 186 Message An interchangeable term used to mean a Request. 188 Reply An SCMP message sent from a server to a client. 190 Services Algorithms implemented by the server application 191 which are executed as designated by the payload. 192 Each available algorithm is a service. 194 2. Payload Encapsulation 196 The payload of an SCMP message MUST be prepared as a standard MIME 197 entity as defined in the [MIME] specification. The [SMIME] document 198 describes how the resulting MIME entity SHOULD be cryptographically 199 enhanced according to [PKCS-7]. 201 An SCMP compliant server SHOULD implement the three message types as 202 described in [SMIME], signed, enveloped, and signed/enveloped. A SCMP 203 compliant server MUST implement signed/envelope message type as 204 described in [SMIME]. 206 It is recommended, for non-repudiation concerns that the trading 207 partners SHOULD exchange signed or signed/enveloped SCMP message types. 209 It is also recommended that strong enough cryptographic methods 210 be used to insure authenticity, integrity, non-repudiation, and privacy 211 of the payload. But, if the trading partners form a private agreement, 212 clear data or signed-only data MAY be exchanged. However, an SCMP 213 compliant server MUST support encryption even if encryption is not being 214 used. 216 In addition to the standard MIME headers, a compliant implementation 217 MUST define "SCMP-protocol-version" and "SCMP-sender-name". These 218 headers added to the outer MIME entity, as described in [SMIME]. 220 Use of the remaining standard SMIME (outside MIME entity) headers are 221 assumed. This includes any additional implementation-specific headers. 222 These headers will most likely be ones that need to be processed prior 223 to payload decryption. 225 2.1 SCMP Protocol Version 227 The SCMP-protocol-version header is used to designate the SCMP protocol 228 version. Server implementations MAY reject the request based upon 229 protocol version, before any message processing occurs. 231 An example SCMP-protocol-version header will be in this format: 233 SCMP-protocol-version: v2.0 235 The possible protocol versions MUST be agreed upon by the trading 236 partners. 238 2.2 SCMP Sender Name 240 The SCMP-sender-name header is used to designate the SCMP sender name. 241 Thereby the sender name can be accessed before any decryption of the 242 request is performed. Server implementations MAY reject the request 243 based upon sender name, before any message processing occurs. 245 An SCMP-sender-name header will be in this format: 247 SCMP-sender-name: CyberSource 249 The possible sender names MUST be agreed upon by the trading partners. 251 3. SCMP Payload-based Headers 253 This section describes the payload-based extensions that MUST be 254 implemented by both the client and server to insure correct and proper 255 request processing. 257 Setting the SCMP service headers is the responsibility of the sending 258 agent's client application. Processing the SCMP payload headers is the 259 responsibility of the receiving agent's server application processing 260 the request. 262 The following headers are described for the payload of the S/MIME 263 entity, and MUST be prepared as defined in [MIME]. Thus if the S/MIME 264 message type is signed/enveloped ( which is recommended ), then the 265 SCMP headers will be encrypted with the sender's message payload. 267 3.1. Request Time to Live 269 This describes the amount of actual processing time in seconds the 270 client expects the server to complete payload processing prior to 271 responding with an appropriate reply. 273 An SCMP server receiving a SCMP message MUST evaluate the request time 274 to live value and determine if it can execute the required service(s) 275 in the amount of time designated. Assuming the server believes it can 276 complete the work within the allowed time, it will accept the request. 277 If not, the server MUST return an error to the client stating it 278 could not accept the request. 280 Once a server has accepted a request, it MUST process it until the time 281 to live value has been reached or until completion. If the time to live 282 value is reached during execution, the server MUST return an error to 283 the client stating that a time-out has occurred. 285 Application functions to insure data consistency, integrity, or 286 rollback after the time to live value has been exceeded will be the 287 responsibility of the server application. A policy on what application 288 actions a server will take upon exceeding a time to live value SHOULD 289 be published by the receiving agent operating the server. 291 An example of a policy in this are would be one where a receiving 292 agent's server will continue processing the request after a request 293 time to live value has been exceeded. Given this policy, a client, 294 having received a time-out error message, would send a "request 295 status message" to the server, referencing the original 296 scmp-request-id (from the message that timed out) in the message 297 payload. The server's reply to this status message would be the reply 298 that would have been sent had the processing time not exceeded the 299 time to live metric. 301 The time to live header will be in this format: 303 SCMP-request-time-to-live: 0..n (seconds) 305 3.2. Message Type 307 This value specifies the type of payload that is contained in the SCMP 308 message. The intent of this header is to provide a meta-level 309 description of the message payload and allow a receiving server to 310 decide which services or associated algorithms to use in processing 311 the payload. 313 Message type is specified as follows: 315 SCMP-message-type: [service-name]/[version-number] 317 The assignment of service names MUST be provided by the server to a 318 client at the time a service is published. For instance, if a service 319 was published called "CommerceService", the SCMP-message-type might 320 be represented as: 322 SCMP-message-type: CommerceService/1.0 324 It is assumed that trading partners will agree on service names 325 before requests are processed. 327 3.3. Request ID 329 A value in the format described in [822] that identifies a 330 specific instance of a request. Request ID's MUST be generated 331 by the client application, thus assuring that the scmp-request-id 332 is available in the event that the request cannot be sent to 333 the server due to errors. 335 An example of a request scmp-request-id is: 337 scmp-request-id: 0917293049096167904518 339 The scmp-request-id MUST be unique in the domain of a client 340 application and SHOULD NOT be easy to predict so as to prevent a 341 potential replay attack. 343 A client application, when preparing the scmp-request-id, SHOULD 344 perform a random number generation with sufficient degrees of 345 randomness, to ensure unpredictability, and generate a client side 346 time value, to ensure uniqueness of the result. These two data items 347 together SHOULD form the resulting scmp-request-id. 349 Servers MAY use a scmp-request-id as a reference and handle to the 350 original request during server message processing. 352 4. SCMP Data Block (Message Payload) 354 The payload or data block can be any arbitrary data type in the format 355 as specified by the SCMP-message-type. This payload forms the content 356 of the SMIME message as described in [SMIME]. 358 5. Certificates 360 Every trading partner implementing SCMP MUST exchange certificates that 361 have been issued and signed by one or more mutually trusted certificate 362 authorities. Prior to establishing trading partner relationships, the 363 sender and receiver MUST acquire mutually acceptable public root 364 certificates from the agreed upon certificate authority or authorities. 366 Trading partners, upon receiving or exchanging public key certificates 367 for the first time, SHOULD validate the certificate and certificate 368 chain before processing an SCMP request. 370 Prior to performing any application functions on a SCMP request 371 payload, the receiving agent's server MUST verify that the request has 372 been made by an authorized sender and that the sender's certificate has 373 not been revoked. 375 A server certificate revalidation policy, related to the frequency 376 certificates are revalidated against a certificate authority's 377 certificate revocation list, is not specified by SCMP. This matter is 378 left as a policy decision for the operator of the SCMP server. 380 6. Transport Implementations 382 SCMP can be implemented using any variety of transport methods as agreed 383 between trading partners. Here are a few examples. 385 http: This delivers a SCMP message to a server URL and should 386 use a POST function. 388 electronic mail: This will support a queued batch processing service 390 7. Receiving Server Functions 392 This section describes minimal server functions required to implement 393 SCMP. 395 7.1. General 397 A SCMP server receives a message from a client, processes the message 398 and generates a reply. If the message type is signed or signed/enveloped 399 the server initially validates the outer signature. If the outer 400 signature is not valid the server MUST NOT process the request further. 402 7.1.1. Message Timestamp 404 The time a request was sent SHOULD be derived from the standard SMIME 405 date header. Clients and servers SHOULD be synchronized using [NTP] 406 or Secure NTP. 408 The sender of an SCMP message MUST place the time a message was 409 dispatched into the SMIME header in [MIME] format. 411 The message timestamp SHOULD be used, in combination with the 412 scmp-request-id, by the server to aid in detection of a potential 413 replay attack. 415 It is recommended that servers SHOULD run a client-visible NTP server 416 to allow SCMP client applications to synchronize clocks as required. 418 7.1.2 Support for Request Non-Repudiation 420 Support for non-repudiation SHOULD be included in any complete SCMP 421 implementation, as described in the following subsections. If the 422 message is of signed or signed/enveloped type, the receiving 423 agent's server MUST implement support for non-repudiation. 425 7.1.2.1 Establish Trusted Trading Relationship 427 Prior to exchanging messages, sending and receiving agents MUST 428 exchange public key certificates. 430 7.1.2.2 Client Private Key Storage 432 The sending agent, maintaining a SCMP client application, MUST 433 maintain the private key in a secure location. Should a sending 434 agent loose control of their private key, they MUST notify 435 the receiving agent at the earliest possible time. 437 7.1.2.3 Client Message Signing 439 The client application signs SCMP messages using their private 440 key as described in [SMIME]. 442 7.1.2.4 Server Processing 444 The receiving agent's server application evaluates the digital 445 signature, thereby guaranteeing that the message payload has not been 446 altered in transit, and that the message was, in fact, signed by a 447 specific trading partner (client) who possess the proper credentials. 449 7.1.2.5 Server Accounting 451 The receiving agent's server application MUST store the original signed/ 452 encrypted message in an unprocessed state along with the timestamp for 453 identifying when the message was received. As the server processes the 454 sending agent's message, a record describing the processing steps along 455 with the appropriate timestamp MUST be appended to a accounting log 456 for the sending agent's request. 458 7.1.2.6 Revokation 460 All messages signed by a sending agent's client application in accordance 461 with [SMIME] and sent to a receiving agent's server SHALL be considered 462 non-repudiable. Repudiation occurs when the sending agent notifies 463 the receiving agent that the sending agent's public key certificate is 464 revoked. The timestamp of this revokation event MUST be the current time 465 at the receiving agent's server. Should a receiving agent's server 466 receive a request after being notified that the public key certificate 467 used to evaluate the sending agent's digital signature has been revoked, 468 this request MUST be considered invalid. 470 7.2. Application issues 472 The server MUST evaluate the signature of the message, if the message 473 is of signed or signed/enveloped type, prior to processing the message 474 payload. Within this process the server SHOULD obtain the senders 475 certificate via the distinguished name in the certificate as described 476 in [SMIME]. In performing this authentication process, the server MUST 477 validate the senders certificate and verify that the sender's 478 certificate is not listed in any available revocation systems. 480 Assuming the SCMP message's signature is valid, the server will process 481 requests with the appropriate service designated by the SCMP-message-type 482 value. 484 7.2.1. Request Serialization 486 A server MAY NOT guarantee serialized request processing. If 487 requests must be serialized, it is expected that all of the 488 serialized transactions will be received in a single message 489 payload or that other content specific serialization systems will be 490 used. 492 7.2.2. Server Errors 494 A server may encounter several classes of error conditions. The 495 server MUST be capable of reporting an error as described in section 8 496 of this document. Error Detection may vary based on specific 497 implementation. 499 A server MUST be capable of detecting a duplicate scmp-request-id 500 and reply to the sending client application with the reply of the 501 original request. Duplicate request detection MUST be based on the 502 scmp-request-id and the distinguished name of the signer to prevent 503 denial of service attacks. 505 In the event of a duplicate request being detected the server MUST: 506 1) lookup the prior request 507 2) verify the sender is the same 508 3) return an appropriate error message to the client. 510 In the event that the three above steps fail, the server MUST return 511 an appropriate SCMP error message. 513 8. Protocol Level Error Messages 515 In general SCMP does not concern itself with application level errors. 516 Such errors MUST be returned in an SCMP reply with appropriate 517 application specific formatting. 519 8.1. Format 521 SCMP error messages are returned by a server as signed data. SCMP errors 522 MUST NOT be encrypted to permit clients to process encryption related 523 errors. 525 The format of SCMP errors is: 527 SCMP 529 8.2. Client Application Error Handling 531 Client action in the case of error return is error specific and not 532 defined. If the server fails to return any reply within twice the 533 time to live requested (due to unspecified server or network 534 failure) the client SHOULD re-send the request. Upon receipt of a 535 duplicate request the server will respond as described in 7.2.2. 536 Clients MUST NOT retry a request in an interval which is less than 537 the time to live value of the original request. 539 9. Author's Address 541 Tom Arnold 542 CyberSource Corporation 543 550 S. Winchester Blvd., #301 544 San Jose, CA 95128 545 E-mail: toma@cybersource.com 546 Phone: 408-556-9100 548 Jason Eaton 549 CyberSource Corporation 550 550 S. Winchester Blvd., #301 551 San Jose, CA 95128 552 E-mail: jeaton@cybersource.com 553 Phone: 408-556-9100 555 Michael Jimenez 556 CyberSource Corporation 557 550 S. Winchester Blvd., #301 558 San Jose, CA 95128 559 E-mail: mjimenez@cybersource.com 560 Phone: 408-556-9100 562 Hubert Chen 563 CyberSource Corporation 564 550 S. Winchester Blvd., #301 565 San Jose, CA 95128 566 E-mail: hubertc@cybersource.com 567 Phone: 408-556-9100 569 10. Acknowledgements 571 The authors wish to recognize and thank several individuals 572 (listed in alphabetic order) who have and continue to 573 support the development of requirements and improvement of 574 this protocol. 576 Mike Agostino (Vulcan), Ron Bose (LitleNet), David Burdett (Mondex), 577 Leonard Cantor (IBM), Dan Corcoran (Equifax), Steve Crocker 578 (Crocker Assoc.), Tony Curwen (Ingram Micro), Donald Eastlake (IBM), 579 Richard Frank (Intertrust), James Gavin (Commercenet), Paul 580 Guthrie (VISA International), Bengamin Hipp (FUSA/Paymentech), 581 Andy Jeffrey (Sonnet Financial), Helle Jespersen (IBM), 582 "Sean Kiewiet" , Connie Lindgreen (IBM), 583 Michael Myers (VeriSign), Allan Ottosen (PBS), John Pettitt 584 (Beyond.com), Jesse Rendleman (CyberSource), Don Sloan 585 (Tech Data), Carl Stucke (Equifax), Frank Tyksen (Portland 586 Software), Huy Vu (VISA USA), Sean Youssefi (CobWeb) 588 11. References 590 [822] D. Crocker, "Standard for the format of ARPA Internet 591 text messages." RFC 0822, IETF, Aug. 1982. 593 [SMIME] S. Dusse, et. al, "S/MIME Version 2 Message 594 Specification", RFC 2311, IETF, March 1998. 596 [MIME] "MIME Part1: Format of Internet Message Bodies", RFC 597 2045; "MIME Part2: Media Types", RFC 2046; "MIME Part 598 3: Message Header Extensions for Non-ASCII Text", RFC 599 2047; "MIME Part 4: Registration Procedures", RFC 600 2048; "MIME Part 5: Conformance Criteria and 601 Examples", RFC 2049, IETF. 603 [MUSTSHOULD] "Key words for use in RFCs to Indicate Requirement 604 Levels", RFC 2119, IETF. 606 [NTP] D. Mills. "Network Time Protocol", RFC 1119, IETF, 607 September 1989. 609 [PKCS-7] B. Kaliski, "PKCS #7: Cryptograpic Message Syntax" 610 RFC 2315, IETF, March 1998.