< draft-ietf-pkix-scvp-07.txt   draft-ietf-pkix-scvp-08.txt >
Internet Draft Ambarish Malpani Internet Draft Ambarish Malpani
draft-ietf-pkix-scvp-07.txt ValiCert, Inc draft-ietf-pkix-scvp-08.txt ValiCert, Inc
February 2002 Russ Housley March 2002 Russ Housley
Expires in six months RSA Laboratories Expires in six months RSA Laboratories
Trevor Freeman Trevor Freeman
Microsoft Corp Microsoft Corp
Simple Certificate Validation Protocol (SCVP) Simple Certificate Validation Protocol (SCVP)
Status of this memo Status of this memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC 2026. provisions of Section 10 of RFC 2026.
skipping to change at line 55 skipping to change at line 55
variety of applications that can use public key certificates but are variety of applications that can use public key certificates but are
burdened by the overhead of validating the certificates when all the burdened by the overhead of validating the certificates when all the
application really wants is the public key and identity from the application really wants is the public key and identity from the
certificate, and a determination of whether or not the certificate may certificate, and a determination of whether or not the certificate may
be used for a particular purpose. There are other applications that be used for a particular purpose. There are other applications that
can perform certification path validation but have no reliable method can perform certification path validation but have no reliable method
of constructing a certification path to a trust anchor. of constructing a certification path to a trust anchor.
1.1 SCVP overview and requirements 1.1 SCVP overview and requirements
[Once the DPV & DPD Requirements document passes WG Last Call, this
section will be updated to reference that document.]
The primary goals of SCVP are to make it easier for applications to The primary goals of SCVP are to make it easier for applications to
deploy systems using a PKI and to allow central administration of deploy systems using a PKI and to allow central administration of
PKI policies. Parts of SCVP can be used by clients that do much of the PKI policies. Parts of SCVP can be used by clients that do much of the
PKI processing themselves and simply want a useful but untrusted server PKI processing themselves and simply want a useful but untrusted server
that will collect information for them. Other parts can be used by that will collect information for them. Other parts can be used by
clients that have complete trust in the server to both offload the work clients that have complete trust in the server to both offload the work
of certificate validation and to ensure that policies are enforced in a of certificate validation and to ensure that policies are enforced in a
consistent fashion across an enterprise. consistent fashion across an enterprise.
Untrusted SCVP servers can provide clients the certification paths needed Untrusted SCVP servers can provide clients the certification paths needed
skipping to change at line 111 skipping to change at line 114
the server "don't give me an answer unless you understand this the server "don't give me an answer unless you understand this
extension", and marking a response extension as critical says "don't extension", and marking a response extension as critical says "don't
use this response unless you understand this extension". Without the use this response unless you understand this extension". Without the
critical bit in the extensions, either the semantics of extensions critical bit in the extensions, either the semantics of extensions
would have to be changed to essentially say "all extensions are would have to be changed to essentially say "all extensions are
critical" (which is overkill for some extensions that might really be critical" (which is overkill for some extensions that might really be
optional), or the semantics would have to be changed to say "you can optional), or the semantics would have to be changed to say "you can
never rely on the other party understanding an extension", which would never rely on the other party understanding an extension", which would
limit the usefulness of some extensions. limit the usefulness of some extensions.
- Need to deal with certificate URLs, where a client doesn't have the - Should we allow another way of specifying trust anchors? If so, it
certificate, but just a pointer to where the certificate is needs to include (1) the trusted issuer name, (2) the trusted public
located. Should we even try and deal with this? key algorithm, (3) the trusted public key, and (4) optionally, the
[WG concensus at the Utah IETF was no] trusted public key parameters associated with the public key.
- Is there any value to an "unvalidated path"? - Is there any value to an "unvalidated path"?
- Should SCVP support validation of attribute certificates? - The structure allows for the validation of other objects, such as
attribute certificates, to be easily added as Query CHOICE items.
Should we change the name of the protocol to reflect this flexibility?
- Should we allow for other methods of authenticating a response (we - Can CertBundle contain objects of a different type than the object
only allow for signed responses right now). Examples would be using being queried? For example, if the client wants the server to validate
a shared secret and HMAC, using a trusted channel between the a public key certificate, can the CertBundle contain an attribute
server and the client, etc. certificate?
- Can TrustedCerts contain objects of a different type than the object
being queried? For example, if, in the future, the client wants the
server to validate a attribute certificate, can the CertBundle contain
a public key certificate?
- Should we require the certReplies SEQUENCE items to be listed in a
particular order?
- ReplyTypesOfCheck and ReplyWantBack use the Extensions structure.
What does the critical bit mean? Should a different structure be used?
- TODO: Need to add OPTIONAL variables in the request to be able to - TODO: Need to add OPTIONAL variables in the request to be able to
control inputs to the path validation algorithm control inputs to the path validation algorithm.
- TODO: Show to delegate SCVP signing authority - TODO: Show how to delegate SCVP signing authority.
- TODO: Add extensions to allow client to require server to validate - TODO: Add extensions to allow client to require server to validate
a certificate for SSL/TLS, S/MIME (sending and receiving mails, also a certificate for a particular context, such as SSL/TLS, S/MIME, or
for both encryption and signing) IPsec.
- TODO: Allow the response to be unsigned if it is simply reporting
an error. Generating malformed requests should not force the server
to perform a private key operation.
- TODO: Change the structure of RequestHash to be algorithm identifier
followed by hash value. This will allow any one-way hash algorithm
to be used.
- TODO: Explain semantics of thisUpdate and nextUpdate in responses
- TODO: Move error codes that apply to the whole request up a level
2. Protocol 2. Protocol
The SCVP protocol uses a simple request-response model. That is, a SCVP The SCVP protocol uses a simple request-response model. That is, a SCVP
client creates a single request and sends it to the server; the server client creates a single request and sends it to the server; the server
creates a single response and sends it to the client. Typical use of creates a single response and sends it to the client. Typical use of
SCVP is expected to be over HTTP, and possibly email. This document SCVP is expected to be over HTTP, and possibly email. This document
registers MIME types for SCVP requests and responses. registers MIME types for SCVP requests and responses.
3. Request 3. Request
skipping to change at line 157 skipping to change at line 185
There are two forms of SCVP request: unsigned and signed. There are two forms of SCVP request: unsigned and signed.
A signed request can be used to authenticate the client to the A signed request can be used to authenticate the client to the
server. A server MAY require all requests to be signed, and server. A server MAY require all requests to be signed, and
a server MAY discard all unsigned requests. Alternatively, a server MAY discard all unsigned requests. Alternatively,
a server MAY choose to process unsigned requests. a server MAY choose to process unsigned requests.
The unsigned request consists of a PSRequest encapsulated in a The unsigned request consists of a PSRequest encapsulated in a
ContentInfo. ContentInfo.
id-ct OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
ct(1) }
ContentInfo { ContentInfo {
contentType id-ct-scvp-psRequest, contentType id-ct-scvp-psRequest,
-- (1.2.840.113549.1.9.16.1.10)
content PSRequest content PSRequest
} }
id-ct-scvp-psRequest OBJECT IDENTIFIER ::= {id-ct 10}
The signed request consists of a PSRequest encapsulated in a The signed request consists of a PSRequest encapsulated in a
SignedData which is in turn encapsulated in a ContentInfo. SignedData which is in turn encapsulated in a ContentInfo.
ContentInfo { ContentInfo {
contentType id-signedData, -- (1.2.840.113549.1.7.2) contentType id-signedData, -- (1.2.840.113549.1.7.2)
content SignedData content SignedData
} }
SignedData { SignedData {
version CMSVersion, version CMSVersion,
digestAlgorithms DigestAlgorithmIdentifiers, digestAlgorithms DigestAlgorithmIdentifiers,
encapContentInfo EncapsulatedContentInfo, encapContentInfo EncapsulatedContentInfo,
certificates CertificateSet, -- (Optional), certificates CertificateSet, -- (Optional)
crls CertificateRevocationLists, -- (Optional) crls CertificateRevocationLists, -- (Optional)
signerInfos SET OF SignerInfos -- (only one in SCVP) signerInfos SET OF SignerInfos -- (only one in SCVP)
} }
SignerInfo { SignerInfo {
version CMSVersion, version CMSVersion,
sid SignerIdentifier, sid SignerIdentifier,
digestAlgorithm DigestAlgorithmIdentifier, digestAlgorithm DigestAlgorithmIdentifier,
signedAttrs SignedAttributes, -- (Required) signedAttrs SignedAttributes, -- (Required)
signatureAlgorithm SignatureAlgorithmIdentifier, signatureAlgorithm SignatureAlgorithmIdentifier,
signature SignatureValue, signature SignatureValue,
unsignedAttrs UnsignedAttributes -- (not used in SCVP) unsignedAttrs UnsignedAttributes -- (not used in SCVP)
} }
EncapsulatedContentInfo { EncapsulatedContentInfo {
eContentType id-ct-scvp-psRequest, eContentType id-ct-scvp-psRequest,
-- (1.2.840.113549.1.9.16.1.10)
eContent OCTET STRING -- Contains PSRequest eContent OCTET STRING -- Contains PSRequest
} }
3.1 PSRequest 3.1 PSRequest
The PSRequest item contains the client request. The PSRequest The PSRequest item contains the client request. The PSRequest
item contains scvpVersion, query, typesOfCheck, and wantBack items. It MAY item contains scvpVersion, query, typesOfCheck, and wantBack items. It MAY
also contain an requestNonce and reqExtensions items. (The "PS" in also contain an requestNonce and reqExtensions items. (The "PS" in
PSRequest means "possibly signed".) PSRequest means "possibly signed".)
skipping to change at line 294 skipping to change at line 318
The Cert item MUST contain an identifier for the type of certificate The Cert item MUST contain an identifier for the type of certificate
and the certificate itself. One type of certificate, for the Internet and the certificate itself. One type of certificate, for the Internet
X.509 PKI [PKIX], is defined, but other types of certificates (such as X.509 PKI [PKIX], is defined, but other types of certificates (such as
attribute certificates [AC] or OpenPGP certificates [OpenPGP]) might attribute certificates [AC] or OpenPGP certificates [OpenPGP]) might
be defined in the future. Cert MUST have the following syntax: be defined in the future. Cert MUST have the following syntax:
Cert ::= CHOICE { Cert ::= CHOICE {
pkixCert [0] Certificate } pkixCert [0] Certificate }
The ASN.1 definition of Certificate is imported from [PKIX].
3.6 ValidityTime 3.6 ValidityTime
The optional validityTime item tells the date and time relative to which The optional validityTime item tells the date and time relative to which
the client wants the server to perform the checks and generate responses. the client wants the server to perform the checks and generate responses.
If the validityTime is present, it MUST be encoded as GeneralizedTime. If the validityTime is present, it MUST be encoded as GeneralizedTime.
If the validityTime is not present, the server is expected to respond If the validityTime is not present, the server MUST respond as if the
as if the client provided the current date and time. client provided the at which the server processes the request.
The information in the corresponding CertReply item in the response The information in the corresponding CertReply item in the response
MUST be formatted as if the server created the response at the time MUST be formatted as if the server created the response at the time
indicated in the validityTime. However, if the server does not have indicated in the validityTime. However, if the server does not have
historical information about that time, it MAY either return an error historical information about that time, it MAY either return an error
or return information for a later time. A client MUST be prepared to or return information for a later time. A client MUST be prepared to
handle responses that contain thisUpdate items that do not match the handle responses that contain thisUpdate items that do not match the
requested validityTime. requested validityTime.
3.7 IntermediateCerts 3.7 IntermediateCerts
skipping to change at line 354 skipping to change at line 380
revInfo item is to provide revocation information to which revInfo item is to provide revocation information to which
the server might not otherwise have access (for example, an the server might not otherwise have access (for example, an
OCSP response that the client received along with the certificate). OCSP response that the client received along with the certificate).
Note that the information in the revInfo item might not be Note that the information in the revInfo item might not be
used by the server, such as if the information is for certificates used by the server, such as if the information is for certificates
that the server does not use in certification path building. that the server does not use in certification path building.
The types of revocation information that can be provided are: a CRL The types of revocation information that can be provided are: a CRL
or an OCSP response. or an OCSP response.
RevocationInfo ::= SEQUENCE { RevocationInfo ::= SEQUENCE {
riType OBJECT IDENTIFIER, riType OBJECT IDENTIFIER,
riValue ANY DEFINED BY riType riValue ANY DEFINED BY riType }
}
The object identifiers for riType for CRLs and OCSP are id-ri-crl and
id-ri-ocsp-response, respectively.
id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) } dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
id-ri OBJECT IDENTIFIER ::= { id-pkix 16 } -- revocation
-- information types
The object identifiers for riType for CRLs and OCSP are id-ri-crl and id-ri OBJECT IDENTIFIER ::= { id-pkix 16 }
id-ri-ocsp-response respectively.
id-ri-crl OBJECT IDENTIFIER ::= { id-ri 1 } id-ri-crl OBJECT IDENTIFIER ::= { id-ri 1 }
id-ri-ocsp-response OBJECT IDENTIFIER ::= { id-ri 2 } id-ri-ocsp-response OBJECT IDENTIFIER ::= { id-ri 2 }
3.11 PolicyID 3.11 PolicyID
The policyID optional item specifies the policy identifier that the The policyID optional item specifies the policy identifier that the
server MUST use when forming a certification path. The policyID item server MUST use when forming a certification path. The policyID item
MUST contain the OID that defines the policy. MUST contain the OID that defines the policy.
3.12 ConfigID 3.12 ConfigID
skipping to change at line 396 skipping to change at line 422
might be a shorthand for some SCVP options, but not others. might be a shorthand for some SCVP options, but not others.
3.13 QueryExtensions 3.13 QueryExtensions
The QueryExtensions item specifies a list of extensions to the SCVP The QueryExtensions item specifies a list of extensions to the SCVP
protocol. For example, a client might request additional information protocol. For example, a client might request additional information
about the certificate(s) in the CertsQuery. The QueryExtensions item, about the certificate(s) in the CertsQuery. The QueryExtensions item,
when present, contains a sequence of Extension items, each of which when present, contains a sequence of Extension items, each of which
contains an ExtnID item, a Critical item, and an ExtnValue item. contains an ExtnID item, a Critical item, and an ExtnValue item.
The syntax for Extensions is imported from [PKIX].
3.14 ExtnID 3.14 ExtnID
The ExtnID item is an identifier for the extension. It contains The ExtnID item is an identifier for the extension. It contains
the object identifier (OID) of the extension. the object identifier (OID) of the extension.
3.15 Critical 3.15 Critical
The Critical item is a BOOLEAN that tells whether the extension is The Critical item is a BOOLEAN that tells whether the extension is
critical. The values for the item are: critical. The values for the item are:
skipping to change at line 434 skipping to change at line 462
typesOfCheck item is present in a request, it can contain one or more typesOfCheck item is present in a request, it can contain one or more
types of check. For each type of check specified in the request, the types of check. For each type of check specified in the request, the
server MUST perform all the checks requested, or return an error. server MUST perform all the checks requested, or return an error.
The types of checks are: The types of checks are:
- Build a certification path to a trusted root. - Build a certification path to a trusted root.
- Build a validated certification path to a trusted root. - Build a validated certification path to a trusted root.
- Do revocation status checks on the certification path. - Do revocation status checks on the certification path.
Note that revocation status check inherently includes path construction. Note that revocation status check inherently includes path construction.
Also, building a validated certification path DOES NOT imply revocation Also, building a validated certification path does not imply revocation
status checks (although a server may still choose to perform them). status checks (although a server may still choose to perform them).
The TypesOfCheck MUST have the following syntax: The TypesOfCheck MUST have the following syntax:
TypesOfCheck ::= SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER TypesOfCheck ::= SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER
id-stc OBJECT IDENTIFIER ::= { id-pkix 17 } -- SCVP check type arc} id-stc OBJECT IDENTIFIER ::= { id-pkix 17 }
id-stc-build-path OBJECT IDENTIFIER ::= { id-stc 1 }
id-stc-build-path OBJECT IDENTIFIER ::= { id-stc 1 }
id-stc-build-valid-path OBJECT IDENTIFIER ::= { id-stc 2 }
id-stc-build-valid-path OBJECT IDENTIFIER ::= { id-stc 2 }
id-stc-build-valid-status-checked-path id-stc-build-valid-status-checked-path
OBJECT IDENTIFIER ::= { id-stc 3 } OBJECT IDENTIFIER ::= { id-stc 3 }
3.18 WantBack 3.18 WantBack
The wantBack item describes the kind of information the client wants The wantBack item describes the kind of information the client wants
from the server for the certificate(s) in the Query item. If the from the server for the certificate(s) in the Query item. If the
wantBack item is present in a request, it MUST contain one or more types wantBack item is present in a request, it MUST contain one or more types
of information. For each type of information specified in the request, of information. For each type of information specified in the request,
the server MUST return information regarding its finding during the the server MUST return information regarding its finding during the
check (in a successful response). check (in a successful response).
skipping to change at line 506 skipping to change at line 536
4. Response 4. Response
A SCVP server response to the client MUST be a single SCVPResponse A SCVP server response to the client MUST be a single SCVPResponse
item. A SCVPRequest item is carried in an application/scvp-response MIME item. A SCVPRequest item is carried in an application/scvp-response MIME
body part. body part.
There are two forms of an SCVP response: unsigned and signed. An unsigned There are two forms of an SCVP response: unsigned and signed. An unsigned
may only be generated for an error status. may only be generated for an error status.
An unsigned response is as follows: An unsigned response is as follows:
ContentInfo { ContentInfo {
contentType id-ct-scvp-psResponse, contentType id-ct-scvp-psResponse,
-- (1.2.840.113549.1.9.16.1.11)
content PSResponse content PSResponse
} }
id-ct-scvp-psResponse OBJECT IDENTIFIER ::= {id-ct 11}
The signed response consists The signed response consists
of a PSResponse encapsulated in a SignedData which is in turn encapsulated of a PSResponse encapsulated in a SignedData which is in turn encapsulated
in a ContentInfo. in a ContentInfo.
ContentInfo { ContentInfo {
contentType id-signedData, -- (1.2.840.113549.1.7.2) contentType id-signedData, -- (1.2.840.113549.1.7.2)
content SignedData content SignedData
} }
SignedData { SignedData {
skipping to change at line 543 skipping to change at line 573
sid SignerIdentifier, sid SignerIdentifier,
digestAlgorithm DigestAlgorithmIdentifier, digestAlgorithm DigestAlgorithmIdentifier,
signedAttrs SignedAttributes, -- (Required) signedAttrs SignedAttributes, -- (Required)
signatureAlgorithm SignatureAlgorithmIdentifier, signatureAlgorithm SignatureAlgorithmIdentifier,
signature SignatureValue, signature SignatureValue,
unsignedAttrs UnsignedAttributes -- (not used in SCVP) unsignedAttrs UnsignedAttributes -- (not used in SCVP)
} }
EncapsulatedContentInfo { EncapsulatedContentInfo {
eContentType id-ct-scvp-psResponse, eContentType id-ct-scvp-psResponse,
-- (1.2.840.113549.1.9.16.1.11)
eContent OCTET STRING -- Contains PSResponse eContent OCTET STRING -- Contains PSResponse
} }
4.1 PSResponse 4.1 PSResponse
The PSResponse item contains the server response. The PSResponse The PSResponse item contains the server response. The PSResponse
MUST contain scvpVersion, producedAt, responseStatus, and requestHash MUST contain scvpVersion, producedAt, responseStatus, and requestHash
items. The PSResponse MAY also contain replyObjects, requestNonce, and items. The PSResponse MAY also contain replyObjects, requestNonce, and
respExtensions optional items. The PSResponse MUST contain exactly one respExtensions optional items. The PSResponse MUST contain exactly one
CertReply item for each certificate requested in the request. The CertReply item for each certificate requested in the request. The
skipping to change at line 631 skipping to change at line 662
unsupportedVersion (21), unsupportedVersion (21),
abortUnrecognizedItems (22), abortUnrecognizedItems (22),
unrecognizedSigKey (23), unrecognizedSigKey (23),
badSignature (24), badSignature (24),
unableToDecode (25), unableToDecode (25),
notAuthorized (26) notAuthorized (26)
} }
The meaning of the various status codes are: The meaning of the various status codes are:
0 The request was fully processed 0 The request was fully processed
1 The request included unrecognized items; continuing 1 The request included unrecognized items; continuing
10 Too busy; try again later 10 Too busy; try again later
20 The structure of the request was wrong 20 The structure of the request was wrong
21 The version of request is not supported by this server 21 The version of request is not supported by this server
22 The request included unrecognized items; aborting 22 The request included unrecognized items; aborting
23 The key given in the RequestSignature is not recognized 23 The key given in the RequestSignature is not recognized
24 The signature did not match the body of the request 24 The signature did not match the body of the request
25 The encoding was not understood 25 The encoding was not understood
26 The request was not authorized 26 The request was not authorized
27 The request included unsupported items; continuing 27 The request included unsupported items; continuing
28 The request included unsupported items; aborting 28 The request included unsupported items; aborting
4.5 RequestHash 4.5 RequestHash
The requestHash item is the SHA-1 hash of the PSRequest. The The requestHash item is the SHA-1 hash of the PSRequest. The
requestHash item serves the following purposes: requestHash item serves the following purposes:
- It allows a client to determine that the request was not maliciously - It allows a client to determine that the request was not maliciously
modified. modified.
- It allows the client to associate a response with a request when - It allows the client to associate a response with a request when
skipping to change at line 714 skipping to change at line 745
typeOfCheckUnrecognized (2), typeOfCheckUnrecognized (2),
wantBackUnrecognized (3), wantBackUnrecognized (3),
certMalformed (4), certMalformed (4),
policyIDUnrecognized (5), policyIDUnrecognized (5),
configInfoUnrecognized (6), configInfoUnrecognized (6),
unauthorizedRequest (7) unauthorizedRequest (7)
} }
The ReplyStatus codes have the following meaning: The ReplyStatus codes have the following meaning:
0 Success: a definitive answer follows 0 Success: a definitive answer follows
1 Failure: the certificate type is not recognized 1 Failure: the certificate type is not recognized
2 Failure: an item wanted in TypesOfCheck is not recognized 2 Failure: an item wanted in TypesOfCheck is not recognized
3 Failure: an item wanted in WantBack is not recognized 3 Failure: an item wanted in WantBack is not recognized
4 Failure: the certificate was malformed 4 Failure: the certificate was malformed
5 Failure: the mandatory PolicyID is not recognized 5 Failure: the mandatory PolicyID is not recognized
6 Failure: the ConfigurationIdentifier is not recognized 6 Failure: the ConfigurationIdentifier is not recognized
7 Failure: unauthorized request 7 Failure: unauthorized request
Status code 4 is used to tell the client that the request was properly Status code 4 is used to tell the client that the request was properly
formed but the certificate in question was not. This is useful to formed but the certificate in question was not. This is useful to
clients that cannot parse a certificate. clients that cannot parse a certificate.
4.8 ThisUpdate 4.8 ThisUpdate
The ThisUpdate item tells the time at which the information in the The ThisUpdate item tells the time at which the information in the
CertReply was correct. The ThisUpdate item represents the date as CertReply was correct. The ThisUpdate item represents the date as
UTC. UTC.
skipping to change at line 751 skipping to change at line 782
4.10 ReplyTypesOfCheck 4.10 ReplyTypesOfCheck
The ReplyTypesOfCheck contains the responses to the TypesOfCheck item The ReplyTypesOfCheck contains the responses to the TypesOfCheck item
in the request. It has the same form as the Extensions item, and the in the request. It has the same form as the Extensions item, and the
OIDs in the ReplyTypesOfCheck item MUST match the OIDS in the OIDs in the ReplyTypesOfCheck item MUST match the OIDS in the
TypesOfCheck item. The criticality bit MUST NOT be set. TypesOfCheck item. The criticality bit MUST NOT be set.
The value for path building to a trusted root, {type-arc 0}, can be The value for path building to a trusted root, {type-arc 0}, can be
one of the following: one of the following:
Value Meaning Value Meaning
0 Built a path ----- -------
1 Could not build a path 0 Built a path
1 Could not build a path
The value for path validation to a trusted root, {type-arc 1}, can be The value for path validation to a trusted root, {type-arc 1}, can be
one of the following: one of the following:
Value Meaning Value Meaning
0 Valid ----- -------
1 Not valid 0 Valid
1 Not valid
The value for the revocation status, {type-arc 2}, can be one of the The value for the revocation status, {type-arc 2}, can be one of the
following: following:
Value Meaning Value Meaning
0 Good ----- -------
1 Revoked 0 Good
2 Unknown 1 Revoked
2 Unknown
4.11 ReplyWantBack 4.11 ReplyWantBack
The ReplyWantBack contains the responses to the WantBack item The ReplyWantBack contains the responses to the WantBack item
in the request. It has the same form as the Extensions item, and the in the request. It has the same form as the Extensions item, and the
OIDs in the ReplyWantBack item MUST match the OIDS in the WantBack OIDs in the ReplyWantBack item MUST match the OIDS in the WantBack
item. The criticality bit MUST NOT be set. item. The criticality bit MUST NOT be set.
The value for the certification chain used to verify the certificate The value for the certification chain used to verify the certificate
in the request, {want-arc 0}, is a CertBundle item. in the request, {want-arc 0}, is a CertBundle item.
skipping to change at line 982 skipping to change at line 1013
compromises a trusted SCVP server, the attacker can change the compromises a trusted SCVP server, the attacker can change the
validation processing for every client that relies on that validation processing for every client that relies on that
server. Thus, an SCVP server must be protected at least as well as the server. Thus, an SCVP server must be protected at least as well as the
trust anchors that the SCVP server trusts. trust anchors that the SCVP server trusts.
Clients MUST check the RequestHash in the response and ensure that it Clients MUST check the RequestHash in the response and ensure that it
matches their original request. Requests contain a lot of information matches their original request. Requests contain a lot of information
that affects the response and clients need to ensure that the server that affects the response and clients need to ensure that the server
response corresponds to the expected request. response corresponds to the expected request.
If the client does not check the signature on the response, a When the SCVP response is used to determine the validity of a
certificate, the client MUST validate the signature on the response
to ensure that it was generated by the expected SCVP server.If the
client does not check the signature on the response, a
man-in-the-middle attack could fool the client into believing modified man-in-the-middle attack could fool the client into believing modified
responses from the server, or responses to questions the client did not responses from the server, or responses to questions the client did not
ask. This attack does not affect the usefulness of some responses (such ask.
as a response that returns a certification path that the client will
validate itself), but does affect things such as a validation response.
If the client does not include a RequestNonce item, or if the client If the client does not include a RequestNonce item, or if the client
does not check that the RequestNonce in the reply matches that in the does not check that the RequestNonce in the reply matches that in the
request, an attacker can replay previous responses from the server. request, an attacker can replay previous responses from the server.
[This is not true if the request hash is used as a nonce by the client.]
If the server does not require some sort of authorization (such as If the server does not require some sort of authorization (such as
signed requests), an attacker can get the server to reply to arbitrary signed requests), an attacker can get the server to reply to arbitrary
requests. Such responses may give the attacker information about requests. Such responses may give the attacker information about
weaknesses in the server or about the timeliness of the server's weaknesses in the server or about the timeliness of the server's
checking. This information may be valuable for a future attack. checking. This information may be valuable for a future attack.
A. References A. References
[MUSTSHOULD] "Key words for use in RFCs to Indicate Requirement [MUSTSHOULD] "Key words for use in RFCs to Indicate Requirement
skipping to change at line 1165 skipping to change at line 1198
rhousley@rsasecurity.com rhousley@rsasecurity.com
Trevor Freeman Trevor Freeman
Microsoft Corporation, Microsoft Corporation,
One Microsoft way One Microsoft way
Redmond, WA98052 Redmond, WA98052
trevorf@microsoft.com trevorf@microsoft.com
F. Changes Between Versions of This Document F. Changes Between Versions of This Document
F.1 Difference between -02 and -03 F.1 Difference between -04 and -05
1. Changed TBSResponse and TBSRequest to PSResponse and
PSRequest. Made signatures optional in both requests and responses.
2. Added a tag to the optional signatures in both requests and
responses.
3. Changed RevocationInfos to RevocationInfo.
4. Removed CertHash completely.
5. Simplified section 3.5, since FullCert has gone away
6. Replaced section 3.6 to talk about Cert, rather than FullCert
7. Replaced ExtensionParameter with ExtensionValue in Section 3.11.
8. Made sure that all SEQUENCE OF are SEQUENCE SIZE (1..MAX) OF
9. Import Extension and used the same definition for Extension as in
RFC2459
10. Replace "trusted root" with "trusted certificate", because a
server or client might decide to put its trust in a certificate that
might not be self-signed. Replaced trustedRoot with trustedCert.
11. Fixed once occurance of definition of requestNonce
12. Removed scvp, scvpReq and scvpResp tags in the XML.
13. Removed the last 2 sentences of the second paragraph Section 3.4
14. Changed last sentence of section 3.13, since you have have multiple
cert chains for a certificate even if there is no cross certification.
15. Changed last sentence of section 3.17.
16. Moved section 3.21 to the response section - 4.4a. We need to
renumber all sections when we are close to being done.
17. Added a default value for the attribute value of ReplyStatus in
the XML.
18. Added IMPORTS to the ASN.1 module.
19. Gave the extensions in different places different names.
20. Changed the way criticality is specified for Extension in XML
21. Added the mime type registration requests
22. Added appendix E and moved Author Information to appendix F
23. Moved signerName from the PSRequest and PSResponse to the
signature part.
24. Removed the second paragraph in section 3.13.
25. Changed a line in section 3.14, first para (about where a client
may have obtained an OCSP response to send to the SCVP server).
26. Got rid of the multiple places where we say what is signed by the
RequestSignature or ResponseSignature (e.g. section 3.1 and 3.2). Also
simplified the definition of the RequestSignature and
ResponseSignature in sections 3 and 4. The should be defined in detail
in the encoding sections.
F.2 Difference between -03 and -04
1. Added format information in the http header in Appendix E.1.1
2. Changed the numbers in the want-arc to start with 0 in section 4.10
3. Added error states to indicate that the request contained
unsupported items in section 4.4.
4. Added acknowledgement to Frank Balluffi and Ameya Talwalkar in
Appendix B.
5. Made nextUpdate optional (renumbered tags in CertReply).
6. Specified the criticality bit in ReplyTypesOfCheck and ReplyWantBack
(sections 4.9 and 4.10)
7. Specified the encoding for the replyTypesOfCheck field
8. Renumbered tag fields for PSResponse.
9. Added a TODO to section 3.4 about Cert URLs.
10. Corrected the section on the ConfigurationIdentifier.
11. Modified TypesOfCheck to allow client to request a non-validated
path.
12. Removed an old (unneeded) line in the security section.
F.3 Difference between -04 and -05
1. Removed the XML format of the syntax 1. Removed the XML format of the syntax
2. Used CMS as the base formatting mechanism 2. Used CMS as the base formatting mechanism
3. Changed the format of RevocationInfo 3. Changed the format of RevocationInfo
4. Specified rules for GeneralizedTime usage 4. Specified rules for GeneralizedTime usage
5. Added a question about the benefit of other types of authentication 5. Added a question about the benefit of other types of authentication
of responses (not just signatures). of responses (not just signatures).
F.4 Differences between -05 and -06 F.2 Differences between -05 and -06
1. Added authors 1. Added authors
2. Fixed language and spelling mistakes 2. Fixed language and spelling mistakes
3. Changed version to scvpVersion 3. Changed version to scvpVersion
F.5 Differences between -06 and -07 F.3 Differences between -06 and -07
1. Updated authors list 1. Updated authors list
2. Closed open issue of whether we should deal with cases where the 2. Closed open issue of whether we should deal with cases where the
client doesn't have the certificate itself client doesn't have the certificate itself
3. Added text for different types of request and wantbacks 3. Added text for different types of request and wantbacks
4. Allow for unsigned error responses 4. Allow for unsigned error responses
 End of changes. 41 change blocks. 
175 lines changed or deleted 113 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/