Tech-invite  3GPPspecsRELsGlossariesSIPRFCs
8887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100

in Index   Prev   Next

RFC 5055

Server-Based Certificate Validation Protocol (SCVP)

Pages: 88
Proposed Standard
Part 4 of 4 – Pages 57 to 88
First   Prev   None

Top   ToC   RFC5055 - Page 57   prevText

4.10. respNonce

The respNonce item contains an identifier to bind the request to the response. If the client includes a requestNonce value in the request and the server is generating a specific non-cached response to the request then the server MUST return the same value in the response. If the server is using a cached response to the request then it MUST omit the respNonce item. If the server is returning a specific non-cached response to a request without a nonce, then the server MAY include a message- specific nonce. For digitally signed messages, the server MAY use the value of the message-digest attribute in the signedAttrs within SignerInfo of the request as the value in the respNonce item. The requestNonce item uses the OCTET STRING type. Conforming client implementations MUST be able to process a response that includes this item. Conforming servers MUST support respNonce.

4.11. serverContextInfo

The serverContextInfo item in a response is a mechanism for the server to pass some opaque context information to the client. If the client does not like the certification path returned, it can make a new query and pass along this context information. Section 3.2.6 contains information about the client's usage of this item. The context information is opaque to the client, but it provides information to the server that ensures that a different certification path will be returned (if another one can be found). The context information could indicate the state of the server, or it could contain a sequence of hashes of certification paths that have already been returned to the client. The protocol does not dictate any structure or requirements for this item. However, implementers should review the Security Considerations section of this document before selecting a structure.
Top   ToC   RFC5055 - Page 58
   Servers that are incapable of returning additional paths MUST NOT
   include the serverContextInfo item in the response.

4.12. cvResponseExtensions

If present, the cvResponseExtensions item contains a sequence of extensions that extend the response. This specification does not define any extensions. The facility is provided to allow future specifications to extend SCVP. The syntax for Extensions is imported from [PKIX-1]. The cvResponseExtensions item, when present, contains a sequence of Extension items, each of which contains an extnID item, a critical item, and an extnValue item. The extnID item is an identifier for the extension. It contains the object identifier (OID) that names the extension. The critical item is a BOOLEAN. Each extension is designated as either critical (with a value of TRUE) or non-critical (with a value of FALSE). An SCVP client MUST reject the response if it encounters a critical extension it does not recognize; however, a non-critical extension MAY be ignored if it is not recognized. The extnValue item contains an OCTET STRING. Within the OCTET STRING is the extension value. An ASN.1 type is specified for each extension, identified by the associated extnID object identifier.

4.13. requestorText

The requestorText item contains a text field supplied by the client. If the client includes a requestorText value in the request and the server is generating a specific non-cached response to the request, then the server MUST return the same value in the response. If the server is using a cached response to the request, then it MUST omit the requestorText item. The requestNonce item uses the UTF8 string type. Conforming client implementations that support the requestorText item in requests (see Section 3.10) MUST be able to process a response that includes this item. Conforming servers MUST support requestorText in responses.
Top   ToC   RFC5055 - Page 59

4.14. SCVP Response Validation

There are two mechanisms for validation of SCVP responses, one based on the client's knowledge of a specific SCVP server key and the other based on validation of the certificate corresponding to the private key used to protect the SCVP response.

4.14.1. Simple Key Validation

The simple key validation method is where the SCVP client has a local policy of one or more SCVP server keys that directly identify the set of valid SCVP servers. Mechanisms for storage of server keys or identifiers are a local matter. For example, a client could store cryptographic hashes of public keys used to verify SignedData responses. Alternatively, a client could store shared symmetric keys used to verify MACs in AuthenticatedData responses. Simple key validation MUST be used by SCVP clients that cannot validate PKIX-1 certificates and are therefore making delegated path validation requests to the SCVP server [RQMTS]. It is a matter of local policy with these clients whether to use SignedData or AuthenticatedData. Simple key validation MAY be used by other SCVP clients for other reasons.

4.14.2. SCVP Server Certificate Validation

It is a matter of local policy what validation policy the client uses when validating responses. When validating protected SCVP responses, SCVP clients SHOULD use the validation algorithm defined in Section 6 of [PKIX-1]. SCVP clients may impose additional limitations on the algorithm, such as limiting the number of certificates in the path or establishing initial name constraints, as specified in Section 6.2 of [PKIX-1]. If the certificate used to sign the validation policy responses and SignedData validation responses contains the key usage extension ([PKIX-1], Section 4.2.1.3), it MUST have either the digital signature bit set, the non-repudiation bit set, or both bits set. If the certificate for AuthenticatedData validation responses contains the key usage extension, it MUST have the key agreement bit set.
Top   ToC   RFC5055 - Page 60
   If the certificate used on a validation policy response or a
   validation response contains the extended key usage extension
   ([PKIX-1], Section 4.2.1.13), it MUST contain either the
   anyExtendedKeyUsage OID or the following OID:

      id-kp-scvpServer             OBJECT IDENTIFIER ::= { id-kp 15 }

5. Server Policy Request

An SCVP client uses the ValPolRequest item to request information about an SCVP server's policies and configuration information, including the list of validation policies supported by the SCVP server. When a ValPolRequest is encapsulated in a MIME body part, it MUST be carried in an application/scvp-vp-request MIME body part. The request consists of a ValPolRequest encapsulated in a ContentInfo. The client does not sign the request. ContentInfo { contentType id-ct-scvp-valPolRequest, -- (1.2.840.113549.1.9.16.1.12) content ValPolRequest } The ValPolRequest type has the following syntax: ValPolRequest ::= SEQUENCE { vpRequestVersion INTEGER DEFAULT 1, requestNonce OCTET STRING } Conforming SCVP server implementations MUST recognize and process the server policy request. Conforming clients SHOULD support the server policy request.

5.1. vpRequestVersion

The syntax and semantics of vpRequestVersion are the same as cvRequestVersion as described in Section 3.1.

5.2. requestNonce

The requestNonce item contains a request identifier generated by the SCVP client. If the server returns a specific response, it MUST include the requestNonce from the request in the response, but the server MAY return a cached response, which MUST NOT include a requestNonce.
Top   ToC   RFC5055 - Page 61

6. Validation Policy Response

In response to a ValPolRequest, the SCVP server provides a ValPolResponse. The ValPolResponse may not be unique to any ValPolRequest, so may be reused by the server in response to multiple ValPolRequests. The ValPolResponse also has an indication of how frequently the ValPolResponse may be reissued. The server MUST sign the response using its digital signature certificate. When a ValPolResponse is encapsulated in a MIME body part, it MUST be carried in an application/scvp-vp-response MIME body part. The response consists of a ValPolResponse encapsulated in a SignedData, which is in turn encapsulated in a ContentInfo. That is, the EncapsulatedContentInfo field of SignedData consists of an eContentType field with a value of id-ct-scvp-valPolResponse (1.2.840.113549.1.9.16.1.13) and an eContent field that contains a DER-encoded ValPolResponse. The SCVP server MUST include its own certificate in the certificates field within SignedData, and the signerInfos field of SignedData MUST include exactly one SignerInfo. The SignedData MUST NOT include the unsignedAttrs field. The ValPolResponse type has the following syntax: ValPolResponse ::= SEQUENCE { vpResponseVersion INTEGER, maxCVRequestVersion INTEGER, maxVPRequestVersion INTEGER, serverConfigurationID INTEGER, thisUpdate GeneralizedTime, nextUpdate GeneralizedTime OPTIONAL, supportedChecks CertChecks, supportedWantBacks WantBack, validationPolicies SEQUENCE OF OBJECT IDENTIFIER, validationAlgs SEQUENCE OF OBJECT IDENTIFIER, authPolicies SEQUENCE OF AuthPolicy, responseTypes ResponseTypes, defaultPolicyValues RespValidationPolicy, revocationInfoTypes RevocationInfoTypes, signatureGeneration SEQUENCE OF AlgorithmIdentifier, signatureVerification SEQUENCE OF AlgorithmIdentifier, hashAlgorithms SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER, serverPublicKeys SEQUENCE OF KeyAgreePublicKey OPTIONAL, clockSkew INTEGER DEFAULT 10, requestNonce OCTET STRING OPTIONAL }
Top   ToC   RFC5055 - Page 62
      ResponseTypes  ::= ENUMERATED {
        cached-only                (0),
        non-cached-only            (1),
        cached-and-non-cached      (2) }

      RevocationInfoTypes ::= BIT STRING {
        fullCRLs                   (0),
        deltaCRLs                  (1),
        indirectCRLs               (2),
        oCSPResponses              (3) }

   SCVP clients that support validation policy requests MUST support
   validation policy responses.  SCVP servers MUST support validation
   policy responses.

   SCVP servers MUST support cached policy responses and MAY support
   specific responses to policy requests.

6.1. vpResponseVersion

The syntax and semantics of the vpResponseVersion item are the same as cvRequestVersion as described in Section 3.1. The vpResponseVersion used MUST be the same as the vpRequestVersion unless the client has used a value greater than the values the server supports. If the client submits a vpRequestVersion greater than the version supported by the server, the server MUST return a vpResponseVersion using the highest version number the server supports as the version number.

6.2. maxCVRequestVersion

The maxCVRequestVersion item defines the maximum version number for CV requests that the server supports.

6.3. maxVPRequestVersion

The maxVPRequestVersion item defines the maximum version number for VP requests that the server supports.

6.4. serverConfigurationID

The serverConfigurationID item is an integer that uniquely represents the version of the server configuration as represented by the validationPolicies, validationAlgs, authPolicies, defaultPolicyValues, and clockSkew. If any of these values change, the server MUST create a new ValPolResponse with a new serverConfigurationID. If the configuration has not changed, then the server may reuse serverConfigurationID across multiple
Top   ToC   RFC5055 - Page 63
   ValPolResponse messages.  However, if the server reverts to an
   earlier configuration, the server MUST NOT revert the configuration
   ID as well, but MUST select another unique value.

6.5. thisUpdate

This item indicates the signing date and time of this policy response. GeneralizedTime values MUST be expressed in Greenwich Mean Time (Zulu) and interpreted as defined in Section 3.2.7.

6.6. nextUpdate and requestNonce

These items are used to indicate whether policy responses are specific to policy requests. Where policy responses are cached, these items indicate when the information will be updated. The optional nextUpdate item indicates the time by which the next policy response will be published. The optional requestNonce item links the response to a specific request by returning the nonce provided in the request. If the nextUpdate item is omitted, it indicates a non-cached response generated in response to a specific request (i.e., the ValPolResponse is bound to a specific request). If this item is omitted, the requestNonce item MUST be present and MUST include the requestNonce value from the request. If the nextUpdate item is present, it indicates a cached response that is not bound to a specific request. An SCVP server MUST periodically generate a new response as defined by the next update time, but MAY use the same ValPolResponse to respond to multiple requests. The requestNonce is omitted if the nextUpdate item is present. It is a matter of local server policy to return a cached or non- cached specific response. GeneralizedTime values in nextUpdate MUST be expressed in Greenwich Mean Time (Zulu) as specified in Section 3.2.7.

6.7. supportedChecks

The supportedChecks item contains a sequence of object identifiers representing the checks supported by the server.
Top   ToC   RFC5055 - Page 64

6.8. supportedWantBacks

The supportedWantBacks item contains a sequence of object identifiers representing the wantBacks supported by the server.

6.9. validationPolicies

The validationPolicies item contains a sequence of object identifiers representing the validation policies supported by the server. It is a matter of local policy if the server wishes to process requests using the default validation policy, and if it does not, then it MUST NOT include the id-svp-defaultValPolicy in this list.

6.10. validationAlgs

The validationAlgs item contains a sequence of OIDs. Each OID identifies a validation algorithm supported by the server.

6.11. authPolicies

The authPolicies item contains a sequence of policy references for authenticating to the SCVP server. The reference to the authentication policy is an OID that the client and server have agreed represents an authentication policy. The list of policies is intended to document to the client if authentication is required for some requests and if so how. AuthPolicy ::= OBJECT IDENTIFIER

6.12. responseTypes

The responseTypes item allows the server to publish the range of response types it supports. Cached only means the server will only return cached responses to requests. Non-cached only means the server will return a specific response to the request, i.e., containing the requestor's nonce. Both means that the server supports both cached and non-cached response types and will return either a cached or non- cached response, depending on the request.

6.13. revocationInfoTypes

The revocationInfoTypes item allows the server to indicate the sources of revocation information that it is capable of processing. For each bit in the RevocationInfoTypes BIT STRING, the server MUST set the bit to one if it is capable of processing the corresponding revocation information type and to zero if it cannot.
Top   ToC   RFC5055 - Page 65

6.14. defaultPolicyValues

This is the default validation policy used by the server. It contains a RespValidationPolicy, which is defined in Section 4.5. All OPTIONAL items in the validationPolicy item MUST be populated. A server will use these default values when the request references the default validation policy and the client does not override the default values by supplying other values in the request. This allows the client to optimize the request by omitting parameters that match the server default values.

6.15. signatureGeneration

This sequence specifies the set of digital signature algorithms supported by an SCVP server for signing CVResponse messages. Each digital signature algorithm is specified as an AlgorithmIdentifier, using the encoding rules associated with the signatureAlgorithm field in a public key certificate [PKIX-1]. Supported algorithms are defined in [PKIX-ALG] and [PKIX-ALG2], but other signature algorithms may also be supported. By including an algorithm (e.g., RSA with SHA-1) in this list, the server states that it has a private key and corresponding certified public key for that asymmetric algorithm, and supports the specified hash algorithm. The list is ordered; the first digital signature algorithm is the server's default algorithm. The default algorithm will be used by the server to protect signed messages unless the client specifies another algorithm. For servers that do not have an on-line private key, and cannot sign CVResponse messages, the signatureGeneration item is encoded as an empty sequence.

6.16. signatureVerification

This sequence specifies the set of digital signature algorithms that can be verified by this SCVP server. Each digital signature algorithm is specified as an AlgorithmIdentifier, using the encoding rules associated with the signatureAlgorithm field in a public key certificate [PKIX-1]. Supported algorithms are defined in [PKIX-ALG] and [PKIX-ALG2], but other signature algorithms may also be supported. For servers that do not verify signatures on CVRequest messages, the signatureVerification item is encoded as an empty sequence.
Top   ToC   RFC5055 - Page 66

6.17. hashAlgorithms

This sequence specifies the set of hash algorithms that the server can use to hash certificates and requests. The list is ordered; the first hash algorithm is the server's default algorithm. The default algorithm will be used by the server to compute hashes included in responses unless the client specifies another algorithm. Each hash algorithm is specified as an object identifier. [PKIX-ALG2] specifies object identifiers for SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512. Other hash algorithms may also be supported.

6.18. serverPublicKeys

The serverPublicKeys item is a sequence of one or more key agreement public keys and associated parameters. It is used by clients making AuthenticatedData requests to the server. Each item in the serverPublicKeys sequence is of the KeyAgreePublicKey type: KeyAgreePublicKey ::= SEQUENCE { algorithm AlgorithmIdentifier, publicKey BIT STRING, macAlgorithm AlgorithmIdentifier, kDF AlgorithmIdentifier OPTIONAL } The KeyAgreePublicKey includes the algorithm identifier and the server's public key. SCVP servers that support the key agreement mode of AuthenticatedData for SCVP requests MUST support serverPublicKeys and the Diffie-Hellman key agreement algorithm as specified in [PKIX-ALG]. SCVP servers that support serverPublicKeys MUST support the 1024-bit Modular Exponential (MODP) group key (group 2) as defined in [IKE]. SCVP servers that support serverPublicKeys MAY support other Diffie-Hellman groups [IKE-GROUPS], as well as other key agreement algorithms. The macAlgorithm item specifies the symmetric algorithm the server expects the client to use with the result of the key agreement algorithm. A key derivation function (KDF), which derives symmetric key material from the key agreement result, may be implied by the macAlgorithm. Alternatively, the KDF may be explicitly specified using the optional kDF item.

6.19. clockSkew

The clockSkew item is the number of minutes the server will allow for clock skew. The default value is 10 minutes.
Top   ToC   RFC5055 - Page 67

7. SCVP Server Relay

In some network environments, especially ones that include firewalls, an SCVP server might not be able to obtain all of the information that it needs to process a request. However, the server might be configured to use the services of one or more other SCVP servers to fulfill all requests. In such cases, the SCVP client is unaware that the initial SCVP server is using the services of other SCVP servers. The initial SCVP server acts as a client to another SCVP server. Unlike the original client, the SCVP server is expected to have moderate computing and memory resources. This section describes SCVP server-to-SCVP server exchanges. This section does not impose any requirements on SCVP clients that are not also SCVP servers. Further, this section does not impose any requirements on SCVP servers that do not relay requests to other SCVP servers. When one SCVP server relays a request to another server, in an incorrectly configured system of servers, it is possible that the same request will be relayed back again. Any SCVP server that relays requests MUST implement the conventions described in this section to detect and break loops. When an SCVP server relays a request, the request MUST include the requestorRef item. If the request to be relayed already contains a requestorRef item, then the server-generated request MUST contain a requestorRef item constructed from this value and an additional GeneralName that contains an identifier of the SCVP server. If the request to be relayed does not contain a requestorRef item, then the server-generated request MUST contain a requestorRef item that includes a GeneralName that contains an identifier of the SCVP server. To prevent false loop detection, servers should use identifiers that are unique within their network of cooperating SCVP servers. SCVP servers that support relay SHOULD populate this item with the DNS name of the server or the distinguished name in the server's certificate. SCVP servers MAY choose other procedures for generating identifiers that are unique within their community. When an SCVP server receives a request that contains a requestorRef item, the server MUST check the sequence of names in the requestorRef item for its own identifier. If the server discovers its own identifier in the requestorRef item, it MUST respond with an error, setting the statusCode in the responseStatus item to 40. When an SCVP server generates a non-cached response to a relayed request, the server MUST include the requestorRef item from the request in the response.
Top   ToC   RFC5055 - Page 68

8. SCVP ASN.1 Module

This section defines the syntax for SCVP request-response pairs. The semantics for the messages are defined in Sections 3, 4, 5, and 6. The SCVP ASN.1 module follows. SCVP { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 21 } DEFINITIONS IMPLICIT TAGS ::= BEGIN IMPORTS AlgorithmIdentifier, Attribute, Certificate, Extensions, -- Import UTF8String if required by compiler -- UTF8String, -- CertificateList, CertificateSerialNumber FROM PKIX1Explicit88 -- RFC 3280 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 18 } GeneralNames, GeneralName, KeyUsage, KeyPurposeId FROM PKIX1Implicit88 -- RFC 3280 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 19 } AttributeCertificate FROM PKIXAttributeCertificate -- RFC 3281 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 12 } OCSPResponse FROM OCSP -- RFC 2560 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 14 } ContentInfo FROM CryptographicMessageSyntax2004 -- RFC 3852 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2004(24) } ; -- SCVP Certificate Validation Request id-ct OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) id-smime(16) 1 }
Top   ToC   RFC5055 - Page 69
   id-ct-scvp-certValRequest OBJECT IDENTIFIER ::= { id-ct 10 }

   CVRequest ::= SEQUENCE {
     cvRequestVersion           INTEGER DEFAULT 1,
     query                      Query,
     requestorRef           [0] GeneralNames OPTIONAL,
     requestNonce           [1] OCTET STRING OPTIONAL,
     requestorName          [2] GeneralName OPTIONAL,
     responderName          [3] GeneralName OPTIONAL,
     requestExtensions      [4] Extensions OPTIONAL,
     signatureAlg           [5] AlgorithmIdentifier OPTIONAL,
     hashAlg                [6] OBJECT IDENTIFIER OPTIONAL,
     requestorText          [7] UTF8String (SIZE (1..256)) OPTIONAL }

   Query ::= SEQUENCE {
     queriedCerts             CertReferences,
     checks                   CertChecks,
     wantBack             [1] WantBack OPTIONAL,
     validationPolicy         ValidationPolicy,
     responseFlags            ResponseFlags OPTIONAL,
     serverContextInfo    [2] OCTET STRING OPTIONAL,
     validationTime       [3] GeneralizedTime OPTIONAL,
     intermediateCerts    [4] CertBundle OPTIONAL,
     revInfos             [5] RevocationInfos OPTIONAL,
     producedAt           [6] GeneralizedTime OPTIONAL,
     queryExtensions      [7] Extensions OPTIONAL }

   CertReferences ::= CHOICE {
     pkcRefs       [0] SEQUENCE SIZE (1..MAX) OF PKCReference,
     acRefs        [1] SEQUENCE SIZE (1..MAX) OF ACReference }

   CertReference::= CHOICE {
     pkc               PKCReference,
     ac                ACReference }

   PKCReference ::= CHOICE {
     cert          [0] Certificate,
     pkcRef        [1] SCVPCertID }

   ACReference ::= CHOICE {
     attrCert      [2] AttributeCertificate,
     acRef         [3] SCVPCertID }

   SCVPCertID ::= SEQUENCE {
       certHash        OCTET STRING,
       issuerSerial    SCVPIssuerSerial,
       hashAlgorithm   AlgorithmIdentifier DEFAULT { algorithm sha-1 } }
Top   ToC   RFC5055 - Page 70
   SCVPIssuerSerial ::= SEQUENCE {
        issuer         GeneralNames,
        serialNumber   CertificateSerialNumber
   }

   ValidationPolicy ::= SEQUENCE {
     validationPolRef           ValidationPolRef,
     validationAlg          [0] ValidationAlg OPTIONAL,
     userPolicySet          [1] SEQUENCE SIZE (1..MAX) OF OBJECT
                                  IDENTIFIER OPTIONAL,
     inhibitPolicyMapping   [2] BOOLEAN OPTIONAL,
     requireExplicitPolicy  [3] BOOLEAN OPTIONAL,
     inhibitAnyPolicy       [4] BOOLEAN OPTIONAL,
     trustAnchors           [5] TrustAnchors OPTIONAL,
     keyUsages              [6] SEQUENCE OF KeyUsage OPTIONAL,
     extendedKeyUsages      [7] SEQUENCE OF KeyPurposeId OPTIONAL,
     specifiedKeyUsages     [8] SEQUENCE OF KeyPurposeId OPTIONAL }


   CertChecks ::= SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER

   WantBack ::= SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER

   ValidationPolRef ::= SEQUENCE {
       valPolId             OBJECT IDENTIFIER,
       valPolParams         ANY DEFINED BY valPolId OPTIONAL }

   ValidationAlg ::= SEQUENCE {
     valAlgId               OBJECT IDENTIFIER,
     parameters             ANY DEFINED BY valAlgId OPTIONAL }

   NameValidationAlgParms ::= SEQUENCE {
     nameCompAlgId          OBJECT IDENTIFIER,
     validationNames        GeneralNames }

   TrustAnchors ::= SEQUENCE SIZE (1..MAX) OF PKCReference

   KeyAgreePublicKey ::= SEQUENCE {
     algorithm           AlgorithmIdentifier,
     publicKey           BIT STRING,
     macAlgorithm        AlgorithmIdentifier,
     kDF                 AlgorithmIdentifier OPTIONAL }

   ResponseFlags ::= SEQUENCE {
     fullRequestInResponse      [0] BOOLEAN DEFAULT FALSE,
     responseValidationPolByRef [1] BOOLEAN DEFAULT TRUE,
     protectResponse            [2] BOOLEAN DEFAULT TRUE,
     cachedResponse             [3] BOOLEAN DEFAULT TRUE }
Top   ToC   RFC5055 - Page 71
   CertBundle ::= SEQUENCE SIZE (1..MAX) OF Certificate

   RevocationInfos ::= SEQUENCE SIZE (1..MAX) OF RevocationInfo

   RevocationInfo ::= CHOICE {
     crl                    [0] CertificateList,
     delta-crl              [1] CertificateList,
     ocsp                   [2] OCSPResponse,
     other                  [3] OtherRevInfo }

   OtherRevInfo ::= SEQUENCE {
     riType                     OBJECT IDENTIFIER,
     riValue                    ANY DEFINED BY riType }

   -- SCVP Certificate Validation Response

   id-ct-scvp-certValResponse OBJECT IDENTIFIER ::= { id-ct 11 }

   CVResponse ::= SEQUENCE {
     cvResponseVersion          INTEGER,
     serverConfigurationID      INTEGER,
     producedAt                 GeneralizedTime,
     responseStatus             ResponseStatus,
     respValidationPolicy   [0] RespValidationPolicy OPTIONAL,
     requestRef             [1] RequestReference OPTIONAL,
     requestorRef           [2] GeneralNames OPTIONAL,
     requestorName          [3] GeneralNames OPTIONAL,
     replyObjects           [4] ReplyObjects OPTIONAL,
     respNonce              [5] OCTET STRING OPTIONAL,
     serverContextInfo      [6] OCTET STRING OPTIONAL,
     cvResponseExtensions   [7] Extensions OPTIONAL,
     requestorText          [8] UTF8String (SIZE (1..256)) OPTIONAL }

   ResponseStatus ::= SEQUENCE {
       statusCode               CVStatusCode DEFAULT  okay,
       errorMessage             UTF8String OPTIONAL }

   CVStatusCode ::= ENUMERATED {
       okay                               (0),
       skipUnrecognizedItems              (1),
       tooBusy                           (10),
       invalidRequest                    (11),
       internalError                     (12),
       badStructure                      (20),
       unsupportedVersion                (21),
       abortUnrecognizedItems            (22),
       unrecognizedSigKey                (23),
       badSignatureOrMAC                 (24),
Top   ToC   RFC5055 - Page 72
       unableToDecode                    (25),
       notAuthorized                     (26),
       unsupportedChecks                 (27),
       unsupportedWantBacks              (28),
       unsupportedSignatureOrMAC         (29),
       invalidSignatureOrMAC             (30),
       protectedResponseUnsupported      (31),
       unrecognizedResponderName         (32),
       relayingLoop                      (40),
       unrecognizedValPol                (50),
       unrecognizedValAlg                (51),
       fullRequestInResponseUnsupported  (52),
       fullPolResponseUnsupported        (53),
       inhibitPolicyMappingUnsupported   (54),
       requireExplicitPolicyUnsupported  (55),
       inhibitAnyPolicyUnsupported       (56),
       validationTimeUnsupported         (57),
       unrecognizedCritQueryExt          (63),
       unrecognizedCritRequestExt        (64) }

   RespValidationPolicy ::= ValidationPolicy

   RequestReference ::= CHOICE {
     requestHash   [0] HashValue, -- hash of CVRequest
     fullRequest   [1] CVRequest }

   HashValue ::= SEQUENCE {
     algorithm         AlgorithmIdentifier DEFAULT { algorithm sha-1 },
     value             OCTET STRING }

   sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
             oiw(14) secsig(3) algorithm(2) 26 }

   ReplyObjects ::= SEQUENCE SIZE (1..MAX) OF CertReply

   CertReply ::= SEQUENCE {
     cert                       CertReference,
     replyStatus                ReplyStatus DEFAULT success,
     replyValTime               GeneralizedTime,
     replyChecks                ReplyChecks,
     replyWantBacks             ReplyWantBacks,
     validationErrors       [0] SEQUENCE SIZE (1..MAX) OF
                                  OBJECT IDENTIFIER OPTIONAL,
     nextUpdate             [1] GeneralizedTime OPTIONAL,
     certReplyExtensions    [2] Extensions OPTIONAL }
Top   ToC   RFC5055 - Page 73
   ReplyStatus ::= ENUMERATED {
     success                    (0),
     malformedPKC               (1),
     malformedAC                (2),
     unavailableValidationTime  (3),
     referenceCertHashFail      (4),
     certPathConstructFail      (5),
     certPathNotValid           (6),
     certPathNotValidNow        (7),
     wantBackUnsatisfied        (8) }

   ReplyChecks ::= SEQUENCE OF ReplyCheck

   ReplyCheck ::= SEQUENCE {
     check                      OBJECT IDENTIFIER,
     status                     INTEGER DEFAULT 0 }

   ReplyWantBacks ::= SEQUENCE OF ReplyWantBack

   ReplyWantBack::= SEQUENCE {
     wb                         OBJECT IDENTIFIER,
     value                      OCTET STRING }

   CertBundles ::= SEQUENCE SIZE (1..MAX) OF CertBundle

   RevInfoWantBack ::= SEQUENCE {
     revocationInfo             RevocationInfos,
     extraCerts                 CertBundle OPTIONAL }

   SCVPResponses ::= SEQUENCE OF ContentInfo

   -- SCVP Validation Policies Request

   id-ct-scvp-valPolRequest     OBJECT IDENTIFIER ::= { id-ct 12 }

   ValPolRequest ::= SEQUENCE {
     vpRequestVersion           INTEGER DEFAULT 1,
     requestNonce               OCTET STRING }

   -- SCVP Validation Policies Response

   id-ct-scvp-valPolResponse OBJECT IDENTIFIER ::= { id-ct 13 }

   ValPolResponse ::= SEQUENCE {
     vpResponseVersion                INTEGER,
     maxCVRequestVersion              INTEGER,
     maxVPRequestVersion              INTEGER,
     serverConfigurationID            INTEGER,
Top   ToC   RFC5055 - Page 74
     thisUpdate                       GeneralizedTime,
     nextUpdate                       GeneralizedTime OPTIONAL,
     supportedChecks                  CertChecks,
     supportedWantBacks               WantBack,
     validationPolicies               SEQUENCE OF OBJECT IDENTIFIER,
     validationAlgs                   SEQUENCE OF OBJECT IDENTIFIER,
     authPolicies                     SEQUENCE OF AuthPolicy,
     responseTypes                    ResponseTypes,
     defaultPolicyValues              RespValidationPolicy,
     revocationInfoTypes              RevocationInfoTypes,
     signatureGeneration              SEQUENCE OF AlgorithmIdentifier,
     signatureVerification            SEQUENCE OF AlgorithmIdentifier,
     hashAlgorithms                   SEQUENCE SIZE (1..MAX) OF
                                        OBJECT IDENTIFIER,
     serverPublicKeys                 SEQUENCE OF KeyAgreePublicKey
                                        OPTIONAL,
     clockSkew                        INTEGER DEFAULT 10,
     requestNonce                     OCTET STRING OPTIONAL }

   ResponseTypes  ::= ENUMERATED {
     cached-only                (0),
     non-cached-only            (1),
     cached-and-non-cached      (2) }

   RevocationInfoTypes ::= BIT STRING {
     fullCRLs                   (0),
     deltaCRLs                  (1),
     indirectCRLs               (2),
     oCSPResponses              (3) }

   AuthPolicy ::= OBJECT IDENTIFIER

   -- SCVP Check Identifiers

   id-stc OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
             dod(6) internet(1) security(5) mechanisms(5) pkix(7) 17 }

   id-stc-build-pkc-path        OBJECT IDENTIFIER ::= { id-stc 1 }
   id-stc-build-valid-pkc-path  OBJECT IDENTIFIER ::= { id-stc 2 }
   id-stc-build-status-checked-pkc-path
                                OBJECT IDENTIFIER ::= { id-stc 3 }
   id-stc-build-aa-path         OBJECT IDENTIFIER ::= { id-stc 4 }
   id-stc-build-valid-aa-path   OBJECT IDENTIFIER ::= { id-stc 5 }
   id-stc-build-status-checked-aa-path
                                OBJECT IDENTIFIER ::= { id-stc 6 }
   id-stc-status-check-ac-and-build-status-checked-aa-path
                                OBJECT IDENTIFIER ::= { id-stc 7 }
Top   ToC   RFC5055 - Page 75
   -- SCVP WantBack Identifiers

   id-swb OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
             dod(6) internet(1) security(5) mechanisms(5) pkix(7) 18 }

   id-swb-pkc-best-cert-path       OBJECT IDENTIFIER ::= { id-swb 1 }
   id-swb-pkc-revocation-info      OBJECT IDENTIFIER ::= { id-swb 2 }
   id-swb-pkc-public-key-info      OBJECT IDENTIFIER ::= { id-swb 4 }
   id-swb-aa-cert-path             OBJECT IDENTIFIER ::= { id-swb 5 }
   id-swb-aa-revocation-info       OBJECT IDENTIFIER ::= { id-swb 6 }
   id-swb-ac-revocation-info       OBJECT IDENTIFIER ::= { id-swb 7 }
   id-swb-relayed-responses        OBJECT IDENTIFIER ::= { id-swb 9 }
   id-swb-pkc-cert                 OBJECT IDENTIFIER ::= { id-swb 10}
   id-swb-ac-cert                  OBJECT IDENTIFIER ::= { id-swb 11}
   id-swb-pkc-all-cert-paths       OBJECT IDENTIFIER ::= { id-swb 12}
   id-swb-pkc-ee-revocation-info   OBJECT IDENTIFIER ::= { id-swb 13}
   id-swb-pkc-CAs-revocation-info  OBJECT IDENTIFIER ::= { id-swb 14}

   -- SCVP Validation Policy and Algorithm Identifiers

   id-svp OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
             dod(6) internet(1) security(5) mechanisms(5) pkix(7) 19 }

   id-svp-defaultValPolicy OBJECT IDENTIFIER ::= { id-svp 1 }

   -- SCVP Basic Validation Algorithm Identifier

   id-svp-basicValAlg OBJECT IDENTIFIER ::= { id-svp 3 }

   -- SCVP Basic Validation Algorithm Errors

   id-bvae OBJECT IDENTIFIER ::= id-svp-basicValAlg

   id-bvae-expired              OBJECT IDENTIFIER ::= { id-bvae 1 }
   id-bvae-not-yet-valid        OBJECT IDENTIFIER ::= { id-bvae 2 }
   id-bvae-wrongTrustAnchor     OBJECT IDENTIFIER ::= { id-bvae 3 }
   id-bvae-noValidCertPath      OBJECT IDENTIFIER ::= { id-bvae 4 }
   id-bvae-revoked              OBJECT IDENTIFIER ::= { id-bvae 5 }
   id-bvae-invalidKeyPurpose    OBJECT IDENTIFIER ::= { id-bvae 9 }
   id-bvae-invalidKeyUsage      OBJECT IDENTIFIER ::= { id-bvae 10 }
   id-bvae-invalidCertPolicy    OBJECT IDENTIFIER ::= { id-bvae 11 }

   -- SCVP Name Validation Algorithm Identifier

   id-svp-nameValAlg OBJECT IDENTIFIER ::= { id-svp 2 }
Top   ToC   RFC5055 - Page 76
   -- SCVP Name Validation Algorithm DN comparison algorithm

   id-nva-dnCompAlg   OBJECT IDENTIFIER ::= { id-svp 4 }

   -- SCVP Name Validation Algorithm Errors

   id-nvae OBJECT IDENTIFIER ::= id-svp-nameValAlg

   id-nvae-name-mismatch          OBJECT IDENTIFIER ::= { id-nvae 1 }
   id-nvae-no-name                OBJECT IDENTIFIER ::= { id-nvae 2 }
   id-nvae-unknown-alg            OBJECT IDENTIFIER ::= { id-nvae 3 }
   id-nvae-bad-name               OBJECT IDENTIFIER ::= { id-nvae 4 }
   id-nvae-bad-name-type          OBJECT IDENTIFIER ::= { id-nvae 5 }
   id-nvae-mixed-names            OBJECT IDENTIFIER ::= { id-nvae 6 }

   -- SCVP Extended Key Usage Key Purpose Identifiers

   id-kp OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
             dod(6) internet(1) security(5) mechanisms(5) pkix(7) 3 }

   id-kp-scvpServer               OBJECT IDENTIFIER ::= { id-kp 15 }

   id-kp-scvpClient               OBJECT IDENTIFIER ::= { id-kp 16 }

   END

9. Security Considerations

For security considerations specific to the Cryptographic Message Syntax message formats, see [CMS]. For security considerations specific to the process of PKI certification path validation, see [PKIX-1]. A client that trusts a server's response for validation of a certificate inherently trusts that server as much as it would trust its own validation software. This means that if an attacker compromises a trusted SCVP server, the attacker can change the validation processing for every client that relies on that server. Thus, an SCVP server must be protected at least as well as the trust anchors that the SCVP server trusts. Clients MUST verify that the response matches their original request. Clients need to ensure that the server has performed the appropriate checks for the correct certificates under the requested validation policy for the specified validation time, and that the response includes the requested wantBacks and meets the client's freshness requirements.
Top   ToC   RFC5055 - Page 77
   When the SCVP response is used to determine the validity of a
   certificate, the client MUST validate the digital signature or MAC on
   the response to ensure that the expected SCVP server generated it.
   If the client does not check the digital signature or MAC on the
   response, a man-in-the-middle attack could fool the client into
   believing modified responses from the server or responses to
   questions the client did not ask.

   If the client does not include a requestNonce item, or if the client
   does not check that the requestNonce in the response matches the
   value in the request, an attacker can replay previous responses from
   the SCVP server.

   If the server does not require some sort of authorization (such as
   signed requests), an attacker can get the server to respond to
   arbitrary requests.  Such responses may give the attacker information
   about weaknesses in the server or about the timeliness of the
   server's checking.  This information may be valuable for a future
   attack.

   If the server uses the serverContextInfo item to indicate some server
   state associated with a requestor, implementers must take appropriate
   measures against denial-of-service attacks where an attacker sends in
   a lot of requests at one time to force the server to keep a lot of
   state information.

   SCVP does not include any confidentiality mechanisms.  If
   confidentiality is needed, it can be achieved with a lower-layer
   security protocol such as TLS [TLS].

   If an SCVP client is not operating on a network with good physical
   protection, it must ensure that there is integrity over the SCVP
   request-response pair.  The client can ensure integrity by using a
   protected transport such as TLS.  It can ensure integrity by using
   MACs or digital signatures to individually protect the request and
   response messages.

   If an SCVP client populates the userPolicySet in a request with a
   value other than anyPolicy, but does not set the
   requireExplicitPolicy flag, the server may return an affirmative
   answer for paths that do not satisfy any of the specified policies.
   In general, when a client populates the userPolicySet in a request
   with a value other than anyPolicy, the requireExplicitPolicy flag
   should also be set.  This guarantees that all valid paths satisfy at
   least one of the requested policies.
Top   ToC   RFC5055 - Page 78
   In SCVP, historical validation of a certificate returns the known
   status of the certificate at the time specified in validationTime.
   This may be used to demonstrate due diligence, but does not
   necessarily provide the most complete information.  A certificate may
   have been revoked after the time specified in validationTime, but the
   revocation notice may specify an invalidity date that precedes the
   validationTime.  The SCVP server would provide an affirmative
   response even though the most current information available indicates
   the certificate should not be trusted at that time.  SCVP clients may
   wish to specify a validationTime later than the actual time of
   interest to mitigate this risk.

10. IANA Considerations

The details of SCVP requests and responses are communicated using object identifiers (OIDs). The objects are defined in an arc delegated by IANA to the PKIX Working Group. This document also includes four MIME type registrations in Appendix A. No further action by IANA is necessary for this document or any anticipated updates.

11. References

11.1. Normative References

[STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004. [OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 2560, June 1999. [PKIX-1] 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. [PKIX-AC] Farrell, S. and R. Housley, "An Internet Attribute Certificate Profile for Authorization", RFC 3281, April 2002.
Top   ToC   RFC5055 - Page 79
   [PKIX-ALG]    Bassham, L., Polk, W., and R. Housley, "Algorithms and
                 Identifiers for the Internet X.509 Public Key
                 Infrastructure Certificate and Certificate Revocation
                 List (CRL) Profile", RFC 3279, April 2002.

   [PKIX-ALG2]   Schaad, J., Kaliski, B., and R. Housley, "Additional
                 Algorithms and Identifiers for RSA Cryptography for use
                 in the Internet X.509 Public Key Infrastructure
                 Certificate and Certificate Revocation List (CRL)
                 Profile", RFC 4055, June 2005.

   [UTF8]        Yergeau, F., "UTF-8, a transformation format of ISO
                 10646", STD 63, RFC 3629, November 2003.

   [ESS]         Hoffman, P., Ed., "Enhanced Security Services for
                 S/MIME", RFC 2634, June 1999.

   [SMIME-CERT]  Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail
                 Extensions (S/MIME) Version 3.1 Certificate Handling",
                 RFC 3850, July 2004.

   [IKE]         Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
                 Protocol", RFC 4306, December 2005.

   [HTTP]        Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
                 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
                 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

11.2. Informative References

[IKE-GROUPS] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC 3526, May 2003. [RQMTS] Pinkas, D. and R. Housley, "Delegated Path Validation and Delegated Path Discovery Protocol Requirements", RFC 3379, September 2002. [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
Top   ToC   RFC5055 - Page 80

12. Acknowledgments

The lively debate in the PKIX Working Group has made a significant impact on this protocol. Special thanks to the following for their contributions to this document and diligence in greatly improving it. Paul Hoffman Phillip Hallam-Baker Mike Myers Frank Balluffi Ameya Talwalkar John Thielens Peter Sylvester Yuriy Dzambasow Sean P. Turner Wen-Cheng Wang Francis Dupont Dave Engberg Faisal Maqsood Thanks also to working group chair Steve Kent for his support and help.
Top   ToC   RFC5055 - Page 81

Appendix A. MIME Media Type Registrations

Four MIME media type registrations are provided in this appendix.

A.1. application/scvp-cv-request

To: ietf-types@iana.org Subject: Registration of MIME media type application/scvp-cv-request MIME media type name: application MIME subtype name: scvp-cv-request Required parameters: None Optional parameters: None Encoding considerations: Binary Security considerations: Carries a request for information. This request may optionally be cryptographically protected. Interoperability considerations: None Published specification: RFC 5055 Applications that use this media type: SCVP clients sending certificate validation requests Additional information: Magic number(s): None File extension(s): .SCQ Macintosh File Type Code(s): None Person & email address to contact for further information: Ambarish Malpani <ambarish@yahoo.com> Intended usage: COMMON Restrictions on usage: This media type can be used with any protocol that can transport digitally signed objects. Author: Ambarish Malpani <ambarish@yahoo.com> Change controller: IESG
Top   ToC   RFC5055 - Page 82

A.2. application/scvp-cv-response

To: ietf-types@iana.org Subject: Registration of MIME media type application/scvp-cv-response MIME media type name: application MIME subtype name: scvp-cv-response Required parameters: None Optional parameters: None Encoding considerations: Binary Security considerations: The client may require that this response be cryptographically protected, or may choose to use a secure transport mechanism. DPD responses may be unprotected, but the client validates the information provided in the request. Interoperability considerations: None Published specification: RFC 5055 Applications that use this media type: SCVP servers responding to certificate validation requests Additional information: Magic number(s): None File extension(s): .SCS Macintosh File Type Code(s): none Person & email address to contact for further information: Ambarish Malpani <ambarish@yahoo.com> Intended usage: COMMON Restrictions on usage: This media type can be used with any protocol that can transport digitally signed objects. Author: Ambarish Malpani <ambarish@yahoo.com> Change controller: IESG
Top   ToC   RFC5055 - Page 83

A.3. application/scvp-vp-request

To: ietf-types@iana.org Subject: Registration of MIME media type application/scvp-vp-request MIME media type name: application MIME subtype name: scvp-vp-request Required parameters: None Optional parameters: None Encoding considerations: Binary Security considerations: Carries a request for information. Interoperability considerations: None Published specification: RFC 5055 Applications that use this media type: SCVP clients sending validation policy requests Additional information: Magic number(s): None File extension(s): .SPQ Macintosh File Type Code(s): none Person & email address to contact for further information: Ambarish Malpani <ambarish@yahoo.com> Intended usage: COMMON Restrictions on usage: None Author: Ambarish Malpani <ambarish@yahoo.com> Change controller: IESG
Top   ToC   RFC5055 - Page 84

A.4. application/scvp-vp-response

To: ietf-types@iana.org Subject: Registration of MIME media type application/scvp-vp-response MIME media type name: application MIME subtype name: scvp-vp-response Required parameters: None Optional parameters: None Encoding considerations: Binary Security considerations: None Interoperability considerations: None Published specification: RFC 5055 Applications that use this media type: SCVP servers responding to validation policy requests Additional information: Magic number(s): None File extension(s): .SPP Macintosh File Type Code(s): none Person & email address to contact for further information: Ambarish Malpani <ambarish@yahoo.com> Intended usage: COMMON Restrictions on usage: This media type can be used with any protocol that can transport digitally signed objects. Author: Ambarish Malpani <ambarish@yahoo.com> Change controller: IESG
Top   ToC   RFC5055 - Page 85

Appendix B. SCVP over HTTP

This appendix describes the formatting and transportation conventions for the SCVP request and response when carried by HTTP. In order for SCVP clients and servers using HTTP to interoperate, the following rules apply. - Clients MUST use the POST method to submit their requests. - Servers MUST use the 200 response code for successful responses. - Clients MAY attempt to send HTTPS requests using TLS 1.0 or later, although servers are not required to support TLS. - Servers MUST NOT assume client support for any type of HTTP authentication such as cookies, Basic authentication, or Digest authentication. - Clients and servers are expected to follow the other rules and restrictions in [HTTP]. Note that some of those rules are for HTTP methods other than POST; clearly, only the rules that apply to POST are relevant for this specification.

B.1. SCVP Request

An SCVP request using the POST method is constructed as follows: The Content-Type header MUST have the value "application/scvp-cv- request". The body of the message is the binary value of the DER encoding of the CVRequest, wrapped in a CMS body as described in Section 3.

B.2. SCVP Response

An HTTP-based SCVP response is composed of the appropriate HTTP headers, followed by the binary value of the BER encoding of the CVResponse, wrapped in a CMS body as described in Section 4. The Content-Type header MUST have the value "application/scvp-cv- response".
Top   ToC   RFC5055 - Page 86

B.3. SCVP Policy Request

An SCVP request using the POST method is constructed as follows: The Content-Type header MUST have the value "application/scvp-vp- request". The body of the message is the binary value of the BER encoding of the ValPolRequest, wrapped in a CMS body as described in Section 5.

B.4. SCVP Policy Response

An HTTP-based SCVP policy response is composed of the appropriate HTTP headers, followed by the binary value of the DER encoding of the ValPolResponse, wrapped in a CMS body as described in Section 6. The Content-Type header MUST have the value "application/scvp-vp- response".
Top   ToC   RFC5055 - Page 87

Authors' Addresses

Trevor Freeman Microsoft Corporation, One Microsoft Way Redmond, WA 98052 USA. EMail: trevorf@microsoft.com Russell Housley Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170 USA EMail: housley@vigilsec.com Ambarish Malpani Malpani Consulting Services EMail: ambarish@yahoo.com David Cooper National Institute of Standards and Technology 100 Bureau Drive, Mail Stop 8930 Gaithersburg, MD 20899-8930 EMail: david.cooper@nist.gov Tim Polk National Institute of Standards and Technology 100 Bureau Drive, Mail Stop 8930 Gaithersburg, MD 20899-8930 EMail: wpolk@nist.gov
Top   ToC   RFC5055 - Page 88
Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.