[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits] [IPR]

Versions: 00 01 02 03 04 05 RFC 5752

      SMIME Working Group                                    Sean Turner, IECA
      Internet Draft                                  Jim Schaad, Soaring Hawk
      Expires June 4, 2007
                                                              December 4, 2006
      
      
                           Multiple Signatures in S/MIME
                         draft-ietf-smime-multisig-00.txt
      
      Status of this Memo
      
         By submitting this Internet-Draft, each author represents that any
         applicable patent or other IPR claims of which he or she is aware
         have been or will be disclosed, and any of which he or she becomes
         aware will be disclosed, in accordance with Section 6 of BCP 79.
      
         Internet-Drafts are working documents of the Internet Engineering
         Task Force (IETF), its areas, and its working groups. Note that other
         groups may also distribute working documents as Internet-Drafts.
      
         Internet-Drafts are draft documents valid for a maximum of six months
         and may be updated, replaced, or obsoleted by other documents at any
         time. It is inappropriate to use Internet-Drafts as reference
         material or to cite them other than as "work in progress."
      
         The list of current Internet-Drafts can be accessed at
         http://www.ietf.org/ietf/1id-abstracts.html
      
         The list of Internet-Draft Shadow Directories can be accessed at
         http://www.ietf.org/shadow.html.
      
         This Internet-Draft will expire on June 4, 2007.
      
      
      Copyright Notice
      
         Copyright (C) The Internet Society (2006).
      
      Abstract
      
         CMS SignedData includes the SignerInfo structure to convey per-
         signer information. SignedData supports multiple signers and
         multiple signature algorithms per-signer with multiple SignerInfo
         structures. If a signer attaches more than one SignerInfo, there are
         concerns that an attacker could perform a downgrade attack by
         removing the SignerInfo(s) with the 'stronger' algorithm(s). This
         document defines a signed attribute, its generation rules, and its
         processing rules to allow signers to convey multiple SignerInfo
         while protecting against downgrade attacks. Additionally, this
         attribute may assist during periods of algorithm migration.
      
      
      
      Schaad, Turner                 Expires June 2007                    1
      
      
      Internet-Draft       Multiple Signatures in S/MIME      December 2006
      
      1 Introduction
      
         The Cryptographic Message Syntax (CMS), see [CMS], defined
         SignerInfo to provide data necessary for relying parties to verify
         the signer’s digital signature, which is also include in the
         SignerInfo structure. Signers include more than one SignerInfo in a
         SignedData if they use different digest or signature algorithms.
         Each SignerInfo exists independently and new SignerInfo structures
         can be added or an existing one(s) removed without perturbing the
         remaining signature(s).
      
         The concern is that if an attacker successfully attacked a hash or
         signature algorithm; the attacker could remove all SignerInfo
         structures except the SignerInfo with the successfully attacked hash
         or signature algorithm; the relying party is then left with the
         attacked SignerInfo even though the relying party supported more
         than just the attacked hash or signature algorithm.
      
         A solution is to have signers include a pointer to all the signer’s
         SignerInfo structures. If an attacker removes any SignerInfo, then
         relying parties will be aware that an attacker has removed one or
         more SignerInfo.
      
         Note this attribute ought not be confused with the countersignature
         attribute, see 11.4 of [CMS], as this is not intended to sign over
         an existing signature rather it is to provide a pointer to
         additional signer’s signatures that are all at the same level. That
         is countersignature provides a serial signature while the attribute
         defined herein provides pointers to parallel signature by the same
         signer.
      
      
      1.1 Requirements Terminology
      
         Though this document is not an Internet Draft, we use the convention
         that 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 [MUSTSHOULD].
      
      
      1.2 Discussion
      
         This draft is being discussed on the 'ietf-smime' mailing list. To
         subscribe, send a message to ietf-smime-request@imc.org with the
         single word subscribe in the body of the message. There is a Web
         site for the mailing list at <http://www.imc.org/ietf-smime/>.
      
      
      
      
      
      Schaad, Turner                 Expires June 2007                    2
      
      
      Internet-Draft       Multiple Signatures in S/MIME      December 2006
      
      2. Rationale
      
      2.1 Attacks
      
         The following types of resistance against known attacks, see
         [ATTACK], is needed:
      
           1) Collision Resistance: Find x and y where x != y and H(x) = H(y)
      
           2) Preimage Resistance: Given y, find x where H(x) = y
      
           3) Second Preimage Resistance: Given y, find x where H(x) = H(y)
      
         Note:  It is known that a collision resistance attack is simpler
         than a second preimage resistance attack, and it is presumed that a
         second preimage resistance attack is simplier than a preimage
         attack.
      
         Within a SignedInfo there are two places where hashes are applied
         and hence can be attacked: the Body and the SignedAttributes.  The
         following outlines the entity that creates the hash, the entity that
         attacks the hash, and the type of resistance required:
      
           1) Hash of the Body (i.e., the octets comprising the value of the
              encapContentInfo.eContent OCTET STRING omitting the tag and
              length octets - as per 5.4 of [CMS]).
      
              a) Alice creates the Body to be hashed:
      
                 i) Alice attacks the hash: This would require a successful
                 Collision Resistance attack.
      
                 ii) Mallory attacks the hash: This would require a
                 successful Second Preimage Reistance attack.
      
              b) Alice hashes a body provided by Bob:
      
                 i) Alice attacks the hash:  This would require a successful
                 Second Preimage Attack.
      
                 ii) Bob attacks the hash:  This would require a successful
                 Collision Resistance attack.  This can be upgraded to
                 requiring a successful Second Preimage Attack if Alice hash
                 the ability to "change" the content of the body in some
                 fashion.  (One example would be to use a keyed hash
                 function.)
      
                 iii) Mallory attacks the hash: This would require a
                 successful Second Preimage Attack.
      
      
      Schaad, Turner                 Expires June 2007                    3
      
      
      Internet-Draft       Multiple Signatures in S/MIME      December 2006
      
              c) Alice signs using a hash value provided by Bob.  (In this
                 case Alice is presumed to never see the body in question.)
      
                 i) Alice attacks hash: This would require a successful
                 Preimage Attack.
      
                 ii) Bob attacks hash: This would require a successful
                 Collision Resistance attack.  Unlike case (b), there is
                 nothing that Alice can do to upgrade the attack required.
      
                 iii) Mallory attacks the hash:  This would require a success
                 Preimage attack if the content is unavailable to Mallory and
                 a successful Second Preimage attack if the content is
                 available to Mallory.
      
           2) Hash of SignedAttributes (i.e., the complete DER encoding of
              the SignedAttrs value contained in the signedAttrs field - as
              per 5.4 of [CMS]).
      
              There is a difference between hashing the body and hashing the
              SignedAttrs value in that one SHOULD NOT accept a sequence of
              attributes to be signed from a third party.  In fact one SHOULD
              NOT accept attributes to be included in the signed attributes
              list from a third party.  The attributes are about the
              signature you are applying and not about the body.  If there is
              meta-information that needs to be attached to the body by a
              third party then they need to provide their own signature and
              you need to be doing a countersignature.  (Note: the fact that
              the signature is to be used as a countersignature is a piece of
              information that should be accepted, but it does not directly
              provide an attribute that is inserted in the attribute list.)
      
              a) Alice attacks the hash: This requires a successful Collision
              Resistance Attack.
      
              b) Mallory attacks the hash: This requires a successful Second
              Preimage Resistance attack.
      
              c) Bob attacks the hash and provides the body hash used:  This
              case is analogous to the current attacks [Attack].  Based on
              prediction of the signed attributes Alice will be using and the
              provided hash value and function.  (It is expected that if
              Alice uses a keyed hashing function as part of the signature
              this attack will be more difficult.)
      
              It should be noted that both of these attacks are considered to
              be more difficult that the attack on the body since more
              structure is designed into the data to be hashed than is
              frequently found in the body and the data is shorter in length
              than that of the body.
      
      Schaad, Turner                 Expires June 2007                    4
      
      
      Internet-Draft       Multiple Signatures in S/MIME      December 2006
      
      
              The successful prediction of the Signing-Time attribute is
              expected to more difficult than with certificates as the time
              would not generally be rounded.  Time stamp services can make
              this more unpredictable by using a random delay before issuing
              the signature.
      
              Allowing a third party to provide a hash value could
              potentially make attack © simpler when keyed hash functions are
              used since there is more data than can be modified without
              changing the overall structure of the Signed Attribute
              structure.
      
         A 3rd type of attack is a generic downgrade attack. The premise is
         to remove the 'better' signature to leave easier to attack
         signature.
      
      
      2.2 Attribute Design
      
         The attribute will have the following characteristics:
      
           1. Use CMS attribute structure;
           2. Be computable before any signatures are applied;
           3. Contain enough information to identify individual signatures
              (i.e., a particular SignerInfo); and,
           4. Contain enough information to resist collision, preimage, and
              second premiage attacks.
      
      
      3. Multiple Signature Indication
      
         The MultipleSignatures attribute type specifies a pointer to a
         signer’s other MultipleSignatures attribute(s). For example, if a
         signer applies three signatures there must be two attribute values
         for MultipleSignatures in each SignerInfo.  The 1st SignerInfo
         points to the 2nd and 3rd SignerInfos.  The 2nd SignerInfo points to
         the 1st and 3rd SignerInfos. The 3rd SignerInfo points to the 1st
         and 2nd SignerInfos.
      
         The MultipleSignatures attribute MUST be a signed attribute. The
         number of attributes included in a SignerInfo is the number of
         signatures applied by a signer less one. This attribute is multi-
         valued and there MAY be more than one AttributeValue present.
      
             The following object identifier identifies the
             MultipleSignatures attribute:
      
           id-aa-multipleSignatures OBJECT IDENTIFIER ::= { iso(1) member-
             body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) TBD }
      
      Schaad, Turner                 Expires June 2007                    5
      
      
      Internet-Draft       Multiple Signatures in S/MIME      December 2006
      
      
         multipleSignatures attribute values have the ASN.1 type
         MultipleSignature:
      
           MultipleSignature ::= SEQUENCE {
             bodyHashAlg     DigestAlgorithIdentifier,
             signAlg         SignatureAlgorithmIdentifier,
             signAttrsHash   SignAttrsHash,
             cert            ESSCertIDv2 OPTIONAL}
      
           SignAttrsHash ::= SEQUENCE {
             algID            AlgorithmIdentifier,
             hash             OCTET STRING }
      
         bodyHashAlg includes the digest algorithmIdentifier for the
         referenced MultipleSignatures attribute.
      
         signAlg includes the signature algorithmIdentifier for the refrenced
         MultipleSignatures attribute.
      
         signAttrsHash has two fields:
      
           - aldId MUST match the digest algorithm for the SignerInfo in
              which this MultipleSignatures attribute value is placed.
      
           - hash is the hash value of the signedAttrs (see section 4.3).
      
         cert is optional. It identities the certificate used to sign the
         SignerInfo that contains the other MultipleSignatures attribute(s).
      
         The following is an example:
      
         SignedData
           DigestAlg=sha1,sha256
           SignerInfo1                    SignerInfo2
             digestAlg=sha1                 digestAlg=sha256
             signatureAlg=dsawithsha1       signatureAlg=ecdsawithsha256
             signedAttrs=                   signedAttrs=
               signingTime1                   signingTime1
               messageDigest1                 messageDigest2
               multiSig1=                     multiSig2=
                 bodyHash=sha256                bodyHash=sha1
                 signAlg=ecdsawithsha256        signAlg=dsawithsha1
                   signAttrsHash=               signAttrsHash=
                   algID=sha1                     algID=sha256
                   hash=value1                    hash=value2
      
      
      
      
      
      Schaad, Turner                 Expires June 2007                    6
      
      
      Internet-Draft       Multiple Signatures in S/MIME      December 2006
      
      4. Message Generation and Processing
      
         The following are the additional procedures for Message Generation
         when using the MultipleSignatures attribute. These paragraphs track
         with section 5.1-5.6 in [CMS].
      
      
      4.1 SignedData Type
      
         The following steps MUST be followed by a signer when generating
         SignedData:
      
           - The signer MUST indicate the CMS version.
      
           - The signer SHOULD include the digest algorithm used in
            SignedData.digestAlgorithms, if the digest algorithm’s identifier
            is not already present.
      
           - The signer MUST include the encapContentInfo. Note the
            encapContentInfo is the same for all signers in this SignedData.
      
           - The signer SHOULD add certificates sufficient to contain
            certificate paths from a recognized “root” or “top-level
            certification authority” to the signer, if the signer’s
            certificates are not already present.
      
           - The signer MAY include the Certificate Revocation Lists (CRLs)
            necessary to validate the digital signature, if the CRLs are not
            already present.
      
           - The signer MUST:
      
             - Retain the existing signerInfo(s).
      
             - Include their signerInfo.
      
      
      4.2 EncapsulatedContentInfo Type
      
         The procedures for generating EncapsulatedContentInfo are as
         specified in section 5.2 of [CMS].
      
      
      4.3 SignerInfo Type
      
         The procedures for generating a SignerInfo are as specified in
         section 5.3 of [CMS] with the following addition:
      
         The signer MUST include the MultipleSignatures attribute in
         signedAttrs.
      
      Schaad, Turner                 Expires June 2007                    7
      
      
      Internet-Draft       Multiple Signatures in S/MIME      December 2006
      
      
      
      
      4.4 Message Digest Calculation Process
      
      4.4.1 MultipleSignatures Signed Attribute Generation
      
         The procedure for generating the MultipleSignatures signed attribute
         are as follows:
      
         1.  All other signed attributes are placed in the respective
         SignerInfo structures but the signatures are not yet computed for
         the SignerInfo.
      
         2.  The MultipleSignature attributes are added to each of the
         SignerInfo structures with the SignAttrsHash.hash field containing a
         zero length octet string.
      
         3.  The correct SignAttrsHash.hash value is computed for each of the
         SignerInfo structures.
      
         4.  After all hash values have been computed, the correct hash
         values are placed into their respective SignAttrsHash.hash fields.
      
      4.4.2 Message Digest calculation Process
      
         The remaining procedures for generating the message-digest attribute
         are as specified in section 5.4 of [CMS].
      
      
      
      4.5 Signature Generation Process
      
         The procedures for signature generation are as specified in
         section 5.5 of [CMS].
      
      
      4.6 Signature Verification Process
      
         The procedures for signature verification are as specified in
         section 5.6 of [CMS] with the following addition:
      
         If the SignedData signerInfo includes the MultipleSignatures
         attribute, the attribute’s values must be calculated as described in
         section 4.4.1.
      
         For every SignerInfo to be considered present for a given signer,
         the number of MultipleSignatures AttributeValue(s) present in a
         given SignerInfo MUST equal the number of SignerInfos for that
         signer less one and the hash value present in each of the
      
      Schaad, Turner                 Expires June 2007                    8
      
      
      Internet-Draft       Multiple Signatures in S/MIME      December 2006
      
         MultipleSignatures AttributeValue(s) MUST match the output of the
         message digest calculation from section 4.4.1 for each SignerInfo.
      
         .  The hash corresponding to the 1st SignerInfo must match the value
         in the MultipleSignature attribute that points to the 1st SignerInfo
         present in the 2nd and 3rd SignerInfos.  The hash corresponding to
         the 2nd SignerInfo must match the value in the MultipleSignature
         attribute that points to the 2nd SignerInfo present in the 1st and
         3rd SignerInfos. The hash corresponding to the 3rd SignerInfo must
         match the value in the MultipleSignature attribute that points to
         the 3rd SignerInfo present in the 1st and 2nd SignerInfos.
      
      
      5.0 Signature Evaluation Processing
      
         This section describes recommended processing of signatures when
         there are more than one SignerInfo present in a message.  This may
         be due to either multiple SignerInfos being present in a singled
         SignedData object, or there are multiple SignerData objects embedded
         in each other.
      
         The text in this section is non-normative.  The processing described
         is highly recommended, but is not forced.  Changes in the processing
         which have the same results with somewhat different orders of
         processing is sufficient.
      
         Order of operations:
      
         1.  Evaluate each SignerInfo object independently.
         2.  Combine the results of all SignerInfo objects at the same level
             (i.e. attached to the same SignerData object)
         3.  Combine the results of the nested SignerData objects.  Note that
             this should ignore the presence of other CMS objects between the
             SignedData objects.
      
      
      5.1 Evaluation of a SignerInfo object
      
         When evaluating a SignerInfo object, there are three different
         pieces that need to be examined.  The first is the mathematics of
         the signature itself (i.e., can one actually successfully do the
         computations and get the correct answer).  This piece ends up with a
         binary answer, either it succeeds or it fails there is no middle
         ground.   Not necessaryily true, what about an unevaluatable
         algorithm - this is nether success nor failure. From the verifiers
         perspective the answer is still fail since they can’t actuall do the
         math - so I think it’s still binary.
      
         The second is the validation of the source of the public key.  For
         CMS, this is generally determined by extracting the public key from
      
      Schaad, Turner                 Expires June 2007                    9
      
      
      Internet-Draft       Multiple Signatures in S/MIME      December 2006
      
         a certificate.  The certificate needs to be evaluated.  This is done
         by the procedures outlined in [PKIX-CERT].  In addition to the
         processing described in that document, there may be additional
         requirements on certification path processing that are required by
         the application in question.  One such set of addition processing is
         described in [SMIME-CERT].  One piece of information that is part of
         this additional processing is local and application policy.  The
         output of this processing can actually be one of four different
         states:  Success, Failure, Indeterminate and Warning.  The first
         three states are described in [PKIX-CERT], Warning would be
         generated when it is possible that some information is currently
         acceptable, but may not be acceptable either in the near future or
         under some circumstances.
      
         The third part of the validation is local and application policy as
         applied to the contents of the SignerInfo object.  This would cover
         such issues as the requirements on mandatory signed attributes or
         requirements on signature algorithms.
      
         -- state if you cannot do the math?
      
      5.2 Evaluation of a SignerInfo Set
      
         Combining the results of the individual SignerInfos into a result
         for a SignedData object requires knowledge of the results for the
         individual SignerInfo objects, the require application policy and
         any local policies.  The default processing if no other rules are
         applied should be:
      
         1. Segregate SignerInfo objects according to who signed.
         2. Take the best result from the items in the grouping; this is the
            result for the grouping.
         3. Take the worst result from all of the groups; this is the result
            for the SignedData object.
      
         Application and local policy can affect each of the steps outlined
         above.
      
         In Step 1:
         - If the subject name or subject alternative name(s) cannot be used
           to determine if two SignerInfo objects were created by the same
           identity, then applications need to specify how such matching is
           to be done.  As an example, the S/MIME message specification could
           say that as long as the same RFC 822 name exists in either the
           subject name or the subject alt name they are the same identity.
           This would be true even if other information that did not match
           existed in these fields.
         - Some applications may specify that this step should be skipped;
           this has the effect of making each SignerInfo object independent
           of all other SignerInfo objects even if the signing identity is
      
      Schaad, Turner                 Expires June 2007                   10
      
      
      Internet-Draft       Multiple Signatures in S/MIME      December 2006
      
           the same.  Applications that specify this need to be aware that
           algorithm rollover will not work correctly in this case.
      
         In Step 2:
         - The major policy implication at this step is the treatment of and
           order for the indeterminate states.  In most cases this state
           would be placed between the failure and warning states.  Part of
           the issue is the question of having a multi-state or a binary
           answer as to success or failure of an evaluation.  Not every
           application can deal with the statement "try again later".  It may
           also be dependent on what the reason for the indeterminate state
           is.  It makes more sense to try again later if the problem is that
           a CRL cannot be found than if you are not able to evaluate the
           algorithm for the signature.
      
         In Step 3:
         - Very application dependent processing other options are:
              o strip bad sig from the outside in - signed  mail.
              o strip bad sigs from the inside out - work flow.
         - Modifications of the algorithm due to the presence of other types
           of layers.  I.e. EncryptedData/EnvelopedData or AuthenticatedData.
      
      
         Implications/differences for AuthenticatedData.
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      Schaad, Turner                 Expires June 2007                   11
      
      
      Internet-Draft       Multiple Signatures in S/MIME      December 2006
      
      6. Security Considerations
      
         If another entity is providing hash to be signed, then ensure it is
         a “trustworthy” source.
      
         //** Needs more work
      
      7 References
      
      
      7.1 Normative References
      
         [CMS]      Housley, R., "Cryptographic Message Syntax (CMS)", RFC
                    3852, July 2004.
      
         [PROFILE]  Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
                    X.509 Public Key Infrastructure Certificate and
                    Certificate Revocation List (CRL) Profile", RFC 3280,
                    April 2002.
      
         [ESSCertID] Schaad, J., "ESS Update: Adding CertID Algorithm
                    Agility", draft-ietf-smime-esscertid-01.txt, April 2006.
      
      
      7.2 Non-Normative References
      
         [Attack]   Hoffman, P., Schneier, B., “Attacks on Cryptographic
                    Hashes in Internet Protocols”, RFC 4270, November 2005.
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      Schaad, Turner                 Expires June 2007                   12
      
      
      Internet-Draft       Multiple Signatures in S/MIME      December 2006
      
      Appendix A. ASN.1 Module
      
         MultipleSignatures
           { iso(1) member-body(2) us(840) rsadsi(113549)
             pkcs(1) pkcs-9(9) smime(16) modules(0) multisig(TBD) }
      
            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.
      
         IMPORTS
      
         -- Imports from RFC 3280 [PROFILE], Appendix A.1
              AlgorithmIdentifier
                FROM PKIX1Explicit88
                  { iso(1) identified-organization(3) dod(6)
                    internet(1) security(5) mechanisms(5) pkix(7)
                    mod(0) pkix1-explicit(18) }
      
         -- Imports from RFC 3852 [CMS], 12.1
              DigestAlgorithmIdentifier, SignatureAlgorithmIdentifier
              FROM CryptographicMessageSyntax2004
                { iso(1) member-body(2) us(840) rsadsi(113549)
                  pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2004(24) }
      
         -- Imports from RFC XXX [ESSCertID], Appendix A
              ESSCertIDv2
              FROM ExtendedSecurityServices-2006
                { iso(1) member-body(2) us(840) rsadsi(113549)
                  pkcs(1) pkcs-9(9) smime(16) modules(0) ess-2006(TBD) }
      
         ;
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      Schaad, Turner                 Expires June 2007                   13
      
      
      Internet-Draft       Multiple Signatures in S/MIME      December 2006
      
         -- Section 3.0
      
         id-multipleSignatures OBJECT IDENTIFIER ::= { iso(1) member-body(2)
         us(840) rsadsi(113549) pkcs(1) pkcs9(9) TBD }
      
         MultipleSignature ::= SEQUENCE {
           bodyHashAlg     DigestAlgorithIdentifier,
           signAlg         SignatureAlgorithmIdentifier,
           signAttrsHash   SignAttrsHash,
           cert            ESSCertIDv2 OPTIONAL }
      
         SignAttrsHash ::= SEQUENCE {
           algID            AlgorithmIdentifier,
           hash             OCTET STRING }
      
      
         END – of MultipleSignatures
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      Schaad, Turner                 Expires June 2007                   14
      
      
      Internet-Draft       Multiple Signatures in S/MIME      December 2006
      
      Editor’s Address
      
         Sean Turner
         IECA, Inc.
      
         Email: turners (at) ieca.com
      
         Jim Schaad
         Soaring Hawk Consulting
      
         Email: jimsch (at) exmsft.com
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      Schaad, Turner                 Expires June 2007                   15
      
      
      Internet-Draft       Multiple Signatures in S/MIME      December 2006
      
      Intellectual Property Statement
      
         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.
      
      
      Disclaimer of Validity
      
         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.
      
      
      Copyright Statement
      
         Copyright (C) The Internet Society (2006).
      
         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.
      
      
      Acknowledgment
      
         Funding for the RFC Editor function is currently provided by the
         Internet Society.
      
      
      Schaad, Turner                 Expires June 2007                   16
      

Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/