Seth,
I think that CertChecks should remain a SEQUENCE. While I don't
believe that a query should include more than one of the currently
defined check OIDs, new checks may be defined in the future which could
be used in combination.
Dave
Seth Hitchings wrote:
If the changes that David
recommends are accepted (which I believe they should be), then is there
any reason for CertChecks to be a sequence of check OIDs? Validation
implies path construction, and status checking implies validation. When
would a client send more than one check?
Seth
Trevor,
There seems to be a misunderstanding here. The check in question is:
Do revocation status checks on the certification path
In your response to Denis below, you say:
If the client has asked for revocation information, I
don't see a full path build for the client certificate is required. You
may build a path for the CA certificate which signed the CRL, but that
is different.
There is a disconnect between these two statements. The check requires
the server to perform status checks on the path. In your
response, you refer to the CRL. If the check only required to
server to perform a status check on the end certificate (i.e., the
certificate presented in the request), then your comment would make
sense. However, the check requires the server to perform status checks
on the path. Since SCVP does not allow the client to present a
path to the server, the server MUST build a certification path
in order to perform the id-stc-build-status-checked-pkc-path check,
otherwise the server would not have a certification path for which to
perform status checks.
You suggest that the id-stc-build-status-checked-pkc-path check might
be used by itself in a case in which a DPD client has already been able
to build a path. But this does not work, since the server may not
provide status checks on the same certification path as the one
constructed by the client (or the one that the client had previously
obtained from the SCVP server). The client could increase the chances
that the server would use the path that it was interested in by
providing the certificates in the path through the intermediateCerts
field, but this would not guarantee that the server would provide
status checks for this path.
As I said in my previous message, if the client wants to server to
provide status checks for the certificates in a particular
certification path, then the client should use OCSP. OCSP allows the
client to ask for status information for a specific set of
certificates, SCVP does not. With SCVP, the client can only specify
the trust anchor and the end certificate; the server MUST build the
remainder of the certification path. So, even if the client only
includes the id-stc-build-status-checked-pkc-path check, there is an
implicit requirement for the server to build a certification path. I
believe that it makes no sense for the server to perform the
id-stc-build-status-checked-pkc-path check on an unvalidated
certification path. That is, I believe that the only sensible use of
this feature is for the server to build a validated certification path
and then perform status checks on that path; there is no benefit to
performing status checks on an unvalidated certification path. Given
this, it makes sense to explicitly indicate that the
id-stc-build-status-checked-pkc-path check requires the server to build
a validated certification path and do revocation status checks on that
certification path.
Dave
Trevor Freeman wrote:
* -----Original Message-----
* From: Denis Pinkas [mailto:Denis.Pinkas@xxxxxxxx]
* Sent: Monday, December 13, 2004 12:35 AM
* To: Trevor Freeman
* Cc: David A. Cooper; ietf-pkix@xxxxxxx
* Subject: Re: SCVP 16 comments deadline
*
* Trevor,
*
* > David,
* > No wanting to rathole on this sine time is short, the section of the
* > document in question which Denis referred to is dealing with the set of
* > request that the client can make to the server. We agree that the client
* > can ask for path construction without revocation checking.
*
* Up to here we agree.
[TF] Good
*
* > I think it
* > legitimate a DPD client could ask for revocation checking because it has
* > already be able to build a path. Conceivably a DPV client could do the
* > same because it pervious asked for the path to be constructed and just
* > wants the revocation data refreshed.
*
* Here we do not agree. If a client has already been able to build a path,
* then he provides that path as "useful certificates" and the DPV server will
* necessarily build the path (using or not using these "useful certificates")
* and verify it.
*
* So if revocation checking is asked for by the client, this necessarily
* mandates path construction.
[TF] what there server does to process the request is orthogonal to the
section in question. If the client has asked for revocation
information, I don't see a full path build for the client certificate is
required. You may build a path for the CA certificate which signed the
CRL, but that is different.
*
* Denis
*
*
* > However to get to the bottom line, is there a specific problem with the
* > text in section 3.1.2
* > Trevor
* >
* > * -----Original Message-----
* > * From: David A. Cooper [mailto:david.cooper@xxxxxxxx]
* > * Sent: Thursday, December 09, 2004 2:22 PM
* > * To: Trevor Freeman
* > * Cc: ietf-pkix@xxxxxxx
* > * Subject: Re: SCVP 16 comments deadline
* > *
* > * Trevor,
* > *
* > * I must say that I agree with Seth and Denis. I was under the impression
* > * that "Do revocation status checking on the certification path" really
* > * meant "build and validated certification path to a trust anchor and do
* > * revocation status checking on the certification path". While I can see
* > * that there may be circumstances in which one would request a validated
* > * certification path without requiring revocation status checking, I can't
* > * see requesting revocation status checking without requesting that the
* > * path be validated.
* > *
* > * It is certainly the case that one can not "do revocation status checking
* > * on the certification path" without also building a certification path.
* > * Since the client can not provide a certification path, revocation status
* > * checking must be performed on a path that is built by the server. I
* > * suppose you could argue that this simply means that a well formed query
* > * can not include the id-stc-build-status-checked-pkc-path without also
* > * including either the id-stc-build-pkc-path or
* > * id-stc-build-valid-pkc-path check. But, I see see the need for this.
* > *
* > * A DPD client would include the id-stc-build-pkc-path along with the
* > * id-swb-pkc-best-cert-path and/or id-swb-pkc-revocation-info wantBacks.
* > * If the DPD client included the id-swb-pkc-revocation-info wantBack, it
* > * wouldn't need to also include the id-stc-build-status-checked-pkc-path
* > * check. If the DPD client did not include the id-swb-pkc-revocation-info
* > * wantBack, then would not include the id-stc-build-status-checked-pkc-path check.
* > *
* > * So, I would argue that the id-swb-pkc-revocation-info wantBack would
* > * only be used in the case that the client was requesting a validated
* > * certification path. The way that I had interpreted the currently
* > * defined checks items, an SCVP query would only include one check since
* > * each successive check included the requirements of the previous one:
* > * id-stc-build-valid-pkc-path included the requirement to build a path
* > * (id-stc-build-pkc-path) and id-stc-build-status-checked-pkc-path
* > * included the requirement to build a validated path
* > * (id-stc-build-valid-pkc-path).
* > *
* > * Under what circumstances can you envision a client wanting the server to
* > * do revocation status checking on a certification path (that is
* > * constructed by the server) without also including a requirement that the
* > * certification path be validated? If there are no reasonable
* > * circumstances in which a client would make such a query, why is it
* > * necessary for clients to be able to construct such a query?
* > *
* > * Dave
* > *
* > * Trevor Freeman wrote:
* > *
* > * >Hi Seth,
* > * >A server can always go beyond what the client asked for. I don't see
* > * >that as strictly necessary in all cases such as if the client just asks
* > * >for revocation. Untimely is a matter of local server policy. What the
* > * >server cannot do is return status or errors relating to the other
* > * >activities which were beyond the request scope.
* > * >Trevor
* > * >
* > * While it might make sense for a client to only ask for revocation
* > * checking if the client could specify the certification path, it does not
* > * seem to make sense given that the server chooses the certification path
* > * for which revocation status checking will be performed. If the client
* > * wants to specify a set of certificates for which it only wants to know
* > * the revocation status, that is what OCSP is for.
* > *
* > * >
* > * >* -----Original Message-----
* > * >* From: Seth Hitchings [mailto:shitchings@xxxxxxxxxxxxxx]
* > * >* Sent: Wednesday, December 08, 2004 11:34 AM
* > * >* To: Trevor Freeman
* > * >* Cc: ietf-pkix@xxxxxxx
* > * >* Subject: RE: SCVP 16 comments deadline
* > * >*
* > * >* Trevor,
* > * >*
* > * >* For clarification, I assume that doing revocation status checks on a path
* > * >* implies building a validated path?
* > * >*
* > * >* If I am correct, in what case would a client ever send more than one check?
* > * >*
* > * >* Seth
* > * >*
* > * >* -----Original Message-----
* > * >* From: owner-ietf-pkix@xxxxxxxxxxxx
* > * >[mailto:owner-ietf-pkix@xxxxxxxxxxxx]
* > * >* On Behalf Of
* > * >* Trevor Freeman
* > * >* Sent: Wednesday, December 08, 2004 1:42 PM
* > * >* To: Denis Pinkas
* > * >* Cc: ietf-pkix@xxxxxxx
* > * >* Subject: RE: SCVP 16 comments deadline
* > * >*
* > * >*
* > * >* Denis,
* > * >* I know of several systems who's policy is never to revoke the identity certificate because
* > * >* they have other mechanisms to address the issue.
* > * >* They are using authorization bound to the identity and they either rely on short lived
* > * >* authorization assertions or revoke the authorization privilege assonated with the
* > * >* identity. Therefore in those cases not checking the revocation status of the certificate
* > * >* makes perfect sense.
* > * >* Trevor
* > * >*
* > * >* * -----Original Message-----
* > * >* * From: owner-ietf-pkix@xxxxxxxxxxxx
* > * >* [mailto:owner-ietf-pkix@xxxxxxxxxxxx]
* > * >* * On Behalf Of Denis Pinkas
* > * >* * Sent: Wednesday, December 08, 2004 8:01 AM
* > * >* * To: Trevor Freeman
* > * >* * Cc: ietf-pkix@xxxxxxx
* > * >* * Subject: Re: SCVP 16 comments deadline
* > * >* *
* > * >* *
* > * >* * Trevor,
* > * >* *
* > * >* * > Hi Denis,
* > * >* * > Below are responses to 1-16. Others will follow later.
* > * >* *
* > * >* * I am pleased that you accepted comments 13, 14, 15 and 16.
* > * >* * Among this list, I have a further remark on comment 4.
* > * >* *
* > * >* * > * 4. Page 13. Typo. Section 3.1.2 "checks"
* > * >* * > * The two following lines are in fact one line:
* > * >* * > *
* > * >* * > * Change:
* > * >* * > *
* > * >* * > * - Build a validated certification path to a trust anchor; and
* > * >* * > *
* > * >* * > * - Do revocation status checks on the certification path.
* > * >* * > *
* > * >* * > * into:
* > * >* * > *
* > * >* * > * - Build a validated certification path to a trust anchor and
* > * >* * > * do revocation status checks on the certification path.
* > * >* * > *
* > * >* * > [TF] Since this paragraph is listing the possible checks and building a
* > * >* * > path is a separate check to revocation checking, I think the current
* > * >* * > text is more accurate.
* > * >* *
* > * >* * I agree that "building a path is a separate check to revocation checking",
* > * >* * but revocation checking without building a validated path does not make sense.
* > * >* *
* > * >* * The full text currently is:
* > * >* *
* > * >* * - Build a certification path to a trust anchor;
* > * >* *
* > * >* * - Build a validated certification path to a trust anchor; and
* > * >* *
* > * >* * - Do revocation status checks on the certification path.
* > * >* *
* > * >* * The full text should be:
* > * >* *
* > * >* * - Build a certification path to a trust anchor;
* > * >* *
* > * >* * - Build a validated certification path to a trust anchor; and
* > * >* * do revocation status checks on the certification path.
* > * >* *
* > * >* * Denis
|