doc: Add RFC documents

1 files changed, 1347 insertions, 0 deletions

diff --git a/doc/rfc/rfc3183.txt b/doc/rfc/rfc3183.txt
new file mode 100644
index 0000000..4640e68
--- /dev/null
+++ b/doc/rfc/rfc3183.txt
@@ -0,0 +1,1347 @@
+
+
+
+
+
+
+Network Working Group                                            T. Dean
+Request for Comments: 3183                                    W. Ottaway
+Category: Experimental                                           QinetiQ
+                                                            October 2001
+
+
+                 Domain Security Services using S/MIME
+
+Status of this Memo
+
+   This memo defines an Experimental Protocol for the Internet
+   community.  It does not specify an Internet standard of any kind.
+   Discussion and suggestions for improvement are requested.
+   Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2001).  All Rights Reserved.
+
+Abstract
+
+   This document describes how the S/MIME (Secure/Multipurpose Internet
+   Mail Extensions) protocol can be processed and generated by a number
+   of components of a communication system, such as message transfer
+   agents, guards and gateways to deliver security services.  These
+   services are collectively referred to as 'Domain Security Services'.
+
+Acknowledgements
+
+   Significant comments were made by Luis Barriga, Greg Colla, Trevor
+   Freeman, Russ Housley, Dave Kemp, Jim Schaad and Michael Zolotarev.
+
+1. Introduction
+
+   The S/MIME [1] series of standards define a data encapsulation format
+   for the provision of a number of security services including data
+   integrity, confidentiality, and authentication.  S/MIME is designed
+   for use by messaging clients to deliver security services to
+   distributed messaging applications.
+
+   The mechanisms described in this document are designed to solve a
+   number of interoperability problems and technical limitations that
+   arise when different security domains wish to communicate securely,
+   for example when two domains use incompatible messaging technologies
+   such as the X.400 series and SMTP/MIME, or when a single domain
+   wishes to communicate securely with one of its members residing on an
+   untrusted domain.  The scenarios covered by this document are
+   domain-to-domain, individual-to-domain and domain-to-individual
+
+
+
+Dean & Ottaway                Experimental                      [Page 1]
+
+RFC 3183         Domain Security Services using S/MIME      October 2001
+
+
+   communications.  This document is also applicable to organizations
+   and enterprises that have internal PKIs which are not accessible by
+   the outside world, but wish to interoperate securely using the S/MIME
+   protocol.
+
+   There are many circumstances when it is not desirable or practical to
+   provide end-to-end (desktop-to-desktop) security services,
+   particularly between different security domains.  An organization
+   that is considering providing end-to-end security services will
+   typically have to deal with some if not all of the following issues:
+
+   1) Heterogeneous message access methods: Users are accessing mail
+      using mechanisms which re-format messages, such as using Web
+      browsers.  Message reformatting in the Message Store makes end-
+      to-end encryption and signature validation impossible.
+
+   2) Message screening and audit: Server-based mechanisms such as
+      searching for prohibited words or other content, virus scanning,
+      and audit, are incompatible with end-to-end encryption.
+
+   3) PKI deployment issues: There may not be any certificate paths
+      between two organizations.  Or an organization may be sensitive
+      about aspects of its PKI and unwilling to expose them to outside
+      access.  Also, full PKI deployment for all employees, may be
+      expensive, not necessary or impractical for large organizations.
+      For any of these reasons, direct end-to-end signature validation
+      and encryption are impossible.
+
+   4) Heterogeneous message formats: One organization using X.400 series
+      protocols wishes to communicate with another using SMTP.  Message
+      reformatting at gateways makes end-to-end encryption and signature
+      validation impossible.
+
+   This document describes an approach to solving these problems by
+   providing message security services at the level of a domain or an
+   organization.  This document specifies how these 'domain security
+   services' can be provided using the S/MIME protocol.  Domain security
+   services may replace or complement mechanisms at the desktop.  For
+   example, a domain may decide to provide desktop-to-desktop signatures
+   but domain-to-domain encryption services.  Or it may allow desktop-
+   to-desktop services for intra-domain use, but enforce domain-based
+   services for communication with other domains.
+
+   Domain services can also be used by individual members of a
+   corporation who are geographically remote and who wish to exchange
+   encrypted and/or signed messages with their base.
+
+
+
+
+
+Dean & Ottaway                Experimental                      [Page 2]
+
+RFC 3183         Domain Security Services using S/MIME      October 2001
+
+
+   Whether or not a domain based service is inherently better or worse
+   than desktop based solutions is an open question.  Some experts
+   believe that only end-to-end solutions can be truly made secure,
+   while others believe that the benefits offered by such things as
+   content checking at domain boundaries offers considerable increase in
+   practical security for many real systems.  The additional service of
+   allowing signature checking at several points on a communications
+   path is also an extra benefit in many situations.  This debate is
+   outside the scope of this document.  What is offered here is a set of
+   tools that integrators can tailor in different ways to meet different
+   needs in different circumstances.
+
+   Message transfer agents (MTAs), guards, firewalls and protocol
+   translation gateways all provide domain security services.  As with
+   desktop based solutions, these components must be resilient against a
+   wide variety of attacks intended to subvert the security services.
+   Therefore, careful consideration should be given to security of these
+   components, to make sure that their siting and configuration
+   minimises the possibility of attack.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [2].
+
+2. Overview of Domain Security Services
+
+   This section gives an informal overview of the security services that
+   are provided by S/MIME between different security domains.  These
+   services are provided by a combination of mechanisms in the sender's
+   and recipient's domains.
+
+   Later sections describe definitively how these services map onto
+   elements of the S/MIME protocol.
+
+   The following security mechanisms are specified in this document:
+
+   1. Domain signature
+   2. Review signature
+   3. Additional attributes signature
+   4. Domain encryption and decryption
+
+   The signature types defined in this document are referred to as
+   DOMSEC defined signatures.
+
+
+
+
+
+
+
+
+Dean & Ottaway                Experimental                      [Page 3]
+
+RFC 3183         Domain Security Services using S/MIME      October 2001
+
+
+   The term 'security domain' as used in this document is defined as a
+   collection of hardware and personnel operating under a single
+   security authority and performing a common business function.
+   Members of a security domain will of necessity share a high degree of
+   mutual trust, due to their shared aims and objectives.
+
+   A security domain is typically protected from direct outside attack
+   by physical measures and from indirect (electronic) attack by a
+   combination of firewalls and guards at network boundaries.  The
+   interface between two security domains is termed a 'security
+   boundary'.  One example of a security domain is an organizational
+   network ('Intranet').
+
+2.1 Domain Signature
+
+   A domain signature is an S/MIME signature generated on behalf of a
+   set of users in a domain.  A domain signature can be used to
+   authenticate information sent between domains or between a certain
+   domain and one of its individuals, for example, when two 'Intranets'
+   are connected using the Internet, or when an Intranet is connected to
+   a remote user over the Internet.  It can be used when two domains
+   employ incompatible signature schemes internally or when there are no
+   certification links between their PKIs.  In both cases messages from
+   the originator's domain are signed over the original message and
+   signature (if present) using an algorithm, key, and certificate which
+   can be processed by the recipient(s) or the recipient(s) domain.  A
+   domain signature is sometimes referred to as an "organizational
+   signature".
+
+2.2 Review Signature
+
+   A third party may review messages before they are forwarded to the
+   final recipient(s) who may be in the same or a different security
+   domain.  Organizational policy and good security practice often
+   require that messages be reviewed before they are released to
+   external recipients.  Having reviewed a message, an S/MIME signature
+   is added to it - a review signature.  An agent could check the review
+   signature at the domain boundary, to ensure that only reviewed
+   messages are released.
+
+2.3 Additional Attributes Signature
+
+   A third party can add additional attributes to a signed message.  An
+   S/MIME signature is used for this purpose - an additional attributes
+   signature.  An example of an additional attribute is the 'Equivalent
+   Label' attribute defined in ESS [3].
+
+
+
+
+
+Dean & Ottaway                Experimental                      [Page 4]
+
+RFC 3183         Domain Security Services using S/MIME      October 2001
+
+
+2.4 Domain Encryption and Decryption
+
+   Domain encryption is S/MIME encryption performed on behalf of a
+   collection of users in a domain.  Domain encryption can be used to
+   protect information between domains, for example, when two
+   'Intranets' are connected using the Internet.  It can also be used
+   when end users do not have PKI/encryption capabilities at the
+   desktop, or when two domains employ incompatible encryption schemes
+   internally.  In the latter case messages from the originator's domain
+   are encrypted (or re-encrypted) using an algorithm, key, and
+   certificate which can be decrypted by the recipient(s) or an entity
+   in their domain.  This scheme also applies to protecting information
+   between a single domain and one of its members when both are
+   connected using an untrusted network, e.g., the Internet.
+
+3. Mapping of the Signature Services to the S/MIME Protocol
+
+   This section describes the S/MIME protocol elements that are used to
+   provide the security services described above.  ESS [3] introduces
+   the concept of triple-wrapped messages that are first signed, then
+   encrypted, then signed again.  This document also uses this concept
+   of triple-wrapping.  In addition, this document also uses the concept
+   of 'signature encapsulation'.  'Signature encapsulation' denotes a
+   signed or unsigned message that is wrapped in a signature, this
+   signature covering both the content and the first (inner) signature,
+   if present.
+
+   Signature encapsulation MAY be performed on the inner and/or the
+   outer signature of a triple-wrapped message.
+
+   For example, the originator signs a message which is then
+   encapsulated with an 'additional attributes' signature.  This is then
+   encrypted.  A reviewer then signs this encrypted data, which is then
+   encapsulated by a domain signature.
+
+   There is a possibility that some policies will require signatures to
+   be added in a specific order.  By only allowing signatures to be
+   added by encapsulation it is possible to determine the order in which
+   the signatures have been added.
+
+   A DOMSEC defined signature MAY encapsulate a message in one of the
+   following ways:
+
+   1) An unsigned message has an empty signature layer added to it
+      (i.e., the message is wrapped in a signedData that has a
+      signerInfos which contains no elements).  This is to enable
+      backward compatibility with S/MIME software that does not have a
+      DOMSEC capability.  Since the signerInfos will contain no signers
+
+
+
+Dean & Ottaway                Experimental                      [Page 5]
+
+RFC 3183         Domain Security Services using S/MIME      October 2001
+
+
+      the eContentType, within the EncapsulatedContentInfo, MUST be id-
+      data as described in CMS [5].  However, the eContent field will
+      contain the unsigned message instead of being left empty as
+      suggested in section 5.2 in CMS [5].  This is so that when the
+      DOMSEC defined signature is added, as defined in method 2) below,
+      the signature will cover the unsigned message.
+
+   2) Signature Encapsulation is used to wrap the original signed
+      message with a DOMSEC defined signature.  This is so that the
+      DOMSEC defined signature covers the message and all the previously
+      added signatures.  Also, it is possible to determine that the
+      DOMSEC defined signature was added after the signatures that are
+      already there.
+
+3.1 Naming Conventions and Signature Types
+
+   An entity receiving an S/MIME signed message would normally expect
+   the signature to be that of the originator of the message.  However,
+   the message security services defined in this document require the
+   recipient to be able to accept messages signed by other entities
+   and/or the originator.  When other entities sign the message the name
+   in the certificate will not match the message sender's name.  An
+   S/MIME compliant implementation would normally flag a warning if
+   there were a mismatch between the name in the certificate and the
+   message sender's name.  (This check prevents a number of types of
+   masquerade attack.)
+
+   In the case of domain security services, this warning condition
+   SHOULD be suppressed under certain circumstances.  These
+   circumstances are defined by a naming convention that specifies the
+   form that the signers name SHOULD adhere to.  Adherence to this
+   naming convention avoids the problems of uncontrolled naming and the
+   possible masquerade attacks that this would produce.
+
+   As an assistance to implementation, a signed attribute is defined to
+   be included in the S/MIME signature - the 'signature type' attribute.
+   On receiving a message containing this attribute, the naming
+   convention checks are invoked.
+
+   Implementations conforming to this standard MUST support the naming
+   convention for signature generation and verification.
+   Implementations conforming to this standard MUST recognize the
+   signature type attribute for signature verification.  Implementations
+   conforming to this standard MUST support the signature type attribute
+   for signature generation.
+
+
+
+
+
+
+Dean & Ottaway                Experimental                      [Page 6]
+
+RFC 3183         Domain Security Services using S/MIME      October 2001
+
+
+3.1.1 Naming Conventions
+
+   The following naming conventions are specified for agents generating
+   signatures specified in this document:
+
+   *  For a domain signature, an agent generating this signature MUST be
+      named 'domain-signing-authority'
+
+   *  For a review signature, an agent generating this signature MUST be
+      named 'review-authority'.
+
+   *  For an additional attributes signature, an agent generating this
+      signature MUST be named 'attribute-authority'.
+
+   This name shall appear as the 'common name (CN)' component of the
+   subject field in the X.509 certificate.  There MUST be only one CN
+   component present.  Additionally, if the certificate contains an RFC
+   822 address, this name shall appear in the end entity component of
+   the address - on the left-hand side of the '@' symbol.
+
+   In the case of a domain signature, an additional naming rule is
+   defined: the 'name mapping rule'.  The name mapping rule states that
+   for a domain signing authority, the domain part of its name MUST be
+   the same as, or an ascendant of, the domain name of the message
+   originator(s) that it is representing.  The domain part is defined as
+   follows:
+
+   *  In the case of an X.500 distinguished subject name of an X.509
+      certificate, the domain part is the country, organization,
+      organizational unit, state, and locality components of the
+      distinguished name.
+
+   *  In the case of an RFC 2247 distinguished name, the domain part is
+      the domain components of the distinguished name.
+
+   *  If the certificate contains an RFC 822 address, the domain part is
+      defined to be the RFC 822 address component on the right-hand side
+      of the '@' symbol.
+
+   For example, a domain signing authority acting on behalf of John Doe
+   of the Acme corporation, whose distinguished name is 'cn=John Doe,
+   ou=marketing,o=acme,c=us' and whose e-mail address is
+   John.Doe@marketing.acme.com, could have a certificate containing a
+   distinguished name of
+   'cn=domain-signing-authority,o=acme,c=us' and an RFC 822 address of
+   'domain-signing-authority@acme.com'.  If John Doe has an RFC 2247
+
+
+
+
+
+Dean & Ottaway                Experimental                      [Page 7]
+
+RFC 3183         Domain Security Services using S/MIME      October 2001
+
+
+   defined address of 'cn=John Doe,dc=marketing,dc=acme,dc=us' then an
+   address of 'cn=domain-signing-authority,dc=acme,dc=us' could be used
+   to represent the domain signing authority.
+
+   When the X.500 distinguished subject name has consecutive
+   organizational units and/or localities it is important to understand
+   the ordering of these values in order to determine if the domain part
+   of the domain signature is an ascendant.  In this case, when parsing
+   the distinguished subject name from the most significant component
+   (i.e., country, locality or organization) the parsed organizational
+   unit or locality is deemed to be the ascendant of consecutive
+   (unparsed) organizational units or localities.
+
+   When parsing an RFC 2247 subject name from the most significant
+   component (i.e., the 'dc' entry that represents the country, locality
+   or organization) the parsed 'dc' entry is deemed to be the ascendant
+   of consecutive (unparsed) 'dc' entries.
+
+   For example, a domain signing authority acting on behalf of John Doe
+   of the Acme corporation, whose distinguished name is 'cn=John Doe,
+   ou=marketing,ou=defence,o=acme,c=us' and whose e-mail address is
+   John.Doe@marketing.defence.acme.com, could have a certificate
+   containing a distinguished name of 'cn=domain-signing-
+   authority,ou=defence,o=acme,c=us' and an RFC 822 address of 'domain-
+   signing-authority@defence.acme.com'.  If John Doe has an RFC 2247
+   defined address of 'cn=John
+   Doe,dc=marketing,dc=defense,dc=acme,dc=us' then the domain signing
+   authority could have a distinguished name of 'cn=domain-signing-
+   authority,dc=defence,dc=acme,dc=us'.
+
+   Any message received where the domain part of the domain signing
+   agent's name does not match, or is not an ascendant of, the
+   originator's domain name MUST be flagged.
+
+   This naming rule prevents agents from one organization masquerading
+   as domain signing authorities on behalf of another.  For the other
+   types of signature defined in this document, no such named mapping
+   rule is defined.
+
+   Implementations conforming to this standard MUST support this name
+   mapping convention as a minimum.  Implementations MAY choose to
+   supplement this convention with other locally defined conventions.
+   However, these MUST be agreed between sender and recipient domains
+   prior to secure exchange of messages.
+
+   On verifying the signature, a receiving agent MUST ensure that the
+   naming convention has been adhered to.  Any message that violates the
+   convention MUST be flagged.
+
+
+
+Dean & Ottaway                Experimental                      [Page 8]
+
+RFC 3183         Domain Security Services using S/MIME      October 2001
+
+
+3.1.2 Signature Type Attribute
+
+   An S/MIME signed attribute is used to indicate the type of signature.
+   This should be used in conjunction with the naming conventions
+   specified in the previous section.  When an S/MIME signed message
+   containing the signature type attribute is received it triggers the
+   software to verify that the correct naming convention has been used.
+
+   The ASN.1 [4] notation of this attribute is: -
+
+      SignatureType ::= SEQUENCE OF OBJECT IDENTIFIER
+
+      id-sti  OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840)
+                  rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 9 }
+
+      -- signature type identifier
+
+   If present, the SignatureType attribute MUST be a signed attribute,
+   as defined in [5].  If the SignatureType attribute is absent and
+   there are no further encapsulated signatures the recipient SHOULD
+   assume that the signature is that of the message originator.
+
+   All of the signatures defined here are generated and processed as
+   described in [5].  They are distinguished by the presence of the
+   following values in the SignatureType signed attribute:
+
+      id-sti-domainSig OBJECT IDENTIFIER ::= { id-sti 2 }
+      -- domain signature.
+
+      id-sti-addAttribSig OBJECT IDENTIFIER ::= { id-sti 3 }
+      -- additional attributes signature.
+
+      id-sti-reviewSig OBJECT IDENTIFIER ::= { id-sti 4 }
+      -- review signature.
+
+   For completeness, an attribute type is also specified for an
+   originator signature.  However, this signature type is optional.  It
+   is defined as follows:
+
+      id-sti-originatorSig OBJECT IDENTIFIER ::= { id-sti 1 }
+      -- originator's signature.
+
+   All signature types, except the originator type, MUST encapsulate
+   other signatures.  Note a DOMSEC defined signature could be
+   encapsulating an empty signature as defined in section 3.
+
+
+
+
+
+
+Dean & Ottaway                Experimental                      [Page 9]
+
+RFC 3183         Domain Security Services using S/MIME      October 2001
+
+
+   A SignerInfo MUST NOT include multiple instances of SignatureType.  A
+   signed attribute representing a SignatureType MAY include multiple
+   instances of different SignatureType values as an AttributeValue of
+   attrValues [5], as long as the SignatureType 'additional attributes'
+   is not present.
+
+   If there is more than one SignerInfo in a signerInfos (i.e., when
+   different algorithms are used) then the SignatureType attribute in
+   all the SignerInfos MUST contain the same content.
+
+   The following sections describe the conditions under which each of
+   these types of signature may be generated, and how they are
+   processed.
+
+3.2 Domain Signature Generation and Verification
+
+   A 'domain signature' is a proxy signature generated on a user's
+   behalf in the user's domain.  The signature MUST adhere to the naming
+   conventions in 3.1.1, including the name mapping convention.  A
+   'domain signature' on a message authenticates the fact that the
+   message has been released from that domain.  Before signing, a
+   process generating a 'domain signature' MUST first satisfy itself of
+   the authenticity of the message originator.  This is achieved by one
+   of two methods.  Either the 'originator's signature' is checked, if
+   S/MIME signatures are used inside a domain.  Or if not, some
+   mechanism external to S/MIME is used, such as the physical address of
+   the originating client or an authenticated IP link.
+
+   If the originator's authenticity is successfully verified by one of
+   the above methods and all other signatures present are valid,
+   including those that have been encrypted, a 'domain signature' can be
+   added to a message.
+
+   If a 'domain signature' is added and the message is received by a
+   Mail List Agent (MLA) there is a possibility that the 'domain
+   signature' will be removed.  To stop the 'domain signature' from
+   being removed the steps in section 5 MUST be followed.
+
+   An entity generating a domain signature MUST do so using a
+   certificate containing a subject name that follows the naming
+   convention specified in 3.1.1.
+
+   If the originator's authenticity is not successfully verified or all
+   the signatures present are not valid, a 'domain signature' MUST NOT
+   be generated.
+
+
+
+
+
+
+Dean & Ottaway                Experimental                     [Page 10]
+
+RFC 3183         Domain Security Services using S/MIME      October 2001
+
+
+   On reception, the 'domain signature' SHOULD be used to verify the
+   authenticity of a message.  A check MUST be made to ensure that both
+   the naming convention and the name mapping convention have been used
+   as specified in this standard.
+
+   A recipient can assume that successful verification of the domain
+   signature also authenticates the message originator.
+
+   If there is an originator signature present, the name in that
+   certificate SHOULD be used to identify the originator.  This
+   information can then be displayed to the recipient.
+
+   If there is no originator signature present, the only assumption that
+   can be made is the domain the message originated from.
+
+   A domain signer can be assumed to have verified any signatures that
+   it encapsulates.  Therefore, it is not necessary to verify these
+   signatures before treating the message as authentic.  However, this
+   standard does not preclude a recipient from attempting to verify any
+   other signatures that are present.
+
+   The 'domain signature' is indicated by the presence of the value id-
+   sti-domainSig in a 'signature type' signed attribute.
+
+   There MAY be one or more 'domain signature' signatures in an S/MIME
+   encoding.
+
+3.3 Additional Attributes Signature Generation and Verification
+
+   The 'additional attributes' signature type indicates that the
+   SignerInfo contains additional attributes that are associated with
+   the message.
+
+   All attributes in the applicable SignerInfo MUST be treated as
+   additional attributes.  Successful verification of an 'additional
+   attributes' signature means only that the attributes are
+   authentically bound to the message.  A recipient MUST NOT assume that
+   its successful verification also authenticates the message
+   originator.
+
+   An entity generating an 'additional attributes' signature MUST do so
+   using a certificate containing a subject name that follows the naming
+   convention specified in 3.1.1.  On reception, a check MUST be made to
+   ensure that the naming convention has been used.
+
+
+
+
+
+
+
+Dean & Ottaway                Experimental                     [Page 11]
+
+RFC 3183         Domain Security Services using S/MIME      October 2001
+
+
+   A signer MAY include any of the attributes listed in [3] or in this
+   document when generating an 'additional attributes' signature.  The
+   following attributes have a special meaning, when present in an
+   'additional attributes' signature:
+
+   1) Equivalent Label: label values in this attribute are to be treated
+      as equivalent to the security label contained in an encapsulated
+      SignerInfo, if present.
+
+   2) Security Label: the label value indicates the aggregate
+      sensitivity of the inner message content plus any encapsulated
+      signedData and envelopedData containers.  The label on the
+      original data is indicated by the value in the originator's
+      signature, if present.
+
+   An 'additional attributes' signature is indicated by the presence of
+   the value id-sti-addAttribSig in a 'signature type' signed attribute.
+   Other Object Identifiers MUST NOT be included in the sequence of OIDs
+   if this value is present.
+
+   There MAY be multiple 'additional attributes' signatures in an S/MIME
+   encoding.
+
+3.4 Review Signature Generation and Verification
+
+   The review signature indicates that the signer has reviewed the
+   message.  Successful verification of a review signature means only
+   that the signer has approved the message for onward transmission to
+   the recipient(s).  When the recipient is in another domain, a device
+   on a domain boundary such as a Mail Guard or firewall may be
+   configured to check review signatures.  A recipient MUST NOT assume
+   that its successful verification also authenticates the message
+   originator.
+
+   An entity generating a signed review signature MUST do so using a
+   certificate containing a subject name that follows the naming
+   convention specified in 3.1.1.  On reception, a check MUST be made to
+   ensure that the naming convention has been used.
+
+   A review signature is indicated by the presence of the value id-sti-
+   reviewSig in a 'signature type' signed attribute.
+
+   There MAY be multiple review signatures in an S/MIME encoding.
+
+
+
+
+
+
+
+
+Dean & Ottaway                Experimental                     [Page 12]
+
+RFC 3183         Domain Security Services using S/MIME      October 2001
+
+
+3.5 Originator Signature
+
+   The 'originator signature' is used to indicate that the signer is the
+   originator of the message and its contents.  It is included in this
+   document for completeness only.  An originator signature is indicated
+   either by the absence of the signature type attribute, or by the
+   presence of the value id-sti-originatorSig in a 'signature type'
+   signed attribute.
+
+4. Encryption and Decryption
+
+   Message encryption may be performed by a third party on behalf of a
+   set of originators in a domain.  This is referred to as domain
+   encryption.  Message decryption may be performed by a third party on
+   behalf of a set of recipients in a domain.  This is referred to as
+   domain decryption.  The third party that performs these processes is
+   referred to in this section as a "Domain Confidentiality Authority"
+   (DCA).  Both of these processes are described in this section.
+
+   Messages may be encrypted for decryption by the final recipient
+   and/or by a DCA in the recipient's domain.  The message may also be
+   encrypted for decryption by a DCA in the originator's domain (e.g.,
+   for content analysis, audit, key word scanning, etc.).  The choice of
+   which of these is actually performed is a system specific issue that
+   depends on system security policy.  It is therefore outside the scope
+   of this document.  These processes of encryption and decryption
+   processes are shown in the following table.
+
+ --------------------------------------------------------------------
+|                        | Recipient Decryption |  Domain Decryption |
+|------------------------|----------------------|--------------------|
+| Originator Encryption  |       Case(a)        |       Case(b)      |
+| Domain Encryption      |       Case(c)        |       Case(d)      |
+ --------------------------------------------------------------------
+
+   Case (a), encryption of messages by the originator for decryption by
+   the final recipient(s), is described in CMS [5].  In cases (c) and
+   (d), encryption is performed not by the originator but by the DCA in
+   the originator's domain. In cases (b) and (d), decryption is
+   performed not by the recipient(s) but by the DCA in the recipient's
+   domain.
+
+   A client implementation that conforms to this standard MUST support
+   case (b) for transmission, case (c) for reception and case (a) for
+   transmission and reception.
+
+
+
+
+
+
+Dean & Ottaway                Experimental                     [Page 13]
+
+RFC 3183         Domain Security Services using S/MIME      October 2001
+
+
+   A DCA implementation that conforms to this standard MUST support
+   cases (c) and (d), for transmission, and cases (b) and (d) for
+   reception.  In cases (c) and (d) the 'domain signature' SHOULD be
+   applied before the encryption.  In cases (b) and (d) the message
+   SHOULD be decrypted before the originators 'domain signature' is
+   obtained and verified.
+
+   The process of encryption and decryption is documented in CMS [5].
+   The only additional requirement introduced by domain encryption and
+   decryption is for greater flexibility in the management of keys, as
+   described in the following subsections.  As with signatures, a naming
+   convention and name mapping convention are used to locate the correct
+   public key.
+
+   The mechanisms described below are applicable both to key agreement
+   and key transport systems, as documented in CMS [5].  The phrase
+   'encryption key' is used as a collective term to cover the key
+   management keys used by both techniques.
+
+   The mechanisms below are also applicable to individual roving users
+   who wish to encrypt messages that are sent back to base.
+
+4.1 Domain Confidentiality Naming Conventions
+
+   A DCA MUST be named 'domain-confidentiality-authority'.  This name
+   MUST appear in the 'common name(CN)' component of the subject field
+   in the X.509 certificate.  Additionally, if the certificate contains
+   an RFC 822 address, this name MUST appear in the end entity part of
+   the address, i.e., on the left-hand side of the '@' symbol.
+
+   Along with this naming convention, an additional naming rule is
+   defined:  the 'name mapping rule'.  The name mapping rule states that
+   for a DCA, the domain part of its name MUST be the same as, or an
+   ascendant of (as defined in section 3.1.1), the domain name of the
+   set of entities that it represents.  The domain part is defined as
+   follows:
+
+   *  In the case of an X.500 distinguished name of an X.509
+      certificate, the domain part is the country, organization,
+      organizational unit, state, and locality components of the
+      distinguished name.
+
+   * In the case of an RFC 2247 distinguished name, the domain part is
+      the domain components of the distinguished name.
+
+   * If the certificate contains an RFC 822 address, the domain part is
+      defined to be the RFC 822 address part on the right-hand side of
+      the '@' symbol.
+
+
+
+Dean & Ottaway                Experimental                     [Page 14]
+
+RFC 3183         Domain Security Services using S/MIME      October 2001
+
+
+   For example, a DCA acting on behalf of John Doe of the Acme
+   corporation, whose distinguished name is 'cn=John Doe,ou=marketing,
+   o=acme,c=us' and whose e-mail address is John.Doe@marketing.acme.com,
+   could have a certificate containing a distinguished name of
+   'cn=domain-confidentiality-authority,o=acme,c=us' and an e-mail
+   address of 'domain-confidentiality-authority@acme.com'.  If John Doe
+   has an RFC 2247 defined address of 'cn=John Doe,dc=marketing,
+   dc=defense,dc=acme,dc=us' then the domain signing authority could
+   have a distinguished name of
+   'cn=domain-signing-authority,dc=defence,dc=acme,dc=us'.  The key
+   associated with this certificate would be used for encrypting
+   messages for John Doe.
+
+   Any message received where the domain part of the domain encrypting
+   agents name does not match, or is not an ascendant of, the domain
+   name of the entities it represents MUST be flagged.
+
+   This naming rule prevents messages being encrypted for the wrong
+   domain decryption agent.
+
+   Implementations conforming to this standard MUST support this name
+   mapping convention as a minimum.  Implementations may choose to
+   supplement this convention with other locally defined conventions.
+   However, these MUST be agreed between sender and recipient domains
+   prior to sending any messages.
+
+4.2 Key Management for DCA Encryption
+
+   At the sender's domain, DCA encryption is achieved using the
+   recipient DCA's certificate or the end recipient's certificate.  For
+   this, the encrypting process must be able to correctly locate the
+   certificate for the corresponding DCA in the recipient's domain or
+   the one corresponding to the end recipient.  Having located the
+   correct certificate, the encryption process is then performed and
+   additional information required for decryption is conveyed to the
+   recipient in the recipientInfo field as specified in CMS [5].  A DCA
+   encryption agent MUST be named according to the naming convention
+   specified in section 4.1.  This is so that the corresponding
+   certificate can be found.
+
+   No specific method for locating the certificate to the corresponding
+   DCA in the recipient's domain or the one corresponding to the end
+   recipient is mandated in this document.  An implementation may choose
+   to access a local certificate store to locate the correct
+   certificate.  Alternatively, a X.500 or LDAP directory may be used in
+   one of the following ways:
+
+
+
+
+
+Dean & Ottaway                Experimental                     [Page 15]
+
+RFC 3183         Domain Security Services using S/MIME      October 2001
+
+
+   1. The directory may store the DCA certificate in the recipient's
+      directory entry.  When the user certificate attribute is
+      requested, this certificate is returned.
+
+   2. The encrypting agent maps the recipient's name to the DCA name in
+      the manner specified in 4.1.  The user certificate attribute
+      associated with this directory entry is then obtained.
+
+   This document does not mandate either of these processes.  Whichever
+   one is used, the name mapping conventions must be adhered to, in
+   order to maintain confidentiality.
+
+   Having located the correct certificate, the encryption process is
+   then performed.  A recipientInfo for the DCA or end recipient is then
+   generated, as described in CMS [5].
+
+   DCA encryption may be performed for decryption by the end recipient
+   and/or by a DCA.  End recipient decryption is described in CMS [5].
+   DCA decryption is described in section 4.3.
+
+4.3 Key Management for DCA Decryption
+
+   DCA decryption uses a private-key belonging to the DCA and the
+   necessary information conveyed in the DCA's recipientInfo field.
+
+   It should be noted that domain decryption can be performed on
+   messages encrypted by the originator and/or by a DCA in the
+   originator's domain.  In the first case, the encryption process is
+   described in CMS [5]; in the second case, the encryption process is
+   described in 4.2.
+
+5. Applying a Domain Signature when Mail List Agents are Present.
+
+   It is possible that a message leaving a DOMSEC domain may encounter a
+   Mail List Agent (MLA) before it reaches the final recipient.  There
+   is a possibility that this would result in the 'domain signature'
+   being stripped off the message.  We do not want a MLA to remove the
+   'domain signature'.  Therefore, the 'domain signature' must be
+   applied to the message in such a way that will prevent a MLA from
+   removing it.
+
+   A MLA will search a message for the "outer" signedData layer, as
+   defined in ESS [3] section 4.2, and strip off all signedData layers
+   that encapsulate this "outer" signedData layer.  Where this "outer"
+   signedData layer is found will depend on whether the message contains
+   a mlExpansionHistory attribute or an envelopedData layer.
+
+
+
+
+
+Dean & Ottaway                Experimental                     [Page 16]
+
+RFC 3183         Domain Security Services using S/MIME      October 2001
+
+
+   There is a possibility that a message leaving a DOMSEC domain has
+   already been processed by a MLA, in which case a 'mlExpansionHistory'
+   attribute will be present within the message.
+
+   There is a possibility that the message will contain an envelopedData
+   layer.  This will be the case when the message has been encrypted
+   within the domain for the domain's "Domain Confidentiality
+   Authority", see section 4.0, and, possibly, the final recipient.
+
+   How the 'domain signature' is applied will depend on what is already
+   present within the message.  Before the 'domain signature' can be
+   applied the message MUST be searched for the "outer" signedData
+   layer, this search is complete when one of the following is found: -
+
+      -  The "outer" signedData layer that includes an
+         mlExpansionHistory attribute or encapsulates an envelopedData
+         object.
+      -  An envelopedData layer.
+      -  The original content (that is, a layer that is neither
+         envelopedData nor signedData).
+
+   If a signedData layer containing a mlExpansionHistory attribute has
+   been found then: -
+
+      1) Strip off the signedData layer (after remembering the included
+         signedAttributes).
+
+      2) Search the rest of the message until an envelopedData layer or
+         the original content is found.
+
+      3) a) If an envelopedData layer has been found then: -
+
+            -  Strip off all the signedData layers down to the
+               envelopedData layer.
+            -  Locate the RecipientInfo for the local DCA and use the
+               information it contains to obtain the message key.
+            -  Decrypt the encryptedContent using the message key.
+            -  Encapsulate the decrypted message with a 'domain
+               signature'
+            -  If local policy requires the message to be encrypted
+               using S/MIME encryption before leaving the domain then
+               encapsulate the 'domain signature' with an envelopedData
+               layer containing RecipientInfo structures for each of the
+               recipients and an originatorInfo value built from
+               information describing this DCA.
+
+
+
+
+
+
+Dean & Ottaway                Experimental                     [Page 17]
+
+RFC 3183         Domain Security Services using S/MIME      October 2001
+
+
+               If local policy does not require the message to be
+               encrypted using S/MIME encryption but there is an
+               envelopedData at a lower level within the message then
+               the 'domain signature' MUST be encapsulated by an
+               envelopedData as described above.
+
+               An example when it may not be local policy to require
+               S/MIME encryption is when there is a link crypto present.
+
+      b) If an envelopedData layer has not been found then: -
+
+            -  Encapsulate the new message with a 'domain signature'.
+
+      4) Encapsulate the new message in a signedData layer, adding the
+         signedAttributes from the signedData layer that contained the
+         mlExpansionHistory attribute.
+
+   If no signedData layer containing a mlExpansionHistory attribute has
+   been found but an envelopedData has been found then: -
+
+      1) Strip off all the signedData layers down to the envelopedData
+         layer.
+      2) Locate the RecipientInfo for the local DCA and use the
+         information it contains to obtain the message key.
+      3) Decrypt the encryptedContent using the message key.
+      4) Encapsulate the decrypted message with a 'domain signature'
+      5) If local policy requires the message to be encrypted before
+         leaving the domain then encapsulate the 'domain signature' with
+         an envelopedData layer containing RecipientInfo structures for
+         each of the recipients and an originatorInfo value built from
+         information describing this DCA.
+
+         If local policy does not require the message to be encrypted
+         using S/MIME encryption but there is an envelopedData at a
+         lower level within the message then the 'domain signature' MUST
+         be encapsulated by an envelopedData as described above.
+
+   If no signedData layer containing a mlExpansionHistory attribute has
+   been found and no envelopedData has been found then: -
+
+      1) Encapsulate the message in a 'domain signature'.
+
+5.1 Examples of Rule Processing
+
+   The following examples help explain the above rules.  All of the
+   signedData objects are valid and none of them are a domain signature.
+   If a signedData object was a domain signature then it would not be
+   necessary to validate any further signedData objects.
+
+
+
+Dean & Ottaway                Experimental                     [Page 18]
+
+RFC 3183         Domain Security Services using S/MIME      October 2001
+
+
+   1) A message (S1 (Original Content)) (where S = signedData) in which
+      the signedData does not include an mlExpansionHistory attribute is
+      to have a 'domain signature' applied.  The signedData, S1, is
+      verified.  No "outer" signedData is found, after searching for one
+      as defined above, since the original content is found, nor is an
+      envelopedData or a mlExpansionHistory attribute found.  A new
+      signedData layer, S2, is created that contains a 'domain
+      signature', resulting in the following message sent out of the
+      domain (S2 (S1 (Original Content))).
+
+   2) A message (S3 (S2 (S1 (Original Content))) in which none of the
+      signedData layers includes an mlExpansionHistory attribute is to
+      have a 'domain signature' applied.  The signedData objects S1, S2
+      and S3 are verified.  There is not an original, "outer" signedData
+      layer since the original content is found, nor is an envelopedData
+      or a mlExpansionHistory attribute found.  A new signedData layer,
+      S4, is created that contains a 'domain signature', resulting in
+      the following message sent out of the domain (S4 (S3 (S2 (S1
+      (Original Content))).
+
+   3) A message (E1 (S1 (Original Content))) (where E = envelopedData)
+      in which S1 does not include a mlExpansionHistory attribute is to
+      have a 'domain signature' applied.  There is not an original,
+      received "outer" signedData layer since the envelopedData, E1, is
+      found at the outer layer.  The encryptedContent is decrypted.  The
+      signedData, S1, is verified.  The decrypted content is wrapped in
+      a new signedData layer, S2, which contains a 'domain signature'.
+      If local policy requires the message to be encrypted, using S/MIME
+      encryption, before it leaves the domain then this new message is
+      wrapped in an envelopedData layer, E2, resulting in the following
+      message sent out of the domain (E2 (S2 (S1 (Original Content)))),
+      else the message is not wrapped in an envelopedData layer
+      resulting in the following message (S2 (S1 (Original Content)))
+      being sent.
+
+   4) A message (S2 (E1 (S1 (Original Content)))) in which S2 includes a
+      mlExpansionHistory attribute is to have a 'domain signature'
+      applied.  The signedData object S2 is verified.  The
+      mlExpansionHistory attribute is found in S2, so S2 is the "outer"
+      signedData.  The signed attributes in S2 are remembered for later
+      inclusion in the new outer signedData that is applied to the
+      message.  S2 is stripped off and the message is decrypted.  The
+      signedData object S1 is verified.  The decrypted message is
+      wrapped in a signedData layer, S3, which contains a 'domain
+      signature'.  If local policy requires the message to be encrypted,
+      using S/MIME encryption, before it leaves the domain then this new
+      message is wrapped in an envelopedData layer, E2.  A new
+      signedData layer, S4, is then wrapped around the envelopedData,
+
+
+
+Dean & Ottaway                Experimental                     [Page 19]
+
+RFC 3183         Domain Security Services using S/MIME      October 2001
+
+
+      E2, resulting in the following message sent out of the domain (S4
+      (E2 (S3 (S1 (Original Content))))).  If local policy does not
+      require the message to be encrypted, using S/MIME encryption,
+      before it leaves the domain then the message is not wrapped in an
+      envelopedData layer but is wrapped in a new signedData layer, S4,
+      resulting in the following message sent out of the domain (S4 (S3
+      (S1 (Original Content).  The signedData S4, in both cases,
+      contains the signed attributes from S2.
+
+   5) A message (S3 (S2 (E1 (S1 (Original Content))))) in which none of
+      the signedData layers include a mlExpansionHistory attribute is to
+      have a 'domain signature' applied.  The signedData objects S3 and
+      S2 are verified.  When the envelopedData E1 is found the
+      signedData objects S3 and S2 are stripped off.  The
+      encryptedContent is decrypted.  The signedData object S1 is
+      verified.  The decrypted content is wrapped in a new signedData
+      layer, S4, which contains a 'domain signature'.  If local policy
+      requires the message to be encrypted, using S/MIME encryption,
+      before it leaves the domain then this new message is wrapped in an
+      envelopedData layer, E2, resulting in the following message sent
+      out of the domain (E2 (S4 (S1 (Original Content)))), else the
+      message is not wrapped in an envelopedData layer resulting in the
+      following message (S4 (S1 (Original Content))) being sent.
+
+   6) A message (S3 (S2 (E1 (S1 (Original Content))))) in which S3
+      includes a mlExpansionHistory attribute is to have a 'domain
+      signature' applied.  The signedData objects S3 and S2 are
+      verified.  The mlExpansionHistory attribute is found in S3, so S3
+      is the "outer" signedData.  The signed attributes in S3 are
+      remembered for later inclusion in the new  outer signedData that
+      is applied to the message.  The signedData object S3 is stripped
+      off.  When the envelopedData layer, E1, is found the signedData
+      object S2 is stripped off.  The encryptedContent is decrypted.
+      The signedData object S1 is verified.  The decrypted content is
+      wrapped in a new signedData layer, S4, which contains a 'domain
+      signature'.  If local policy requires the message to be encrypted,
+      using S/MIME encryption, before it leaves the domain then this new
+      message is wrapped in an envelopedData layer, E2.  A new
+      signedData layer, S5, is then wrapped around the envelopedData,
+      E2, resulting in the following message sent out of the domain (S5
+      (E2 (S4 (S1 (Original Content))))).  If local policy does not
+      require the message to be encrypted, using S/MIME encryption,
+      before it leaves the domain then the message is not wrapped in an
+      envelopedData layer but is wrapped in a new signedData layer, S5,
+      resulting in the following message sent out of the domain (S5 (S4
+      (S1 (Original Content).  The signedData S5, in both cases,
+      contains the signed attributes from S3.
+
+
+
+
+Dean & Ottaway                Experimental                     [Page 20]
+
+RFC 3183         Domain Security Services using S/MIME      October 2001
+
+
+   7) A message (S3 (E2 (S2 (E1 (S1 (Original Content)))))) in which S3
+      does not include a mlExpansionHistory attribute is to have a
+      'domain signature' applied.  The signedData object S3 is verified.
+      When the envelopedData E2 is found the signedData object S3 is
+      stripped off.  The encryptedContent is decrypted.  The signedData
+      object S2 is verified, the envelopedData E1 is decrypted and the
+      signedData object S1 is verified.  The signedData object S2 is
+      wrapped in a new signedData layer S4, which contains a 'domain
+      signature'.  Since there is an envelopedData E1 lower down in the
+      message, the new message is wrapped in an envelopedData layer, E3,
+      resulting in the following message sent out of the domain (E3 (S4
+      (S2 (E1 (S1 (Original Content)))))).
+
+6. Security Considerations
+
+   This specification relies on the existence of several well known
+   names, such as domain-confidentiality-authority.  Organizations must
+   take care with these names, even if they do not support DOMSEC, so
+   that certificates issued in these names are only issued to legitimate
+   entities.  If this is not true then an individual could get a
+   certificate associated with domain-confidentiality-authority@acme.com
+   and as a result might be able to read messages the a DOMSEC client
+   intended for others.
+
+   Implementations MUST protect all private keys.  Compromise of the
+   signer's private key permits masquerade.
+
+   Similarly, compromise of the content-encryption key may result in
+   disclosure of the encrypted content.
+
+   Compromise of key material is regarded as an even more serious issue
+   for domain security services than for an S/MIME client.  This is
+   because compromise of the private key may in turn compromise the
+   security of a whole domain.  Therefore, great care should be used
+   when considering its protection.
+
+   Domain encryption alone is not secure and should be used in
+   conjunction with a domain signature to avoid a masquerade attack,
+   where an attacker that has obtained a DCA certificate can fake a
+   message to that domain pretending to be another domain.
+
+   When an encrypted DOMSEC message is sent to an end user in such a way
+   that the message is decrypted by the end users DCA the message will
+   be in plain text and therefore confidentiality could be compromised.
+
+
+
+
+
+
+
+Dean & Ottaway                Experimental                     [Page 21]
+
+RFC 3183         Domain Security Services using S/MIME      October 2001
+
+
+   If the recipient's DCA is compromised then the recipient can not
+   guarantee the integrity of the message.  Furthermore, even if the
+   recipient's DCA correctly verifies a message's signatures, then a
+   message could be undetectably modified, when there are no signatures
+   on a message that the recipient can verify.
+
+7. DOMSEC ASN.1 Module
+
+   DOMSECSyntax
+    { iso(1) member-body(2) us(840) rsadsi(113549)
+          pkcs(1) pkcs-9(9) smime(16) modules(0) domsec(10) }
+
+    DEFINITIONS IMPLICIT TAGS ::=
+    BEGIN
+
+    -- EXPORTS All
+    -- The types and values defined in this module are exported for
+    -- use in the other ASN.1 modules.  Other applications may use
+    -- them for their own purposes.
+
+    SignatureType ::= SEQUENCE OF OBJECT IDENTIFIER
+
+    id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
+             us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 16 }
+
+    id-sti  OBJECT IDENTIFIER ::= { id-smime 9 }   -- signature type
+    identifier
+
+    -- Signature Type Identifiers
+
+    id-sti-originatorSig       OBJECT IDENTIFIER ::= { id-sti 1 }
+    id-sti-domainSig           OBJECT IDENTIFIER ::= { id-sti 2 }
+    id-sti-addAttribSig        OBJECT IDENTIFIER ::= { id-sti 3 }
+    id-sti-reviewSig           OBJECT IDENTIFIER ::= { id-sti 4 }
+
+    END -- of DOMSECSyntax
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dean & Ottaway                Experimental                     [Page 22]
+
+RFC 3183         Domain Security Services using S/MIME      October 2001
+
+
+8. References
+
+   [1] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 2633,
+       June 1999.
+
+   [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+       Levels", BCP 14, RFC 2119, March 1997.
+
+   [3] Hoffman, P., "Enhanced Security Services for S/MIME", RFC 2634,
+       June 1999.
+
+   [4] International Telecommunications Union, Recommendation X.208,
+       "Open systems interconnection: specification of Abstract Syntax
+       Notation (ASN.1)", CCITT Blue Book, 1989.
+
+   [5] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999.
+
+9. Authors' Addresses
+
+   Tim Dean
+   QinetiQ
+   St. Andrews Road
+   Malvern
+   Worcs
+   WR14 3PS
+
+   Phone: +44 (0) 1684 894239
+   Fax:   +44 (0) 1684 896660
+   EMail: tbdean@QinetiQ.com
+
+   William Ottaway
+   QinetiQ
+   St. Andrews Road
+   Malvern
+   Worcs
+   WR14 3PS
+
+   Phone: +44 (0) 1684 894079
+   Fax:   +44 (0) 1684 896660
+   EMail: wjottaway@QinetiQ.com
+
+
+
+
+
+
+
+
+
+
+
+Dean & Ottaway                Experimental                     [Page 23]
+
+RFC 3183         Domain Security Services using S/MIME      October 2001
+
+
+10.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2001).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dean & Ottaway                Experimental                     [Page 24]
+