Subject: Re: Comments to SCVP ID 17

From: Nathalie Jolly <[email-masked]>
Date: Tue, 01 Mar 2005 14:09:43 +0100

Hello,

I have been reading SCVP draft 17 in detail and I send you my reading 
notes. I hope it will help you work on this topic. Since I began 
reading, draft 18 has appeared but I kept working on draft 17. Sorry if 
any of the following remarks have already been addressed.

Please keep in mind that I did not read the previous drafts and thus may
miss some of the design context. I am though quite familiar with
RFCs 2560 and 3280.

The following email deals first with my major remarks/questions on draft
17. I have also written down a non-exhaustive list of minor remarks, 
which you will find at the end of this email.

1- Some general considerations

The abstract and introduction refer to a specification for
implementating DPD/DPV ("certificate path construction and validation"
as stated in the abstract), whereas the rest of the draft specifies 
certificate validation as a whole (certificate content validation + 
revocation status + building and validation of the certification paths, 
depending of the chosen checks).

I would suggest :
- that you rewrite the abstract and introduction so that the purpose of 
the document becomes clearer (SCVP includes DPD/DPV but also deals with 
certificate content and revocation)
- that you distinguish in the text the "DPD" and the "DPV" part.

2- Validation policies, checks and validation algorithms

2.1- The concepts
If I understand correctly :
- checks = the validations that the client wants done,
- validation policy = the values that the client wants the server to use
while performing the checks,
- validation algorithm = the algorithm to be used by the server for
performing the checks.

The server uses the "validation algorithm" in order to perform the
"checks" using the values of the "validation policy".

My feeling is that we need to define a name for (checks + validation
policy + validation algorithm). They are thinly correlated with
one another. In my opinion, the term "validation policy" should refer as
the whole (checks + validation policy + validation algorithm), since the
word "policy" means a global strategy more than just a few numerical values.

Especially the algorithm should be a part of the "validation policy",
since each algorithm is an implementation of a set of checks. We could
have an algorithm per check and combine algorithms for each checks
combination.

Then, the chapters 5 and 6 (Server Policy request and response) would
send to the client the validation policies available, including checks
and algorithms for each response, and not two separate lists for
validation policies and validation algorithms.

I read that reviewers Wen-Cheng Wang and Denis Pinkas are of this
opinion, at least for merging "validation policy" and "validation
algorithm" (maybe not for the "checks"), and I totally agree with them.

2.2- Checks, some complementary remarks

- §1 : Sentence "A server may choose to perform additional checks,
although the server cannot indicate in the response that the additional
checks have been performed." ->

What happens if an error occurs for one of these additional checks ? The
server should be able to send back an error message, which is not
possible if he cannot indicate the additional check in the response. Or
the client will not understand why the server returns an error.

- The text does not address the possibility of keeping the calculated
paths (DPD) in a cache on the server between validation queries (DPV). 
Certification paths should be able to be stored by the SCVP server and 
not calculated for each request, since they do not depend on the 
incoming certificate (2 certificates delivered by the same CA and been 
validated under the same validation policy have the same certification 
path at a given time). Thus, we need to state that the path building is 
optional, if it has been done before and if the CA / validation policy 
information have not been modified.

Therefore, we could have checks such as "id-stc-check-pkc-path" without
the "build" part.

More generally, the text should separate clearly what is the scope of 
DPD and what is the scope of DPV.

2.3- Validation policies

- Concerning the default values that can be overridden : a
simplification would be that the server does not return an error but
behaves as it should :

We could add an attribute : are_default_values_overridable

then the server behavior could be :
If (is_default_values_overridable) then :
- conflicts must not lead to server error
- and SCVP server takes new values
If !(is_default_values_overridable) then :
- conflicts must not lead to server error
- and SCVP server takes default values

- Concerning validation policy parameters :

The parameter list should be extensible. For example, we could make use
of a parameter stating if the certificate to validate must be a CA
certificate, a Enduser certificate or any type of certificate, ...

2.4- Client versus server authority

The text addresses the case where the client does not trust the server
and has to receive all the information used by the server, even if the
server validates the certification path, in order to be able to decide
not to trust the answer and query again the same or another server.

In organisations that want to centralize their PKI policies, the
projects that need a SCVP server cannot have the choice to contest the
authoritative answer of the SCVP server. Checks and validation policies
are contractually defined between the client and the server and the
client has to accept the answer received. In this context, we need a
protocol that gives the server the right to refuse subsequent requests
(which means : "SCVP servers MAY support serverContextInfo" - instead of
"SHOULD")

3- serverContextInfo

I can't really understand the choice to implement this
"serverContextInfo" instead of letting the server send all the paths at
once. It means we have to keep context on the server for each query
(with all the subsequent questions : how long do we keep it ? do we need
to backup it for replay/verification purpose ?)

The text states that this value is used by the client if if finds the
response "unacceptable". What does "unacceptable mean" ? If it is
possible to define these "unacceptability criteria", they could be
implemented in the validation policy on the server, so that the server
gives the correct response at first query.

4- basic validation algorithm errors (3.2.4.2.2)

IIRC, the validation algorithm defined in section 6 of [PKIX-1] does not
contain any keyusage / revocation check. Thus, the
id-bvae-invalid-key-usage and id-bvae-revoked values are not used.

5- ValidationTime

I am afraid I missed the "clock skew" concept. IIUC, the idea of 
introducing clock skew aims to solve the delay between the moment where 
the user revokes his certificats and the moment where the system is 
aware that the certificate is indeed revoked.

How does the SCVP server behave with the "clock stew" concept ?

- If the server builds a response concerning the state the
certificate was in 10 mn before the query, it increases the risk that a 
certificate has been revoked in the meantime and that the SVCP server is 
not yet aware of the revocation.

- If the server builds a response concerning the state the
certificate will be in 10 mn after the query, the server has to wait 10 
mn before checking the certificate and sending the response to the client.

It seems to me that the solution is not clear enough in the text.

6- Some minor remarks

*** $3.2.2 : Sentence "For each check specified in the request, the SCVP 
server MUST perform all of the requested checks, or return an error".

please rewrite : "For each check specified in the request, the SCVP 
server MUST perform the requested check, or return an error".

*** id-swb-pkc-best-cert-path : we lack a definition of what is the 
"best" certification path and how the choice is made by the SCVP server.

*** §3 Validation request
Please state that a SCVP server MUST process a protected request.

*** §3.2.7 validationTime
typo : valididationTime -> validationTime

I hope this contribution will help.

Sincerely yours,
Nathalie Jolly
Project manager for the development of a certificate validation service
for the french government.

-- 
Nathalie Jolly - inet6
-------------------------------------------------------------------
   o            Siege social: 51, rue de Verdun - 92 158 Suresnes
  /     _ __ _  Bureaux: 33, rue Benoit Malon - 92150 Suresnes
/ /\  /_ / /_  France
\/  \/_ / /_/  Tel. +33 (0) 1 41 44 85 45
-------------- Fax  +33 (0) 1 46 97 20 10
i n e t s y s  http://www.inet6.fr

---

From: "David A. Cooper" <[email-masked]>
Date: Fri, 04 Mar 2005 18:10:00 -0500

Nathalie Jolly wrote:

> revocation status + building and validation of the certification 
> paths, depending of the chosen checks).
>
> I would suggest :
> - that you rewrite the abstract and introduction so that the purpose 
> of the document becomes clearer (SCVP includes DPD/DPV but also deals 
> with certificate content and revocation)

I do not understand. Certificate content validation and revocation 
status checking are part of certification path validation.

Where specifically in the text is there a need to distinguish between 
the DPD part and the DPV part?  Remember that SCVP is simply one 
protocol that can be used for both purposes.

> algorithm" (maybe not for the "checks"), and I totally agree with them.

The validation algorithm is already part of the validation policy.  As 
with other aspects of a validation policy, the validation policy defines 
a default value and may or may not allow the client to request the use 
of a non-default value.

As for combining the checks with the validation policy, this seems like 
a rather significant change at the last minute and it does not seem that 
the change is necessary nor have others requested such a change, so I 
have to assume that the working group is generally in favor of the 
current structure.

> the client will not understand why the server returns an error.

This is an issue that Sharon Boeyen raised as well.  If I understand 
correctly, she would like to have the option of returning additional 
checks items in the replyChecks field if additional checks were 
performed and one of those additional checks resulted in an error.  The 
replyChecks would still be required to include all of the checks item 
from the request, but would be allowed to include additional checks as 
well.  We will have to raise this issue at the meeting next week to see 
if the working group favors such a change.

> path at a given time). Thus, we need to state that the path building 
> is optional, if it has been done before and if the CA / validation 
> policy information have not been modified.

This is an implementation detail and not an aspect of the protocol.  In 
the protocol, it is clearly stated that cached responses may be allowed 
except when the client insists on a non-cached response.  I fully expect 
servers to cache certification paths for use in responding to future 
queries, but (other than when sending cached responses) the server's 
doing so should have no affect on the client's query or the server's 
response, just the efficiency with which the server generates the 
response, so it outside the scope of the standard.

> Therefore, we could have checks such as "id-stc-check-pkc-path" without

The client can not include a certification path in its request (only a 
set of certificates that the server may either use or ignore), so from 
the client's point-of-view the server must always build a certification 
path.  Just because the client's request includes a check asking the 
server to build a path does not mean that the server cannot simply 
return a previously cached path as long as the returned path satisfies 
the client's request.

> DPD and what is the scope of DPV.

SCVP already states which checks are required for DPD and which are 
required for DPV.  In draft 19, the text will state that only DPD 
servers are required to implement id-stc-build-pkc-path and only DPV 
servers are required to implement id-stc-build-valid-pkc-path and 
id-stc-build-status-checked-pkc-path.

> - and SCVP server takes default values

It is my understanding that this is not the general view of the working 
group.  There seems to be consensus that the server must either use the 
values specified by the client or return an error.  If the server 
indicates that a certificate is valid, but validated the certificate 
using different input values than those requested by the client, then 
the client may unknowingly accept a certificate that does not meet its 
requirements.

> certificate, a Enduser certificate or any type of certificate, ...

The parameters list is extensible.  If the validation is performed using 
a validation algorithm that accepts additional parameters, then those 
additional parameters may be specified along with the algorithm.  The 
name validation algorithm, for example, includes additional parameters.

At one point there was a field that allowed the client to specify that 
the certificate to be validated must be a CA certificate or an end 
entity certificate.  However, such a feature would have added 
substantial complexity, so the decision was made to remove it from the 
base standard with the understanding that this feature could always be 
added in the future (e.g., as a new validation algorithm, a new check 
item, an extension, etc.).

> (which means : "SCVP servers MAY support serverContextInfo" - instead of

In most cases, I would expect serverContextInfo to be used for DPD, 
where the certification path returned to the client may not satisfy the 
client's validation policy requirements.  The server may not validate 
the path it is returning to the client, but may know about more than one 
potentially acceptable certification paths.  If the first path does not 
meet the client's requirements and the server indicates that additional 
paths are available, this provides a method for the client to request 
another path.

serverContextInfo is less likely to be needed for DPV since the server 
is validating that it has found a certification path that satisfies the 
validation policy specified by the client.  But, I do not see a 
compelling reason to change "SHOULD" to "MAY".  "SHOULD" does not mean 
that a server that does not implement this is non-conformant.  Also, 
this "SHOULD" is referring to the implementation of the SCVP server 
(i.e., the code).  It says nothing about how a given SCVP server is 
configured, which is the issue that you are concerned about.

> to backup it for replay/verification purpose ?)

There is an id-swb-pkc-all-cert-paths wantBack, but this may not be the 
best option depending on how the server is implemented.  In many cases 
the first path returned by the server will be acceptable to the client.  
If the server had to return all paths, this would require extra 
bandwidth and may require extra processing to compute the paths.

The subsequent questions are implementation details.  It could be that 
the server will retain information about previous queries for which it 
returned a serverContextInfo, where the serverContextInfo could be an 
index into this store.  In this case, the server may store information 
about a limited number of previous queries while deleting information 
about old queries.  Alternatively, the server may return all the 
information needed in serverContextInfo so that it does not need to 
remember anything about previous queries.

> gives the correct response at first query.

As I said above, I believe this feature will mostly be used with DPD.  
In this case, the server may return certification paths without 
validating them first, so the server would not know whether the path it 
is returning satisfies the client's validation policy or not.

> id-bvae-invalid-key-usage and id-bvae-revoked values are not used.

The validation policy includes keyUsages, which specifies requirements 
if any for the end (or target) certificate.  If the certificate includes 
a keyUsage extension that does not satisfy the keyUsages requirement in 
the validation policy, then the id-bvae-invalid-key-usage is returned.

Revocation checking must be performed by the server if the client 
includes a check item that requires it.  Also, section 6 of RFC 3280 
does include revocation checking:

    6.1.3  Basic Certificate Processing

       The basic path processing actions to be performed for certificate i
       (for all i in [1..n]) are listed below.

          (a)  Verify the basic certificate information.  The certificate
          MUST satisfy each of the following:

             (3)  At the current time, the certificate is not revoked and is
             not on hold status.  This may be determined by obtaining the
             appropriate CRL (section 6.3), status information, or by out-
             of-band mechanisms.

> introducing clock skew aims to solve the delay between the moment 
> where the user revokes his certificats and the moment where the system 
> is aware that the certificate is indeed revoked.
>
> certificate was in 10 mn before the query, it increases the risk that 
> a certificate has been revoked in the meantime and that the SVCP 
> server is not yet aware of the revocation.
>
> certificate will be in 10 mn after the query, the server has to wait 
> 10 mn before checking the certificate and sending the response to the 
> client.

The server would never have to wait before sending the response.  
Section 3.2.7 states "A server can ignore the validationTime provided in 
the request if the time is within the clock skew of the server's current 
time." So, if the specified validationTime is the current time or less 
than 10 minutes in the past (assuming the default value), the server can 
just respond with the status at the current time.  If the specified 
validationTime is more than 10 minutes in the past, then validationTime 
+ 10 minutes is already in the past so the server would be able to 
respond immediately.

> *** $3.2.2 : Sentence "For each check specified in the request, the 
> SCVP server MUST perform all of the requested checks, or return an 
> error".
>

OK.

> "best" certification path and how the choice is made by the SCVP server.

This is just a name, not the description.  Besides, the path returned by 
the server is the one that it considers "best" given the specified 
validation policy.

> Please state that a SCVP server MUST process a protected request.

Section 4 states:

   For protected requests and responses, SCVP servers MUST support
   SignedData and SHOULD support AuthenticatedData.  It is a matter of
   local policy which types are used.

So processing protected requests is already required.

> typo : valididationTime -> validationTime

OK.

---

From: Nathalie Jolly <[email-masked]>
Date: Mon, 07 Mar 2005 14:59:57 +0100

Hello David,

Thanks for your answers. Please read my comments under your answers.

> status checking are part of certification path validation.

Certificate content validation and revocation status checking _may be_
part of certificate validation (it depends on the checks and validation
policy the client chooses to ask for). The abstract and introduction do
not highlight enough the fact that the SCVP protocol is modular. It
seems important that abstract and introduction define the most important
issues of the RFC.

> protocol that can be used for both purposes.

I agree it can be used for both purposes. I meant that, in the protocol
specification, some features are clearly dedicated to discovery, and
other to validation. This could be detailed along the text.

> a default value and may or may not allow the client to request the use 

When I wrote that the validation algorithm must be part of the
validation policy, I was thinking of the set of checks. The idea is that
the algorithm implements a check, and that when combining the checks,
you combine the linked algorithms.

> have to assume that the working group is generally in favor of the 

Yes, I know timing is an issue for the draft. Maybe it is just a
question of words choice. I would save the "validation policy" concept
for the general purpose of validation strategy for the organisation
implementing SCVP, even if we do not map it in the ASN.1 structure of
the protocol. As you certainly know, words are very important and will 
never change once the draft is a RFC, whereas changing a word _now_ is 
still easy.

> if the working group favors such a change.

I fully agree with her. I hope the working group will favor this suggestion.

OK.

> return a previously cached path as long as the returned path satisfies 

OK. In my opinion, this deserves to be written down explicitly in the RFC.

> id-stc-build-status-checked-pkc-path.

OK, good idea.

> the client may unknowingly accept a certificate that does not meet its 

This raises the point I already talked about, "client versus server
authority". In organisations where the need is to centralize the
validation service, the validation authority is responsible for its
answers and cannot accept the modification of parameters. The need is to
validate certificates, not to return error values...

> name validation algorithm, for example, includes additional parameters.

What I meant is that the additional parameters should be located in the
validation policy and not in the validation algorithm. They are
parameters, like "inhibitPolicyMappings" or any other that you specified
in "validationPolicy" and are used by a validation algorithm.

> item, an extension, etc.).

OK. This feature is a good example. It adds :
- a new check : the check for certificate type
- an extention to the validation policy : the expected value
- a new algorithm : an algorithm that is able to make the check,
whatever the expected value
The expected value (isCACert or isEndUserCert) is part of the validation
policy.
The algorithm is "expected-value independent".

OK.

> is returning satisfies the client's validation policy or not.

OK. When I wrote that the text did not detail precisely enough what was
designed for DPD and what was designed for DPV, this is a good example
of questions that would deserve to be clarified.

> the validation policy, then the id-bvae-invalid-key-usage is returned.

No. I re-read RFC 3280 chapter 6 and did not read anything concerning
keyUsage in the algorithm, except about keyCertSign value.

>             appropriate CRL (section 6.3), status information, or by out-

OK. My mistake.

> + 10 minutes is already in the past so the server would be able to 

This is now very very clear and correct. Could you rephrase the draft text ?

>> typo : valididationTime -> validationTime

Best regards,
Nathalie Jolly.