Re: WG Last Call: SCVP

[Denis Pinkas <Denis.Pinkas@xxxxxxxx>]

Comments on draft-ietf-pkix-scvp-12.txt
Simple Certificate Validation Protocol (SCVP)

The following 8 issues have been suppressed since there are agreed:
9, 11, 12, 13, 16, 18, 19 and 23.

There remains 16 issues to be discussed. The original numbering has been kept.

1. Section 1.3 Validation Policies

In this section the wording "validation policy" is used but is left
undefined: "A validation policy can be used to specify the SCVP
configuration." Please define it.

[Trevor Freeman] I have added a reference to 3379 to define validation
policy.

[Denis] Are you going to add a reference to section 7 from RFC 3379 ?

This text is copied below.

   A validation policy is a set of rules against which the validation of
   the certificate is performed.

   A validation policy MAY include several trust anchors.  A trust
   anchor is defined as one public key, a CA name, and a validity time
   interval; a trust anchor optionally includes additional constraints.
   The use of a self-signed certificate is one way to specify the public
   key to be used, the issuer name, and the validity period of the
   public key.

   Additional constraints for each trust anchor MAY be defined.  These
   constraints might include a set of certification policy constraints
   or a set of naming constraints.  These constraints MAY also be
   included in self-signed certificates.

   Additional conditions that apply to the certificates in the path MAY
   also be specified in the validation policy.  For example, specific
   values could be provided for the inputs to the certification path
   validation algorithm in [PKIX-1], such as user-initial-policy-set,
   initial-policy-mapping-inhibit, initial-explicit-policy, or initial-
   any-policy-inhibit.

   Additional conditions that apply to the end-entity certificate MAY
   also be specified in the validation policy.  For example, a specific
   name form might be required.

   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.


2. Section 1.3 Validation Policies. The text says: " The validation policy 
is determined by private agreement between the client and the server, ...".

While this may be one case this is not the single case. Please delete
and simply say: "The validation policy MUST be represented as an OBJECT
IDENTIFIER and optionally some additional parameters.

[Trevor Freeman] I have removed the word private.

[Denis] This does not solve my concern. A validation policy may also be 
determined by a policy issuer, while means that there is no agreement 
between the client and the server. The client wants to use a given 
validation policy defined by a policy issuer. If the server supports it, 
then it is fine. If the server does not support it, then the client looks 
for another server supporting it.

For the first of the sentence I would thus propose:

"The validation policy may be determined by the server, or any third party."

For the second part of the sentence, we currently have:

", but it MUST be represented as an OBJECT IDENTIFIER."

I have proposed:

"The validation policy MUST be represented as an OBJECT
IDENTIFIER and optionally some additional parameters."

So the issue is whether we have or not "and optionally some additional 
parameters"

This seems to be the reason of a disagreement on many of the other points.

The validation policy does not only include the processing algorithms but 
also the values used by the processing algorithms to validate a certificate.

The two possibilities, as I see them, are :

- the OID of the validation policy tells everything (i.e. both the 
processing algorithms and all the values to be used by these processing 
algorithms),

- the OID validation policy provides the processing algorithms and some of 
the values to be used, but some other values may be defined as additional 
parameters.

Please, reconsider my proposal.


3. In section 3, SignedData is defined with unsignedAttrs being not used. As 
it will be explained later on, unsignedAttrs should be used to carry 
unsigned certificate values, as well as unsigned revocation information 
(CRLs in particular) while the references (much shorter) will be signed.

This has the major advantage of keeping the size of archived signed 
responses short.

[Trevor Freeman] This is not a requirement in 3379. Correct. However, this 
is a big advantage in the following case:

The RP wants to keep an archive of "YES" answers. If the values are all 
signed, then the size of the archives will get pretty big since the same CA 
certificates and CRLs will be duplicated many times in every "YES" answer. 
If only the references are signed, then the values may be stored elsewhere 
and only once: the same values will be usable for thousands of validations.


4. Section 3.2. The text currently says on page 9: " The OPTIONAL
valPolicy, trustAnchors, intermediateCerts, and revInfos items provide 
context for the client request."

This sentence should be replaced by the following:

"Either the valPolicy item or the trustAnchors item SHALL be used. The
intermediateCerts and revInfos items provide certificates or revocation
status information which MAY be useful to build the response."

[Trevor Freeman] I disagree since the validation policy alone is not
enough. 3379 does not require that the validation policy and the
parameter used with that policy are represented by a single OID.

[Denis] I do not think that you disagree on the second sentence:
" The intermediateCerts and revInfos items provide certificates or 
revocation status information which MAY be useful to build the response."

You probably disagree on the first sentence. It is in fact incorrect.
I would thus propose the following:

"Either the valPolicy item alone or both the valPolicy and the trustAnchors 
items SHALL be used.

The rational is explained in issue 2.


5. Section 3.2.3  wantBack

More options should be allowed to return:

1)  only the references of both the certificates and the associated
revocation status information for the path as a signed parameter,

[Trevor Freeman] This is covered by a certificate status request.

2) both the references of both the certificates and the associated
revocation status information for the path as signed parameter, and the
certificate values together with the associated revocation status
information as an unsigned attribute (see comment 3)

[Trevor Freeman] This is covered by two requests, one for certificate
status and one DPD.

[Denis] This is not optimum, since this could be done by one request.
If this is done in two requests, this may be complicated because there is no 
assurance that the first DPD request will return the path used by the DPV 
request. So the client will have to test if the path that is returned is the 
right one and re-issue a PVD request until it the right one is returned. If 
you maintain two requests, these additional explanations would be useful.

Note : certificate values or associated revocation status information as
a signed parameter are not needed when using the two alternatives above.

[Trevor Freeman] This is not a requirement in 3379. The client is at
liberty to ignore the signature.

[Denis] This relates to issue 2.

It is unclear why *only* the "Public key from the certificate" should be
returned. Either suppress this option, explain why it is sufficient or
return the full certificate.

[Trevor Freeman] This reduces the footprint of a simple client.

[Denis] Maybe. If we keep it, then add the full certificate as another 
possibility.

6. Section 3.2.5  valPolicy . The text says:

"  The valPolicy item, defines the validation policy to be used by the
    SCVP server during certificate validation.  The client can use this
    instead of specifying other SCVP configuration items such as
    trustAnchors.  The value of this item can be determined by private
    agreement between the client and the server, but it MUST be
    represented as an object identifier.  The server might want to
    assign identifiers that indicate that some settings are used in
    addition to others given in the request.  In this way, the
    validation policy object identifier can be a shorthand for some SCVP
    options, but not others".

Replace the whole with:

"  The valPolicy item, defines the validation policy to be used by the
    SCVP server during certificate validation.  The client MUST either
    use it or use trustAnchors which allows to define relatively simple
    validation policies".

[Trevor Freeman] I have removed the second sentence and the word
"private" from the third sentence.

[Denis] This does not solve my concern. See issue 2.

I would propose the following rephrasing:

"  The valPolicy item, defines the validation policy to be used by the
    SCVP server during certificate validation.  The client MUST either
    use it or use it in combination with trustAnchors. The second option
    allows to define relatively simple validation policies".


7. Section 3.2.5  valPolicy . The text says: "All SCVP servers MUST support 
the default policy". This is fine. However, it is important that the client 
may know the parameters of the default policy when the default policy has 
been used by the server. So the default policy SHALL define its parameters.

[Trevor Freeman] the default policy has no parameters - it is a set of rules 
as per 3379.

[Denis] As explained in issue 2, a validation policy must at least define 
one root key, so it is not true to say that it has no parameter.

In order to be able to use this protocol with Qualified Certificates (as per 
the European Directive on Electronic Signatures) certPolicies should further 
be subdivided in two categories: certPolicy for the end-entity certificate 
and certPolicies for CA certificates (currently CA certificates do not have 
certPolicies mandated as per the European Directive on Electronic Signatures).

It is thus propose to defined three parameters for the default policy:

  - trustAnchors,
  - certPolicy for the end-entity certificate,
  - certPolicies for CA certificates.

As mentioned in the text, revocation conditions include any source of
revocation available.

[Trevor Freeman] This is not a requirement for 3379. The trust anchors
are specified in the request. You requirements are accommodated by two
requests, one for the end cert, and one for the CA cert.

[Denis] No. This would not solve my concern. The EESSI  standards built upon 
the EU Directive ask for a given CP to be present in the end-entity 
certificate, but place no such constraint on the CP from the CA 
certificates. It would however be nice to be able to use the default 
validation policy in such a case.

8. Section 3.2.5.1 The need and the rational for this section could not
be understood: an OID unambiguously identity a validation policy, a "name
Validation Policy" or "Validation Policy name" (?) would not add
anything.

Please explain or delete.

[Trevor Freeman] This was asked for at IETF 56 as an example for another
validation policy.

[Denis] Adding an explanation in the document like "This was asked for at 
IETF 56" would not be sufficient.

:-)

I still do not understand. Please provide additional explanations in the 
main body of the document (or delete).


10. Section 4 Validation Response. The text states: " An unsigned response 
MUST only be generated for an error status". This is contradictory with the 
preamble where it is said:

"SCVP can be used by clients that do much of the certificate processing
themselves but simply want an untrusted server to collect information
for them."

When simply collecting certification paths, responses do not need to be
signed. Thus clients should have a way to indicate whether they want
signed responses or not.

[Trevor Freeman] This is not a requirement in 3379. The client can
ignore the signature.

[Denis] I disagree. This is a DPD requirement. RFC 3379 states:

   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.

Signing takes time and resources. Please do not mandate the signing operation.


14. Section 4.4 requestReference, page 22. The text states: "However, the 
requestNonce provides a better mechanism for matching requests and 
responses". This is incorrect. Change into:

"While requestRef allows to detect that the request was modified, the 
requestNonce parameter provides replay protection."

[Trevor Freeman] disagree

[Denis] You disagree but you do not provide a rational for it. Please 
explain your position.


15. Section 4.4.1  requestHash, page 23. The text states: "However, the 
requestNonce provides a better mechanism for matching requests andresponses."

This is incorrect. Change into:

"While requestHash allows to detect that the request was modified, the 
requestNonce parameter provides replay protection."

[Trevor Freeman] disagree

[Denis] You disagree but you do not provide a rational for it. Please 
explain your position.


17. Section 4.6 responder, page 23. The text states: "The OPTIONAL responder 
item is used to identify the server." The rational for this parameter is not 
clear. In PKIX, the subject item from a certificate allows to identify a 
server. Since it is unrelated, it is very doubtful to have a value chosen by 
the client which has only local significance to the SCVP server. Please 
explain or delete.

[Trevor Freeman] This is a requirement of 3379.

[Denis] Maybe, but where from ? I would guess that this item is only needed 
to detect a loop when chaining is being used. If this is the case, please 
add such explanations and what the client SHALL do with it. If this is not 
the case, please add the appropriate explanations.


20. Section 4.7.5 page 28. The text states:

   "The octet string value for the AC issuer certification path used to
    verify the certificate in the request, { id-swb 5 }, contains the
    CertBundle type.  The syntax and semantics of the CertBundle type
    are described in section 3.2.7."

As already mentioned, since

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

and

      PKCReference ::= CHOICE {
        cert              [1] Certificate,
        pkcRef            [2] ESSCertID }

The client should be able to say in his request whether he wants back cert 
or pkcRef. If within the signed response he gets pkcRef, then he should be 
able to say that he wants CertBundle with the option cert as an unsigned 
attribute. The integrity of this unsigned parameter can easily be checked 
using the signed pkcRef.

[Trevor Freeman] disagree

[Denis] See item 3.


21. Section 4.7.6 valPolicy, page 29. The text states: "The valPolicy value 
MUST NOT be id-svp-defaultValPolicy".

If the default policy has been used, then the client MUST be able to
know which one it was: the default policy may vary with the time.

Change into:

"When the valPolicy value is id-svp-defaultValPolicy, then all the
parameters from that policy MUST be returned."

[Trevor Freeman] Disagree. If the client wants all the parameters used
with the validation policy, then they can ask for the request to be
included in the response.

[Denis] Fine. However, it would be nice to include this explanation in the 
document.


22. Section 6 Validation Policies Response. The text states: "The response 
is not signed by the server". It would be nice to include a variant that 
would allow the response to be signed.

[Trevor Freeman] Disagree.

[Denis] You disagree but you do not provide a rational for it. Please 
explain your position.


24. Addition. At present, PKCReference is defined as:

       PKCReference ::= CHOICE {
        cert              [1] Certificate,
        pkcRef            [2] ESSCertID }

In OCSPv2 a third alternative, i.e. certIdWithSignature has been introduced. 
It would be interesting to be able to support it. It allows an OCSPserver 
(and thus an SCVP server) to answer when it does not have access to the 
value of the certificate (in particular when it *only* uses CRLs in the 
background), whereas ESSCertID would be useless.

certIdWithSignature is a compact way to specify unambiguously a certificate 
and to allow to verify a certification path.

    CertIdWithSignature ::= SEQUENCE {
         issuerandSerialNumber     IssuerandSerialNumber,
         tbsCertificateHash        BIT STRING,
         certSignature             CertSignature
    }

IssuerandSerialNumber is defined in [RFC3369] section 10.2.4.

tbsCertificateHash contains a hash value computed over the ASN.1 DER
encoded tbsCertificate field from the certificate using the hash
function identified in the signature algorithm from the signature.

certSignature contains the signature fields from the certificate.

    CertSignature ::= SEQUENCE {
         signatureAlgorithm        AlgorithmIdentifier,
         signatureValue            BIT STRING
    }
[Trevor Freeman] Disagree. This is not a requirement in 3379.

[Denis] Yes, this is not in RFC 3379 but this comes from an observation made 
after RFC 3379 was done and when the OCSPv2 draft was written. Please take a 
closer look at this issue.

Denis