[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
SCVP Compliance Matrix
Dear PKIX Working Group:
In preparation for the upcoming straw poll, I am providing the attached
compliance matrix for SCVP. Please review it, and the SCVP specification
too. The updated SCVP specification has been submitted for posting in the
Internet-Draft repository. If should appear soon.
Have a safe and joyous holiday season,
Russ
SCVP Compliance to the Requirements in RFC 3379
Prepared by Russ Housley on 23 December 2002 based on
draft-ietf-pkix-scvp-11.txt
This document responds to the thirty-five conformance statements
extracted from RFC 3379 by Tim Polk and Steve Kent, the co-chairs
of the PKIX Working Group. In each response, a brief description
the manner in which SCVP meets the requirement is provided; a
reference to the appropriate section in the SCVP specification is
also provided.
Topic 1: Basic Protocol
1. If the DPV server does not support the client requested
validation policy, then the DPV server MUST return an error. (4.1.
Basic Protocol)
SCVP includes the OPTIONAL valPolicy field in the query to allow
the client to request the use of a specific validation policy,
which is defined by an OID. See section 3.2.5.
SCVP defines the unrecognizedValPolicy error code for use by the
server if the client provides an unacceptable OID value. See
section 4.7.2.
2. If the DPV request does not specify a validation policy, the
server response MUST indicate the validation policy that was used.
(4.1. Basic Protocol)
SCVP always includes the validation policy used by the server
in non-error responses. Further, the query allows the client
to specify the use of the server default, but the response must
state the validation policy that was used. See section 4.7.6.
3. The protocol MUST allow the client to include these policy
dependent parameters in the DPV request; however, it is expected
that most clients will simply reference a validation policy for a
given application or accept the DPV server's default validation
policy. (4.1. Basic Protocol)
[For the candidate protocol, state the provisions it includes for
such parameters.]
SCVP defines the syntax of a validation policy as an OID
followed by optional parameters. We expect application-specific
validation policies to be defined in other documents, not in the
SCVP protocol document itself. We believe that the PKIX working
group should specify application-specific validation policies for
S/MIME, TLS, and IPsec. See section 3.2.5.
4. The DPV server MUST obtain revocation status information for
the validation time in the client request. (4.1. Basic Protocol)
[a. Indicate how a conformant server for the candidate protocol deals
with other than "current time" validation requests.]
[b. For the candidate protocol, indicate which revocation status
methods a conformant server is required to support. A DPV server
must support some revocation status methods, but the methods
used by different CAs may differ, suggesting that a server needs to
be prepared to deal with several such methods. A server may need
to be configured to use specific methods for specific CAs. How
does the candidate protocol accommodate this need?]
SCVP request includes an optional validityTime in the query. If
the validityTime is not present, the server responds as if the
client provided the date and time at which the server processes
the request, otherwise the server creates the response formatted
as if it was created the time indicated in the validityTime. If
the server does not have appropriate historical information, the
server returns an error. See section 3.2.6.
SCVP supports CRLs, delta CRLs, and OCSP responses. The protocol
specification does not require a server to support any particular
set of these revocation information sources. See section 3.2.9.
5. If the revocation status information for the requested validation
time is unavailable, then the DPV server MUST return a status
indicating that the certificate is invalid. Additional information
about the reason for invalidity MAY also be provided. (4.1 Basic
Protocol)
If the SCVP server does not have appropriate historical information,
the server returns an error. See section 3.2.6.
The unavailableValidityTime error code is specified for this purpose.
See section 4.7.2.
6. The certificate to be validated MUST either be directly provided
in the request or unambiguously referenced, such as the CA
distinguished name, certificate serial number, and the hash of the
certificate, like ESSCertID as defined in [ESS] or
OtherSigningCertificate as defined in [ES-F]. (4.1 Basic Protocol)
[For the candidate protocol, specify which formats for certificate
references MUST be supported by conformant clients and servers.
The lists may differ for clients vs. servers, e.g., servers may bear
the burden of having to accept a larger range of reference types, to
ease the burden on clients.]
In SCVP, the certificate may be included in the request, or it can
be referenced using the ESSCertID type defined in [ESS]. See
section 3.2.1.
7. The DPV client MUST be able to provide to the validation
server, associated with each certificate to be validated, useful
certificates, as well as useful revocation information. (4.1 Basic
Protocol)
[For the candidate protocol, indicate which forms of revocation
status info a conformant client is allowed to provide, and what
forms of revocation status data a conformant server MUST be
prepared to accept from a client.]
SCVP allows the client to optionally provide trust anchors,
intermediate certificates, and revocation information. See
sections 3.2.7, 3.2.8, and 3.2.9, respectively.
8. The DPV server MUST have the certificate to be validated.
When the certificate is not provided in the request, the server
MUST obtain the certificate and then verify that the certificate is
indeed the one being unambiguous referenced by the client. (4.1
Basic Protocol)
[For the candidate protocol, specify what mechanisms a conformant
server MUST implement in support of this requirement, e.g.,
retrieval of a certificate via LDAP queries.]
In SCVP, the certificate may be included in the request, or it
can be referenced using the ESSCertID type defined in [ESS].
See section 3.2.1.
The referenceCertHashFail error code is provided if the hash in
the ESSCertID does not match the certificate fetched by the SCVP
server. See section 4.7.2.
SCVP does not impose any particular certificate repository access
protocol requirements on the SCVP server. If the PKIX Working
Group can quickly agree on a small set that MUST be supported,
then it would be very easy to add.
9. The DPV server MUST include either the certificate or an
unambiguous reference to the certificate (in case of a CA key
compromise) in the DPV response. (4.1 Basic Protocol)
The SCVP server always returns the certificate. See section
4.7.1.
10. The DPV response MUST indicate one of the following status
alternatives:
1. the certificate is valid according to the validation policy.
2. the certificate is not valid according to the validation
policy.
3. the validity of the certificate is unknown according to the
validation policy.
4. the validity could not be determined due to an error.
(source for 10: 4.1 Basic Protocol)
SCVP includes two levels of error status. This is necessary
since a request can include queries for more than one certificate.
The first level deals with the whole request. If there are
serious problems (like a decode error), then none of the queries
are processed. SCVP also allows unrecognized items to be skipped
if the resulting request still makes sense. See section 4.3.
The second level deals with each queried certificate. This allows
a successful response to one queried certificate and an error
response to another. See section 4.7.2.
11. When the certificate is not valid according to the validation
policy, then the reason MUST also be indicated. Invalidity reasons
include:
1. the DPV server cannot determine the validity of the
certificate because a certification path cannot be
constructed.
2. the DPV server successfully constructed a certification path,
but it was not valid according to the validation algorithm in
[PKIX-1].
3. the certificate is not valid at this time. If another
request could be made later on, the certificate could possibly
be determined as valid. This condition may occur before a
certificate validity period has begun or while a certificate
is suspended.
(Source for 11: 4.1 Basic Protocol)
[For the candidate protocol, indicate what if any, other invalidity
reasons are reportable by a conformant server.]
SCVP uses the following ASN.1 type for errors associated with
individual certificate queries:
ReplyStatus ::= ENUMERATED {
success (0),
unrecognizedCheck (1),
unrecognizedWantBack (2),
malformedPKC (3),
malformedAC (4),
unrecognizedCertPolicy (5),
unrecognizedValPolicy (6),
unrecognizedExtension (7),
unavailableValidityTime (8),
referenceCertHashFail (9),
certPathConstructFail (10),
certPathNotValid (11),
certPathNotValidNow (12) }
The meaning of these ReplyStatus values are:
0 Success: a definitive answer follows
1 Failure: an OID in the check item is not recognized
2 Failure: an OID in the wantBack item is not recognized
3 Failure: the public key certificate was malformed
4 Failure: the attribute certificate was malformed
5 Failure: the certificate policy OID is not recognized
6 Failure: the validation policy OID is not recognized
7 Failure: the extension OID is not recognized
8 Failure: historical data for the requested validity
time is not available
9 Failure: the referenced certificate did not match the
hash value provided
10 Failure: no certification path could be constructed
11 Failure: the constructed certification path is invalid
12 Failure: the constructed certification path is invalid,
but a query at a later time may be successful
12. The protocol MUST prevent replay attacks, and the replay
prevention mechanism employed by the protocol MUST NOT rely
on synchronized clocks. (4.1 Basic Protocol)
[For the candidate protocol, describe the means by which conformant
clients and servers detect and reject replay attacks.]
SCVP optionally includes a nonce in the request. The client
SHOULD include a nonce in every request to prevent an attacker
from replaying old responses from the server. See section 3.4,
and the Security Considerations.
SCVP does not include a mechanism to detect replayed requests;
however, if the working group considers this important, additional
rules could be used to provide this capability for signed requests.
Replay detection of unsigned requests is not desirable
13. The DPV request MUST allow the client to request that the
server include in its response additional information which will
allow relying parties not trusting the DPV server to be confident
that the certificate validation has correctly been performed.
[...] When the certificate is valid according to the validation
policy, the server MUST, upon request, include that information in
the response. However, the server MAY omit that information when
the certificate is invalid or when it cannot determine the validity.
(4.1 Basic Protocol)
[For the candidate protocol, specify the additional information
that a conformant server MUST be able to provide and indicate how
the set of information to be returned is determined, e.g., if it
may vary depending on the client or other parameters.]
SCVP supports the return of the following information for public
key certificates:
- Certification path built for the certificate;
- Proof of revocation status for each certificate in the
certification path;
- Status indication; and
- Public key from the certificate.
SCVP supports the return of the following information for
attribute certificates:
- Certification path built for the AC issuer certificate;
- Proof of revocation status for each certificate in the AC
issuer certification path;
- Proof of revocation status for the attribute certificate; and
- Status indication.
There are no MUST, SHOULD, or MAY statements associated with this
information. If the PKIX Working Group can quickly select the
items that MUST be supported by a server, it would be very easy to
add. See section 3.2.3.
14. The DPV server MUST be able, upon request, copy a text field
provided by the client into the DPV response. (4.1 Basic Protocol)
SCVP supports this requirement with the requestor item. It is
an OCTET STRING. If the PKIX working group thinks that a
UTF8String would be better, this change could easily be made;
however, it would hamper the relay loop detection algorithm in
the current draft. See section 3.3 and section 7.
15. The DPV response MUST be bound to the DPV request so that
the client can be sure that all the parameters from the request have
been taken into consideration by the DPV server to build the
response. This can be accomplished by including a one-way hash
of the request in the response.
[For the candidate protocol, describe how this binding is effected.]
In some environments it may be necessary to present only a DPV
response to another relying party without the corresponding
request. In this case the response MUST be self contained. This
can be accomplished by repeating only the important components
from the request in the response. (4.1 Basic Protocol)
SCVP supports both alternatives, using the following structure:
RequestReference ::= CHOICE {
requestHash [1] HashValue, -- hash of CVRequest
fullRequest [2] CVRequest }
By default, SHA-1 is used to has the request; however, the syntax
accomodates additional one-way hash functions.
The processing associated with each of the alternatives is
described in section 4.4.1 and 4.4.2, respectively.
16. For the client to be confident that the certificate validation was
handled by the expected DPV server, the DPV response MUST be
authenticated, unless an error is reported (such as a badly
formatted request or unknown validation policy).
[For the candidate protocol, specify the response message authentication
mechanisms that a conformant server MUST support, and those
that a conformant client MUST support. Note that clients might be
required to support fewer mechanisms, or might be required to
support only one mechanism from a set, while a server might be
required to support all of the mechanisms in the set, e.g., as a
means of ensuring interoperation.]
For the client to be able prove to a third party that trusts the same
DPV server that the certificate validation was handled correctly,
the DPV response MUST be digitally signed, unless an error is
reported. The DPV server's certificate MUST authenticate the DPV
server. (4.1 Basic Protocol)
Digital signatures are the only authentication mechanism supported
by SCVP. All non-error server responses are signed. The CMS
SignedData content type is used. Support for SHA-1 is needed by
other protocol mechanisms, but a particular digital signature
algorithm is not mandated. See section 4.
17. The DPV server MAY require client authentication, therefore,
the DPV request MUST be able to be authenticated. (4.1 Basic
Protocol)
[For the candidate protocol, describe the request message
authentication mechanisms that a conformant server MUST
support, and those that a conformant client MUST support, to
ensure a minimal level of interoperability. Note that clients might
be required to support fewer mechanisms, or might be required to
support only one mechanism from a set, while a server might be
required to support all of the mechanisms in the set, e.g., as a
means of ensuring interoperation.]
Digital signatures are the only authentication mechanism supported
by SCVP. The request may either be signed or unsigned, and the
server may choose to reject any unsigned requests. The CMS
SignedData content type is used. Support for SHA-1 is needed by
other protocol mechanisms, but a particular digital signature
algorithm is not mandated. See section 3.
18. When the DPV request is authenticated, the client SHOULD be
able to include a client identifier in the request for the DPV server
to copy into the response. Mechanisms for matching this identifier
with the authenticated identity depends on local DPV server
conditions and/or the validation policy. The DPV server MAY
choose to blindly copy the identifier, omit the identifier, or return
an error response. (4.1 Basic Protocol)
[For the candidate protocol, describe provisions for confidentiality,
if any.]
SCVP supports this requirement with the requestor item. It is an
OCTET STRING. If the client includes a requestor value in the
request, then the server MUST return the same value in the
response. See section 3.3.
No provisions are provided for confidentiality, and RFC 3379 does
not anticipate any. RFC 3379 says:
There are no specific confidentiality requirements within this
application layer protocol. However, when confidentiality is
needed, it can be achieved with a lower-layer security protocol.
In recognition of this situation, the SCVP security considerations
say:
SCVP does not include any confidentiality mechanisms.
If confidentiality is needed, it can be achieved with a
lower-layer security protocol.
Topic 2: Relay and Redirection
19. Protocols designed to satisfy these requirements MAY include
optional fields and/or extensions to support relaying, re-direction
or multicasting. [...] If the protocol supports such features,
the protocol MUST include provisions for DPV clients and DPV
servers that do not support such features, allowing them to
conform to the basic set of requirements. (4.2. Relaying, Re-
direction and Multicasting)
[For the candidate protocol, describe any relay, referral, or
multicasting facilities required of conformant server.]
Support for relaying is completely optional. The requestor
item is used to detect relay loops. This mechanism requires
that the identifier not include any zero octets, which is
actually a requirement on clients as well as servers that
support relay. See section 7.
20. When a server supports a relay mechanism, a mechanism to
detect loops or repetition MUST be provided. (4.2. Relaying, Re-
direction and Multicasting)
SCVP uses the requestor item is used to detect relay loops.
See section 7.
21. When a protocol provides the capability for a DPV server to
redirect a request to another DPV server (that is, the protocol
chooses to provide a referral mechanism), a mechanism to provide
information to be used for the re-direction SHOULD be supported.
If such re-direction information is sent back to clients, then the
protocol MUST allow conforming clients to ignore it. (4.2.
Relaying, Re-direction and Multicasting)
[For the candidate protocol, describe what strategy is employed to
deal with redirection by a conformant server and what redirection
features are mandated for a conformant client.]
SCVP does not support referral. We believe that the DPV
protocol should accomodate very lightweight clients, and a
referral mechanism adds complexity to the client. It also
makes the trust model more complicated.
22. Optional parameters in the protocol request and/or response
MAY be provide support for relaying, re-direction or multicasting.
DPV clients that ignore any such optional parameters MUST be
able to use the DPV service. DPV servers that ignore any such
optional parameters MUST still be able to offer the DPV service,
although they might not be able to overcome the limitations
imposed by the network topology. In this way, protocol
implementers do not need to understand the syntax or semantics of
any such optional parameters. (4.2. Relaying, Re-direction and
Multicasting)
SCVP relaying is completely transaprent to the client. The
requestor item must be provided in a relayed request, but the
relaying server provides the value. The requestor value is
constructed in a manner that allows servers that support
relaying to detect loops. Servers that do not support relaying
do not perform any special handling of this item. See section 7.
Topic 3: DPD Requirements
23. Clients MUST be able to specify whether they want, in
addition to the certification path, the revocation information
associated with the path, for the end-entity certificate, for the CA
certificates, or for both. (5. Delegated Path Discovery Protocol)
[For the candidate protocol, specify what revocation status data
types MUST be supported by a conformant server.]
SCVP supports CRLs, delta CRLs, and OCSP responses. The protocol
allows the client to indicate that revocation status information
is desired, but the client does not indicate the type. The
validation policy could indicat the type of revocation information
that is returned. See section 3.2.9 for a discussion of the
revocation information. See section 3.2.3 for a discussion of
the wantBack item that is used to request revocation information.
24. If the DPD server does not support the client requested path
discovery policy, the DPD server MUST return an error. (5.
Delegated Path Discovery Protocol)
SCVP includes the OPTIONAL valPolicy field in the query to
allow the client to request the use of a specific validation
policy, which is defined by an OID. See section 3.2.5.
SCVP defines the unrecognizedValPolicy error code for use by
the server if the client provides an unacceptable OID value.
See section 4.7.2.
25. The DPD request MUST allow more elaborated path discovery
policies to be referenced. (5. Delegated Path Discovery Protocol)
[For the candidate protocol, specify the parameters for path
discovery that a conformant server MUST support, i.e., the
minimum path discovery policy supported, and specify what
optional path discovery parameters a server SHOULD/MAY
support.]
SCVP includes the OPTIONAL valPolicy field in the query to
allow the client to request the use of a specific validation
policy, which is defined by an OID. See section 3.2.5.
SCVP allows the client to optionally provide trust anchors,
intermediate certificates, and revocation information. See
sections 3.2.7. 3.2.8, and 3.2.9, respectively. Any other
input to the path validation algorithim must be handled as
a parameter to the validation policy.
26. If the trust anchor is a self-signed certificate, that self-signed
certificate MUST NOT be included. In addition, if requested, the
revocation information associated with each certificate in the path
MUST also be returned. (5. Delegated Path Discovery Protocol)
[For the candidate protocol, specify the types of revocation status
data that a conformant server MUST support.]
SCVP allows the client to specify trust anchors in the query.
A trust anchor can be specified by a certificate, a reference to
a certificat, or "raw" trust anchor information, which consists
of the distinguished name, public key algorithm (including optional
algorithm paramters), and the public key. SCVP says:
The trust anchor itself, regardless of its form, MUST NOT
be included in any certification path constructed by the
SCVP server.
See section 3.2.7 for a discussion of trust anchors.
SCVP supports CRLs, delta CRLs, and OCSP responses. The protocol
specification does not require a server to support any particular
set of these revocation information types. If the PKIX Working
Group can quickly agree on the set that MUST be supported, then
it would be very easy to add. See section 3.2.9.
27. By default, the DPD server MUST return a single certification
path for each end-entity certificate in the DPD request. (5.
Delegated Path Discovery Protocol)
SCVP only returns a single certification path. If the returned
certification path is unacceptable to the client, a subsequent
request is needed to obtain a different certification path. The
serverContextInfo item in the query is used to notify the SCVP
server that the previously returned certification path(s) are
unacceptiable and a different one is desired. See section 3.2.4.
28. Therefore, the DPD client MUST have a means of obtaining
more than one certification path for each end-entity certificate in
the DPD request. At the same time, the mechanism for obtaining
additional certification paths MUST NOT impose protocol state on
the DPD server. (5. Delegated Path Discovery Protocol)
[For the candidate protocol, provide a state machine description of DPD
operation, to demonstrate that this requirement is met.]
The serverContextInfo item in the query is opaque to the client. It
can represent SCVP server state, it can identify previously returned
certification paths, or any other locally known mechanism. See
section 3.2.4.
The following description, while not a complete state machine,
provides a clear understanding of protocol operation.
1. Client sends request to server, requesting a certification
path. The wantBack item contains id-swb-aa-cert-path.
2. Server constructs a certification path, and it is returned
in the replyWantBack item. Additionally, the
serverContextInfo item is set. One possible mechanism is
to store a sequence of hash values in the serverContextInfo
item, where each hash value is the SHA-1 hash of the DER
encoding of the certification path. In this situation, the
sequence contains a single hash value.
3. Client finds the returned certification path unacceptable.
The query is repeated, but the serverContextInfo item is
set to the value from the most recent reply.
4. Server constructs a certification path, and computes the DER
encoding of the certification path. If it matches one of
hash values in the serverContextInfo item, it is discarded.
This process is repeated until a certification path is found
that is not already represented by a hash value. The SHA-1
hash of this certification path is added to the sequence
from the query serverContextInfo item. The server returns
the certification path in the replyWantBack item and the
updated serverContextInfo item.
5. If the client is still unsatisfied, repeat step 3 and 4
as many times as necessary. If the server is unable to
construct a certification path that is not represented in
the serverContextInfo item, the certPathConstructFail error
is returned.
29. Path discovery MUST be performed according to the path
discovery policy. The DPD response MUST indicate one of the
following status alternatives:
1. one or more certification paths was found according to the
path discovery policy, with all of the requested revocation
information present.
2. one or more certification paths was found according to the
path discovery policy, with a subset of the requested
revocation information present.
3. one or more certification paths was found according to the
path discovery policy, with none of the requested revocation
information present.
4. no certification path was found according to the path
d iscovery policy.
5. path construction could not be performed due to an error.
(Source for 29: 5. Delegated Path Discovery Protocol)
SCVP indicates query success or failure with the replyStatus item.
See section 4.7.2.
SCVP indicates the success or failure of each requested check in
the replyChecks item. See section 4.7.4.
SCVP provides the requested information in the replyWantBack item.
See section 4.7.5.
30. For the client to be confident that all of the elements from the
response originate from the expected DPD server, an authenticated
response MAY be required. For example, the server might sign
the response or data authentication might also be achieved using a
lower-layer security protocol. (5. Delegated Path Discovery
Protocol)
[For the candidate protocol, specify whether conformant
servers MUST be capable of generating authenticated responses,
what authentication mechanisms they MUST support, and what
authentication mechanisms conformant clients MUST support.
Note that clients might be required to support fewer mechanisms,
or might be required to support only one mechanism from a set,
while a server might be required to support all of the mechanisms
in the set, e.g., as a means of ensuring interoperation.]
Digital signatures are the only authentication mechanism supported
by SCVP. All non-error server responses are signed. The CMS
SignedData content type is used. Support for SHA-1 is needed by
other protocol mechanisms, but a particular digital signature
algorithm is not mandated. See section 4.
31. The DPD server MAY require client authentication, allowing
the DPD request MUST to be authenticated. (5. Delegated Path
Discovery Protocol)
[For the candidate protocol, specify whether conformant servers
MUST be capable of authenticating requests, what authentication
mechanisms they MUST support, and what authentication mechanisms
conformant clients MUST support. Note that clients might be
required to support fewer mechanisms, or might be required to
support only one mechanism from a set, while a server might be
required to support all of the mechanisms in the set, e.g., as a
means of ensuring interoperation..]
Digital signatures are the only authentication mechanism supported
by SCVP. The request may either be signed or unsigned, and the
server may choose to reject any unsigned requests. The CMS
SignedData content type is used. Support for SHA-1 is needed by
other protocol mechanisms, but a particular digital signature
algorithm is not mandated. See section 3.
32. Using a separate request/response pair, the DPV or DPD client
MUST be able to obtain references for the default policy or for all
of the policies supported by the server. (6. DPV and DPD Policy
Query)
The validation Policies Request (VPRequest) and the Validation
Policies Response (VPResponse) are used to obtain the set of
validation policies supported by a SCVP server. The VPRequest is
defined in section 5, and the V{Response is defined in section 6.
33. In order to succeed, one valid certification path (none of the
certificates in the path are expired or revoked) MUST be found
between an end-entity certificate and a trust anchor and all
constraints that apply to the certification path MUST be verified.
(7. Validation Policy)
SCVP section 1.2 says:
For a certification path to meet the validation policy, it MUST
be a valid certification path as defined in [PKIX-1] and all
validation policy constraints that apply to the certification
path MUST be verified.
[PKIX-1] is a reference to RFC 3280.
34. The validation policy MUST specify the source of revocation
information:
1. full CRLs (or full Authority Revocation Lists) have to be
collected.
2. OCSP responses, using [OCSP], have to be collected.
3. delta CRLs and the relevant associated full CRLs (or full
Authority Revocation Lists) are to be collected.
4. any available revocation information has to be collected.
5. no revocation information need be collected.
(Source for 34: 7.3. Revocation Requirements)
SCVP section 1.2 says:
Revocation checking is one aspect of certification path validation
defined in [PKIX-1]. Therefore, the validation policy MUST specify
the source of revocation information. Five alternatives are
envisioned:
1. full CRLs (or full Authority Revocation Lists) have to be
collected;
2. OCSP responses, using [OCSP], have to be collected;
3. delta CRLs and the relevant associated full CRLs (or full
Authority Revocation Lists) are to be collected;
4. any available revocation information has to be collected;
and
5. no revocation information need be collected.
[PKIX-1] is a reference to RFC 3280, and [OCSP] is a reference to
RFC 2560.
35. The validation policy MUST specify the source of revocation
information:
- full CRLs (or full Authority Revocation Lists) have to be
collected.
- OCSP responses, using [OCSP], have to be collected.
- delta CRLs and the relevant associated full CRLs (or full
Authority Revocation Lists) are to be collected.
- any available revocation information has to be collected.
- no revocation information need be collected.
(source for 35: 7. Validation Policy)
[For the candidate protocol, describe the path validation and path
discovery policy parameters that a conformant server MUST or
SHOULD support, e.g., trust anchor names, keys, name
constraints and policy constraints for trust anchors, path depth
limits, key usage constraints, extended key usage constraints,
required/allowed revocation status data types, etc.]
Conformance item 34 and 35 seem to be identical. SCVP section 1.2
is quoted in the above response.
SCVP defines the syntax of a validation policy as an OID
followed by optional parameters. We expect application-specific
validation policies to be defined in other documents, not in the
SCVP protocol document itself. The parameters for each of these
application-specific validation policies will be defined in the
documents that specify the policies, not in SCVP. We believe that
the PKIX working group should specify application-specific
validation policies for S/MIME, TLS, and IPsec. See section 3.2.5.