[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: SCVP 16 comments deadline

To: "Denis Pinkas" <Denis.Pinkas@xxxxxxxx>
Subject: RE: SCVP 16 comments deadline
From: "Trevor Freeman" <trevorf@xxxxxxxxxxxxxxxxxxxxxx>
Date: Mon, 13 Dec 2004 11:06:39 -0800
Cc: "David A. Cooper" <david.cooper@xxxxxxxx>, <ietf-pkix@xxxxxxx>
List-archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-id: <ietf-pkix.imc.org>
List-unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>
Sender: owner-ietf-pkix@xxxxxxxxxxxx
Thread-index: AcTg7qEAoqar6iReSGaUY49LQ/+Y5gAV2DCg
Thread-topic: SCVP 16 comments deadline


* -----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
* > * >*
* > * >
* > * >
* > * >
* > *
* >
* >
*
Follow-Ups:
- Re: SCVP 16 comments deadline
  - From: David A. Cooper
Prev by Date: RE: Proposed Changes to RFC 3280
Next by Date: I-D ACTION:draft-ietf-pkix-rfc2511bis-07.txt
Previous by thread: RE: SCVP 16 comments deadline
Next by thread: Re: SCVP 16 comments deadline
Index(es):
- Date
- Thread