Subject: RE: WG Last Call: SCVP

From: "Trevor Freeman" <[email-masked]>
Date: Wed, 23 Jul 2003 12:26:05 -0700

See below.

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]] 
Sent: Friday, July 18, 2003 6:02 AM
To: Trevor Freeman
Cc: [email-masked]; [email-masked]
Subject: Re: WG Last Call: SCVP

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 ?

[Trevor Freeman] Actually, I now realise that a simple reference is not
going to work since the current use of validation policies in SCVP does
not cleanly map onto 3379 use of the term. I will redraft SCVP to clean
this up.

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.

[Trevor Freeman]I will redraft this section and repost.

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.

[Trevor Freeman] This is not a requirement in 3379.

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."

[Trevor Freeman] Wait for the redrafted version

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.

[Trevor Freeman] We are past optimisations. I am only considering
critical issues.

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.

[Trevor Freeman] Wait for the redrafted version.

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.

[Trevor Freeman] Please clarify. We already support returning the
certificate.

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.

[Trevor Freeman] I am redrafting this.

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".
[Trevor Freeman] agreed

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.

[Trevor Freeman] Not true. Both the default policy and the Name
comparison policy do not define a trust root. The trust root must be
supplied in the request or the server chooses.

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 or the sever choose. You requirements are
accommodated by two requests, one for the end cert, and one for the CA
cert or define another algorithm.

[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.

[Trevor Freeman] My previous answer still stands. Two requests using the
default policy meets your request.

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.

[Trevor Freeman] disagree. Its documented on the list along with
countless other issues not in RFCs.

:-)

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.

[Trevor Freeman] We are conformant with 3379. The server decides and may
return a signed or unsigned response.

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.

[Trevor Freeman] I don't think you assertion that the current text is
incorrect - is correct.

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.

[Trevor Freeman] I don't think you assertion that the current text is
incorrect - is correct.

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.

[Trevor Freeman] Since you are an author of 3379, I would expect you to
be better placed to answer why this is in 3379.

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.

[Trevor Freeman] See my response to 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.

[Trevor Freeman] Agreed.

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.

[Trevor Freeman] Actually I have reconsidered this and have changed my
position and now will mandate that this will be signed.

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.

[Trevor Freeman] disagree. The SCVP server MUST have the certificate to
build a response. This is a MUST in 3379.

Denis