summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3855.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3855.txt')
-rw-r--r--doc/rfc/rfc3855.txt675
1 files changed, 675 insertions, 0 deletions
diff --git a/doc/rfc/rfc3855.txt b/doc/rfc/rfc3855.txt
new file mode 100644
index 0000000..c0415ed
--- /dev/null
+++ b/doc/rfc/rfc3855.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+Network Working Group P. Hoffman
+Request for Comments: 3855 IMC
+Category: Standards Track C. Bonatti
+ IECA
+ July 2004
+
+
+ Transporting Secure/Multipurpose Internet Mail
+ Extensions (S/MIME) Objects in X.400
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2004).
+
+Abstract
+
+ This document describes protocol options for conveying objects that
+ have been protected using the Cryptographic Message Syntax (CMS) and
+ Secure/Multipurpose Internet Mail Extensions (S/MIME) version 3.1
+ over an X.400 message transfer system.
+
+1. Introduction
+
+ The techniques described in the Cryptographic Message Syntax [CMS]
+ specification and message specifications can reasonably be
+ transported via a variety of electronic mail systems. This
+ specification defines the options and values necessary to enable
+ interoperable transport of S/MIME messages over an X.400 system.
+
+ This document describes a mechanism for using CMS objects as the
+ message content of X.400 messages in a native X.400 environment.
+ This means that gateways or other functions that expect to deal with
+ IPMS, such as those specified in [MIXER] and [BODYMAP], cannot do
+ anything with these messages. Note that cooperating S/MIME agents
+ must support common forms of message content in order to achieve
+ interoperability.
+
+ Definition of gateway services to support relay of CMS object between
+ X.400 and SMTP environments is beyond the scope of this document.
+
+
+
+
+Hoffman & Bonatti Standards Track [Page 1]
+
+RFC 3855 Transporting S/MIME Objects in X.400 July 2004
+
+
+1.1. Terminology
+
+ The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED",
+ and "MAY" in this document are to be interpreted as described in BCP
+ 14, RFC 2119 [MUSTSHOULD].
+
+1.2. Definitions
+
+ For the purposes of this document, the following definitions apply.
+
+ ASN.1: Abstract Syntax Notation One, as defined in ISO/IEC 8824.
+
+ Object Identifier (OID): A globally unique identifier value
+ consisting of a sequence of integer values assigned through
+ distributed registration as specified by ISO/IEC 8824.
+
+ Transfer Encoding: A reversible transformation made on data so 8-bit
+ or binary data may be sent via a channel that only transmits 7-bit
+ data.
+
+1.3. Compatibility with Existing S/MIME Implementations
+
+ It is a goal of this document to, if possible, maintain backward
+ compatibility with existing X.400 implementations that employ S/MIME
+ v3.1 wrappers.
+
+2. S/MIME Packaging
+
+2.1. The X.400 Message Structure
+
+ This section reviews the X.400 message format. An X.400 message has
+ two parts, the envelope and the content, as described in X.402
+ [X.400]:
+
+ Envelope -- An information object whose composition varies from one
+ transmittal step to another and that variously identifies the
+ message's originator and potential recipients, documents its
+ previous conveyance and directs its subsequent conveyance by the
+ Message Transfer System (MTS), and characterizes its content.
+
+ Content -- The content is the piece of information that the
+ originating User Agent wants to be delivered to one or more
+ recipients. The MTS neither examines nor modifies the content,
+ except for conversion, during its conveyance of the message. MTS
+ conversion is not applicable to the scenario of this document
+ because such conversion is incompatible with CMS protection
+ mechanisms.
+
+
+
+
+Hoffman & Bonatti Standards Track [Page 2]
+
+RFC 3855 Transporting S/MIME Objects in X.400 July 2004
+
+
+ One piece of information borne by the envelope identifies the type of
+ the content. The content type is an identifier (an ASN.1 OID or
+ Integer) that denotes the syntax and semantics of the content
+ overall. This identifier enables the MTS to determine the message's
+ deliverability to particular users, and enables User Agents and
+ Message Stores to interpret and process the content.
+
+ Some X.400 content types further refine the structure of content as a
+ set of heading elements and body parts. An example of this is the
+ Interpersonal Messaging System (IPMS). The IPMS content structure is
+ able to convey zero or more arbitrary body parts each identified by
+ the body part type. The body part type is an ASN.1 OID or Integer
+ that denotes the syntax and semantics of the body part in question.
+
+2.2. Carrying S/MIME as X.400 Content
+
+ When transporting a CMS-protected message in X.400, the preferred
+ approach (except as discussed in section 2.3 below) is to convey the
+ object as X.400 message content. This section describes how S/MIME
+ CMS objects are conveyed as the content part of X.400 messages. This
+ mechanism is suitable for transport of CMS-protected messages
+ regardless of the mail content that has been encapsulated.
+
+ Implementations MUST include the CMS object in the content field of
+ the X.400 message.
+
+ If the CMS object is covered by an outer MIME wrapper, the content-
+ type field of the P1 envelope MUST be set to the following CMS-
+ defined value:
+
+ id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
+ rsadsi(113549) pkcs(1) pkcs7(7) 1 }
+
+ If the CMS object is not covered by an outer MIME wrapper, the
+ content-type field of the P1 envelope MUST be set to the following
+ CMS-defined value:
+
+ id-ct-contentInfo OBJECT IDENTIFIER ::= { iso(1) member-body(2)
+ us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
+ content-types(1) 6}
+
+2.2.1. Carrying Plaintext MIME objects as X.400 Content
+
+ When transporting a plaintext MIME object in X.400, the preferred
+ approach is to convey the object as X.400 message content. The
+
+
+
+
+
+
+Hoffman & Bonatti Standards Track [Page 3]
+
+RFC 3855 Transporting S/MIME Objects in X.400 July 2004
+
+
+ content-type field of the P1 envelope MUST be set to the following
+ CMS-defined value:
+
+ id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
+ rsadsi(113549) pkcs(1) pkcs7(7) 1 }
+
+2.3. Carrying S/MIME as IPMS Body Parts
+
+ Under some circumstances S/MIME CMS-protected messages can be
+ conveyed within select body parts of the content. Implementations
+ generally SHOULD NOT embed CMS objects within X.400 body parts, but
+ should instead convey them as content as described in section 2.2.
+ Nevertheless, one notable exception is necessary for the case of
+ forwarding.
+
+ In instances when CMS objects are forwarded as part of a message
+ forwarding function, use of a body part is necessary. When
+ forwarding a CMS object in an IPMS or IPMS-compatible body part,
+ implementations MUST use the content-body-part as formally defined by
+ [X.400], as shown below for reference.
+
+ content-body-part {ExtendedContentType:content-type}
+ EXTENDED-BODY-PART-TYPE ::= {
+ PARAMETERS {ForwardedContentParameters IDENTIFIED BY
+ {id-ep-content -- concatenated with content-type -- }},
+ DATA {Content IDENTIFIED BY
+ {id-et-content -- concatenated with content-type -- }} }
+
+ ForwardedContentParameters ::= SET {
+ delivery-time [0] MessageDeliveryTime OPTIONAL,
+ delivery-envelope [1] OtherMessageDeliveryFields OPTIONAL,
+ mts-identifier [2] MessageDeliveryIdentifier OPTIONAL }
+
+ id-ep-content ::= {joint-iso-itu-t(2) mhs(6) ipms(1) ep(11) 17}
+
+ id-et-content ::= {joint-iso-itu-t(2) mhs(6) ipms(1) et(4) 17}
+
+ The implementation MUST copy the CMS object to be forwarded into the
+ Content field of the content-body-part. The direct-reference field
+ of the body part MUST include the OID formed by the concatenation of
+ the id-et-content value and the following CMS-defined value.
+
+ id-ct-contentInfo OBJECT IDENTIFIER ::=
+ { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
+ pkcs-9(9) smime(16) content-types(1) 6}
+
+ For example, to forward any CMS object the DATA component of the body
+ part would be identified by { 2 6 1 4 17 1 2 840 113549 1 9 16 1 6 }.
+
+
+
+Hoffman & Bonatti Standards Track [Page 4]
+
+RFC 3855 Transporting S/MIME Objects in X.400 July 2004
+
+
+ The ForwardedContentParameters are optional and MAY be supported at
+ the discretion of the implementor. The OID value id-et-content MAY
+ also be included in the original-encoded-information-types field of
+ the X.400 message envelope at the discretion of the sending S/MIME
+ agent.
+
+ In this instance, the content-type field of the P1 envelope MUST be
+ set to the value associate with the forwarding content (e.g., integer
+ 22 for IPMS).
+
+2.4. Transfer Encoding
+
+ According to various S/MIME specifications for message wrapping, CMS
+ objects MAY optionally be wrapped in MIME to dynamically support 7-
+ bit transport. This outer wrapping is not required for X.400
+ transport, and generally SHOULD NOT be applied in a homogeneous X.400
+ environment. Heterogeneous mail systems or other factors MAY require
+ the presence of this outer MIME wrapper
+
+2.5. Encoded Information Type Indication
+
+ In [MSG], the application/pkcs7-mime content type and optional
+ "smime-type" parameter are used to convey details about the security
+ applied (signed or enveloped) along with information about the
+ contained content. This may aid receiving S/MIME implementations in
+ correctly processing the secured content. Additional values of
+ smime-type are defined in [ESS]. In an X.400 transport environment,
+ MIME typing is not available. Therefore the equivalent semantic is
+ conveyed using the Encoded Information Types (EITs). The EITs are
+ conveyed in the original-encoded-information-types field of the X.400
+ message envelope. This memo defines the following smime-types.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman & Bonatti Standards Track [Page 5]
+
+RFC 3855 Transporting S/MIME Objects in X.400 July 2004
+
+
+ +-----------------------------------------------------+
+ | |
+ | smime-type EIT Value (OID) |
+ | CMS protection type Inner Content |
+ | |
+ +-----------------------------------------------------+
+ | |
+ | enveloped-data id-eit-envelopedData |
+ | EnvelopedData Data |
+ | |
+ | signed-data id-eit-signedData |
+ | SignedData Data |
+ | |
+ | certs-only id-eit-certsOnly |
+ | SignedData empty (zero-length content) |
+ | |
+ | signed-receipt id-eit-signedReceipt |
+ | SignedData Receipt |
+ | |
+ | enveloped-x400 id-eit-envelopedx400 |
+ | EnvelopedData X.400 content |
+ | |
+ | signed-x400 id-eit-signedx400 |
+ | SignedData X.400 content |
+ | |
+ | compressed-data id-eit-compressedData |
+ | CompressedData RFC 3274 compression wrapper |
+ | |
+ +-----------------------------------------------------+
+
+ Sending agents SHOULD include the appropriate S/MIME EIT OID value.
+ Receiving agents SHOULD recognize S/MIME OID values in the EITs
+ field, and process the message appropriately according to local
+ procedures.
+
+ In order that consistency can be obtained in future S/MIME EIT
+ assignments, the following guidelines should be followed when
+ assigning new EIT values. Values assigned for S/MIME EITs should
+ correspond to assigned smime-type values on a one-to-one basis. The
+ restrictions of section 3.2.2 of [MSG] therefore apply. S/MIME EIT
+ values may coexist with other EIT values intended to further qualify
+ the makeup of the protected content.
+
+
+
+
+
+
+
+
+
+Hoffman & Bonatti Standards Track [Page 6]
+
+RFC 3855 Transporting S/MIME Objects in X.400 July 2004
+
+
+2.5.1. Enveloped Data
+
+ The enveloped data EIT indicates that the X.400 content field
+ contains a MIME type that has been protected by the CMS enveloped-
+ data content type in accordance with [MSG]. The resulting enveloped
+ data CMS content is conveyed in accordance with section 2.2. This
+ EIT should be indicated by the following OID value:
+
+ id-eit-envelopedData OBJECT IDENTIFIER ::=
+ { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
+ pkcs-9(9) smime(16) id-eit(10) id-eit-envelopedData(1) }
+
+2.5.2. Signed Data
+
+ The signed data EIT indicates that the X.400 content field contains a
+ MIME type that has been protected by the CMS signed-data content type
+ in accordance with [MSG]. The resulting signed data CMS content is
+ conveyed in accordance with section 2.2. This EIT should be
+ indicated by the following OID value:
+
+ id-eit-signedData OBJECT IDENTIFIER ::=
+ { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
+ pkcs-9(9) smime(16) id-eit(10) id-eit-signedData(2) }
+
+2.5.3. Certs Only
+
+ The certs-only message is used to transport certificates and/or CRLs,
+ such as in response to a registration request. This is described in
+ [CERT31]. The certs-only message consists of a single instance of
+ CMS content of type signed-data. The encapContentInfo eContent field
+ MUST be absent and signerInfos field MUST be empty. The resulting
+ certs-only CMS content is conveyed in accordance with section 2.2.
+ This EIT should be indicated by the following OID value:
+
+ id-eit-certsOnly OBJECT IDENTIFIER ::=
+ { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
+ pkcs-9(9) smime(16) id-eit(10) id-eit-certsOnly(3) }
+
+2.5.4. Signed Receipt
+
+ The signed receipt EIT indicates that the X.400 content field
+ contains a Receipt content that has been protected by the CMS
+ signed-data content type in accordance with [ESS]. The resulting CMS
+ signed-data content is conveyed in accordance with section 2.2. This
+ EIT should be indicated by the following OID value:
+
+
+
+
+
+
+Hoffman & Bonatti Standards Track [Page 7]
+
+RFC 3855 Transporting S/MIME Objects in X.400 July 2004
+
+
+ id-eit-signedReceipt OBJECT IDENTIFIER ::=
+ { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
+ pkcs-9(9) smime(16) id-eit(10) id-eit-signedReceipt(4) }
+
+2.5.5. Enveloped X.400
+
+ The enveloped X.400 EIT indicates that the X.400 content field
+ contains X.400 content that has been protected by the CMS enveloped-
+ data content type in accordance with [X400WRAP]. The resulting
+ enveloped X.400 CMS content is conveyed in accordance with section
+ 2.2. This EIT should be indicated by the following OID value:
+
+ id-eit-envelopedX400 OBJECT IDENTIFIER ::=
+ { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
+ pkcs-9(9) smime(16) id-eit(10) id-eit-envelopedX400(5) }
+
+2.5.6. Signed X.400
+
+ The signed X.400 EIT indicates that the X.400 content field contains
+ X.400 content that has been protected by the CMS signed-data content
+ type in accordance with [X400WRAP]. The resulting signed X.400 CMS
+ content is conveyed in accordance with section 2.2. This EIT should
+ be indicated by the following OID value:
+
+ id-eit-signedX400 OBJECT IDENTIFIER ::=
+ { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
+ pkcs-9(9) smime(16) id-eit(10) id-eit-signedX400(6) }
+
+2.5.7. Compressed Data
+
+ The compressed data EIT indicates that the X.400 content field
+ contains a another type that has been compressed by the compressed-
+ data content type in accordance with [COMPRESS]. The resulting CMS
+ content is conveyed in accordance with section 2.2. This EIT should
+ be indicated by the following OID value:
+
+ id-eit-compressedData OBJECT IDENTIFIER ::=
+ { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
+ pkcs-9(9) smime(16) id-eit(10) id-eit-compressedData(7) }
+
+2.6. Interaction with X.400 Elements of Service
+
+ Care should be taken in the selection of X.400 services to be used in
+ conjunction with CMS objects. Services affecting conversion of the
+ content, expansion of Distribution Lists (DLs), and message
+ redirection can interact badly with services provided by the
+ "EnvelopedData" and "SignedData" CMS content types.
+
+
+
+
+Hoffman & Bonatti Standards Track [Page 8]
+
+RFC 3855 Transporting S/MIME Objects in X.400 July 2004
+
+
+2.6.1. MTS Conversion Services
+
+ MTS conversion is not applicable to the scenario of this document
+ because such conversion is incompatible with CMS protection
+ mechanisms. X.400 systems that implement conversion services should
+ generally be unable to attempt conversion of CMS content types
+ because those types do not conform to X.420 structure rules.
+ Nevertheless, when transporting CMS objects within an X.400
+ environment, the Conversion Prohibition service SHOULD be selected.
+
+2.6.2. Message Redirection Services
+
+ X.400 message redirection services can have an indirect impact on the
+ application of the CMS "EnvelopedData" content type. Several
+ different forms of redirection are possible in X.400, including:
+
+ - Originator Requested Alternate Recipient (ORAR)
+ - Alternate Recipient Assignment
+ - Redirection of Incoming Messages
+
+ In addition, any auto-forwarding services that are not security-aware
+ may share the same problem. An auto-forwarding implementation that
+ removes the EnvelopedData and reapplies it for the forwarded
+ recipient is not affected by this problem. The normal case is that
+ the private key is not available when the human user is not present,
+ thus decryption is not possible. However, if the private key is
+ present, forwarding can be used instead.
+
+ When the "EnvelopedData" content type is used to protect message
+ contents, an instance of RecipientInfo is needed for each recipient
+ and alternate recipient in order to ensure the desired access to the
+ message. A RecipientInfo for the originator is a good practice just
+ in case the MTS returns the whole message.
+
+ In the event that ORAR is used, the originator is aware of the
+ identity of the alternate recipient and SHOULD include a
+ corresponding RecipientInfo element. For other forms of redirection
+ (including non-security-aware auto-forwarding) the alternate
+ recipient must either have access to the intended recipient's keys
+ (not recommended) or must relay the message to the intended recipient
+ by other means.
+
+2.6.3. DL Expansion
+
+ X.400 DLs can have an indirect impact on the application of the CMS
+ "EnvelopedData" content type. When the "EnvelopedData" content type
+ is used to protect message contents, an instance of RecipientInfo is
+ needed for each recipient in order to ensure the desired access to
+
+
+
+Hoffman & Bonatti Standards Track [Page 9]
+
+RFC 3855 Transporting S/MIME Objects in X.400 July 2004
+
+
+ the message. Messages to a DL would typically include only a single
+ RecipientInfo associated with the DL. Unlike Mail Lists (MLs)
+ described in [ESS], however, X.400 DLs are not generally security-
+ aware and do not regenerate RecipientInfo elements for the DL
+ members. It is recommended that a security-aware ML conforming to
+ [ESS] be used in preference to X.400 DLs. When transporting CMS
+ objects within an X.400 environment, the DL Expansion Prohibited
+ service SHOULD be selected.
+
+3. Security Considerations
+
+ This specification introduces no new security concerns to the CMS or
+ S/MIME models. Security issues are identified in section 5 of [MSG],
+ section 6 of [ESS] and the Security Considerations section of [CMS].
+
+4. References
+
+4.1. Normative References
+
+ [MUSTSHOULD] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [CERT31] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail
+ Extensions (S/MIME) Version 3.1 Certificate Handling",
+ RFC 3850, July 2004.
+
+ [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC
+ 3852, July 2004.
+
+ [COMPRESS] Gutmann, P., "Compressed Data Content Type for
+ Cryptographic Message Syntax (CMS)", RFC 3274, June
+ 2002.
+
+ [ESS] Hoffman, P., Ed., "Enhanced Security Services for
+ S/MIME", RFC 2634, June 1999.
+
+ [MSG] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail
+ Extensions (S/MIME) Version 3.1 Message Specification",
+ RFC 3851, July 2004.
+
+ [X.400] ITU-T X.400 Series of Recommendations, Information
+ technology - Message Handling Systems (MHS). X.400:
+ System and Service Overview; X.402: Overall
+ Architecture; X.411: Message Transfer System: Abstract
+ Service Definition and Procedures; X.420: Interpersonal
+ Messaging System; 1996.
+
+
+
+
+
+Hoffman & Bonatti Standards Track [Page 10]
+
+RFC 3855 Transporting S/MIME Objects in X.400 July 2004
+
+
+4.2. Informative References
+
+ [BODYMAP] Alvestrand, H., "Mapping between X.400 and RFC-822/MIME
+ Message Bodies", RFC 2157, January 1998.
+
+ [MIXER] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay):
+ Mapping between X.400 and RFC 822/MIME", RFC 2156,
+ January 1998.
+
+ [X400WRAP] Hoffman, P., Bonatti, C., and A. Eggen, "Securing X.400
+ Content with Secure/Multipurpose Internet Mail
+ Extensions (S/MIME), RFC 3854, July 2004.
+
+5. Authors' Addresses
+
+ Paul Hoffman
+ Internet Mail Consortium
+ 127 Segre Place
+ Santa Cruz, CA 95060 USA
+
+ EMail: phoffman@imc.org
+
+
+ Chris Bonatti
+ IECA, Inc.
+ 15309 Turkey Foot Road
+ Darnestown, MD 20878-3640 USA
+
+ EMail: bonattic@ieca.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman & Bonatti Standards Track [Page 11]
+
+RFC 3855 Transporting S/MIME Objects in X.400 July 2004
+
+
+6. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2004). This document is subject
+ to the rights, licenses and restrictions contained in BCP 78, and
+ except as set forth therein, the authors retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at ietf-
+ ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+Hoffman & Bonatti Standards Track [Page 12]
+