Subject: RE: PKIX WG Agenda for 60th IETF (second try!)

From: "Trevor Freeman" <[email-masked]>
Date: Tue, 3 Aug 2004 23:46:38 -0700

Hi Peter,
Sorry I missed this but as Tim said, I am on vacation and not attending
San Diego so have not been reading every posting. If you had also sent
this mail to me personally you would have at least found out I am on
vacation. Dennis changed the subject line to include SCVP which caught
my attention and since I did not find another posting with the same
subject I wrongly assumed he had forwarded a private mail to the list.
My apologies. 

I will therefore repost my comments directly to you.

Trevor
* -----Original Message-----
* From: [email-masked]
[mailto:[email-masked]]
* On Behalf Of Peter Sylvester
* Sent: Wednesday, July 28, 2004 5:33 AM
* To: [email-masked]
* Cc: [email-masked]
* Subject: Re: PKIX WG Agenda for 60th IETF (second try!)
* 
* 
* 
* it seems to me that some of the results of discussions between
* the editor and me have been forgotten or so.
* 
* 
* I still think that the scvp is not conformant to RFC 3379
* and/or the editors has not done something as announced.
* 
* 1) RFC 3379 says:
*    The DPV request MUST allow the client to request that the server
*    include in its response additional information which will allow
*    relying parties not trusting the DPV server to be confident that
the
*    certificate validation has correctly been performed.  Such
*    information may (not necessarily exclusively) consist of a
*    certification path, revocation status information from authorized
CRL
*    issuers or authorized OCSP responders, revocation status
information
*    from CRL issuers or OCSP responders trusted under the validation
*    policy, time-stamp tokens from TSAs responders trusted under the
*    validation policy, or a DPV response from a DPV server that is
*                       XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
* 
*    trusted under the validation policy.  When the certificate is valid
*    according to the validation policy, the server MUST, upon request,
*    include that information in the response.  However, the server MAY
*    omit that information when the certificate is invalid or when it
*    cannot determine the validity.
* 
*    ==> no provision (as far as I see).

[TF] Given that SCVP requires the server ensure that the validation
policy has been complied with and permits all the parameters for the
currently defined validation algorithms to be returned ( full
certificate path, CRLs, OCSP responses) then I consider SCVP to be fully
compliant with 3379. There are no currently defined validation
algorithms which have a TSA response or a DPV response from another SCVP
server as an input, however if such as algorithm were to be defined,
then the extension mechanisms within SCVP would permit TSA responses or
DPV responses to be also returned. 

Also which discussing the client requesting the validation information
by value in section 3.2.5 states

"include by value in the CVResponse  every aspect of the validation
policy"

* 
* 
* 2) RFC 3379 says:
*    When the DPV request is authenticated, the client SHOULD be able to
*    include a client identifier in the request for the DPV server to
copy
*    into the response.  Mechanisms for matching this identifier with
the
*    authenticated identity depends on local DPV server conditions
and/or
*    the validation policy.  The DPV server MAY choose to blindly copy
the
*    identifier, omit the identifier, or return an error response.
* 
* The current text is SCVP says:
* 
*   The OPTIONAL requestor item is used to identify the requestor.  The
*   value is only of local significance to the requestor.  If the SCVP
*   client includes a requestor value in the request, then the SCVP
*   server MUST return the same value if the server is generating a
*   specific response.
* 
* 
* tf also said:
* 
* > Given there are plenty of ways a client can generate a "unique" as
well
* > as other behaviors like it can encode a DN in the octet sting if it
* > likes I don't see a problem. Its down to the client to do what it
thinks
* > fit. The value is simply replayed by the server so it is treated a
* > binary blob.
* 
[TF] Since you had not linked our discussion on the requestor field to
this section of 3379 before we have been at cross purposes. As Dennis
pointed out this field is intended for SCVP relay so the current text is
accurate for that purpose. It's a opaque blob to the server so
definition of any standard structures in this case was and is a
pointless exercise.

It is also not appropriate to reuse the requestor field because of the
case of authenticated relay. Since the client signed the request with a
certificate in this case, the request complies with 3379. We just need
to add a GeneralName field in the response for this purpose. Though
remember that with cached responses this will not be possible.

.
* There is nothing else possible for the server except copying, or,
* no mechanisms to match this with the some authenticated entity
* can be safely developped if it is solely 'up to the client to encode
* whatever'.
* 
* I had proposed two changes to the logic of 0 terminated octet strings
by:
* 
* - a sequence of octet strings allowing a real opaque string.
* - a choice of generalname
* 
* I.e.
* 
*    Identifiers ::= SEQUENCE OF {
*           CHOICE {
*                opaqueId OCTET STRING,
*                nameId GeneralName
*           }
* 
* No comment to this proposition as far as I remember.
* 
* 3) In May 204 trevor wrote:
* 
* > I think we can use the Cert sign bit in key usage so the is CA bit
can
* > be removed from SCVP15
* 
* which was not done.

[TF] Yes I reconsidered that position. Since the 3280 path validation
algorithm uses the basic constrains extension as it's test for CA
certificates (3280, 6.1.4, k) and that algorithm is a mandatory feature
for every SCVP validation algorithm, I concluded it was safer to use the
same test rather than risk another based on key usage.

* 
* 4) Somewhat related to this, and to the provisions to search in DPD or
* validate
*    in DPV several types of extensions, I had proposed to opetionally
* search
*    for the pathlength basicconstraint. if for example a client has a
*    cert and a CA cert then one could use it to search only for CAs
that
*    have at least a pathlength of 1.
* 
* 
* I seem to understand that the rule in this WG is:
* 
* - editor, chairmen, iesg says something ==> accepted if no response
* - others ==> rejected if no response from anyone.
* 
* all totally independant of the content of the comment.
* 
* At least point 3 doesn't fit into this rule.
* 
* I'd like to to see whether there is someone participating
* in this list who agrees with something or considers it as useful ...
* 
* Thanks for consideration
* Peter
* 
*

---

From: Peter Sylvester <[email-masked]>
Date: Wed, 11 Aug 2004 13:27:17 +0200 (MEST)

> DPV responses to be also returned. 

If you read the text above the XXX above I am not talking about TSAs.
There has been a lengthy discussion about this requirement years ago
with at least some understaning that a DPV server can operate in a similar
way as an OCSP server, thus returning DPV server responses have the
similar functionality. 

I suggest to return a CMS contenttype as one of the possible return values.

---

From: Peter Sylvester <[email-masked]>
Date: Wed, 11 Aug 2004 13:27:09 +0200 (MEST)

> same test rather than risk another based on key usage.

The boolean isCA does not indicate at all how the server determines
whether a cert is a CA cert. You may consider to at least reference 
what the server is supposed to perform as a test.  

Since you returned to you original definition, please respond to
my repeated suggestion to use an integer representing a minimal value
for pathmenth in the basicconstraints instead of a boolean.

---

From: "Trevor Freeman" <[email-masked]>
Date: Wed, 11 Aug 2004 09:18:11 -0700

Hi Peter,

RFC3280, section 6.1.6 item k states

"Verify that the certificate is a CA certificate (as specified in a
basicConstraints extension or as verified out-of-band)."

Therefore the server does use the Boolean in the basic constraints
extension to determine if the certificate is a CA or not. Therefore use
of a Boolean with SCVP is in alignment with 3280.

I would be happy to add an OID to allow a DPD client to request all
paths be returned so a DPD client can make more granular choices along
the lines you discuss.

Trevor

* -----Original Message-----
* From: Peter Sylvester [mailto:[email-masked]]
* Sent: Wednesday, August 11, 2004 4:27 AM
* To: [email-masked]; Trevor Freeman
* Cc: [email-masked]
* Subject: RE: PKIX WG Agenda for 60th IETF (second try!)
* 
* > * 3) In May 204 trevor wrote:
* > *
* > * > I think we can use the Cert sign bit in key usage so the is CA
bit
* > can
* > * > be removed from SCVP15
* > *
* > * which was not done.
* >
* >
* > [TF] Yes I reconsidered that position. Since the 3280 path
validation
* > algorithm uses the basic constrains extension as it's test for CA
* > certificates (3280, 6.1.4, k) and that algorithm is a mandatory
feature
* > for every SCVP validation algorithm, I concluded it was safer to use
the
* > same test rather than risk another based on key usage.
* >
* 
* The boolean isCA does not indicate at all how the server determines
* whether a cert is a CA cert. You may consider to at least reference
* what the server is supposed to perform as a test.
* 
* Since you returned to you original definition, please respond to
* my repeated suggestion to use an integer representing a minimal value
* for pathmenth in the basicconstraints instead of a boolean.
* 
* 
* > *
* > * 4) Somewhat related to this, and to the provisions to search in
DPD or
* > * validate
* > *    in DPV several types of extensions, I had proposed to
opetionally
* > * search
* > *    for the pathlength basicconstraint. if for example a client has
a
* > *    cert and a CA cert then one could use it to search only for CAs
* > that
* > *    have at least a pathlength of 1.
* > *
* >

---

From: "Trevor Freeman" <[email-masked]>
Date: Wed, 11 Aug 2004 09:25:20 -0700

Hi Peter,
The TSA and DPVs responses are both in the paragraph you refer to and
both are outside the bounds of the validation algorithms defined today
so do not constitute information useful to a relying party. So I think
SCVP 15 conforms to RFC3379.  Wherever you define the algorithm that
does use such values as part of the validation process you can also
define how to return them in the response. The SVP response is
extensible so I am confident you can do that.

Trevor

* -----Original Message-----
* From: Peter Sylvester [mailto:[email-masked]]
* Sent: Wednesday, August 11, 2004 4:27 AM
* To: [email-masked]; Trevor Freeman
* Cc: [email-masked]
* Subject: RE: PKIX WG Agenda for 60th IETF (second try!)
* 
* > * 1) RFC 3379 says:
* > *    The DPV request MUST allow the client to request that the
server
* > *    include in its response additional information which will allow
* > *    relying parties not trusting the DPV server to be confident
that
* > the
* > *    certificate validation has correctly been performed.  Such
* > *    information may (not necessarily exclusively) consist of a
* > *    certification path, revocation status information from
authorized
* > CRL
* > *    issuers or authorized OCSP responders, revocation status
* > information
* > *    from CRL issuers or OCSP responders trusted under the
validation
* > *    policy, time-stamp tokens from TSAs responders trusted under
the
* > *    validation policy, or a DPV response from a DPV server that is
* > *                       XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
* > *
* > *    trusted under the validation policy.  When the certificate is
valid
* > *    according to the validation policy, the server MUST, upon
request,
* > *    include that information in the response.  However, the server
MAY
* > *    omit that information when the certificate is invalid or when
it
* > *    cannot determine the validity.
* > *
* > *    ==> no provision (as far as I see).
* >
* > [TF] Given that SCVP requires the server ensure that the validation
* > policy has been complied with and permits all the parameters for the
* > currently defined validation algorithms to be returned ( full
* > certificate path, CRLs, OCSP responses) then I consider SCVP to be
fully
* > compliant with 3379. There are no currently defined validation
* > algorithms which have a TSA response or a DPV response from another
SCVP
* > server as an input, however if such as algorithm were to be defined,
* > then the extension mechanisms within SCVP would permit TSA responses
or
* > DPV responses to be also returned.
* >
* 
* If you read the text above the XXX above I am not talking about TSAs.
* There has been a lengthy discussion about this requirement years ago
* with at least some understaning that a DPV server can operate in a
similar
* way as an OCSP server, thus returning DPV server responses have the
* similar functionality.
* 
* I suggest to return a CMS contenttype as one of the possible return
* values.
* 
* > Also which discussing the client requesting the validation
information
* > by value in section 3.2.5 states
* >
* > "include by value in the CVResponse  every aspect of the validation
* > policy"
* >
* >

---

From: Peter Sylvester <[email-masked]>
Date: Wed, 11 Aug 2004 18:50:32 +0200 (MEST)

> extensible so I am confident you can do that.

The scenario is a local DPV server operating as a locally trusted
interface like in OCSP. The DPV server has the knoweldge about
which other DPV servers are to be contacted to validate the cert
in question. 

The DPV relay thus simply asks the external service (operated closely
to a CA for example), and then simply confirms the result by
telling its client that the cert is good 'because the other DPV told it',
and it includes the original DPV response.

This behaviour is IMO an essential feature for the different types
of relaying. 

it is not up to me to define these things: SCVP needs to support them
to conform wityh 3379. That's why I propose simply to add a text
with a response value containing a CMS content-type. I do not think
that this should require another document.

---

From: Peter Sylvester <[email-masked]>
Date: Wed, 11 Aug 2004 19:02:05 +0200 (MEST)

> RFC3280, section 6.1.6 item k states
you mean 6.1.4 I guess.

> of a Boolean with SCVP is in alignment with 3280.

To which value do you intialize max_path_length of point k in 6.1.2
if you want to validate a CA cert that is used to signed another CA?

---

From: "Trevor Freeman" <[email-masked]>
Date: Wed, 11 Aug 2004 10:13:10 -0700

* -----Original Message-----
* From: Peter Sylvester [mailto:[email-masked]]
* Sent: Wednesday, August 11, 2004 10:02 AM
* To: [email-masked]; Trevor Freeman
* Cc: [email-masked]
* Subject: RE: PKIX WG Agenda for 60th IETF (second try!)
* 
* >
* > RFC3280, section 6.1.6 item k states
* >
* you mean 6.1.4 I guess.
* 
* > "Verify that the certificate is a CA certificate (as specified in a
* > basicConstraints extension or as verified out-of-band)."
* >
* > Therefore the server does use the Boolean in the basic constraints
* > extension to determine if the certificate is a CA or not. Therefore
use
* > of a Boolean with SCVP is in alignment with 3280.
* 
* To which value do you intialize max_path_length of point k in 6.1.2
* if you want to validate a CA cert that is used to signed another CA?
* 
[TF] SCVP supports all the inputs as defined in 6.1.1

---

From: Peter Sylvester <[email-masked]>
Date: Wed, 11 Aug 2004 19:24:15 +0200 (MEST)

> [TF] SCVP supports all the inputs as defined in 6.1.1

Are you saying that 3280 is broken? 

My question is whether you can you validate a CA certificate
of a partial path where you alreaduy know that you have a subCA.

---

From: "Trevor Freeman" <[email-masked]>
Date: Wed, 11 Aug 2004 10:36:14 -0700

* -----Original Message-----
* From: Peter Sylvester [mailto:[email-masked]]
* Sent: Wednesday, August 11, 2004 10:24 AM
* To: [email-masked]; Trevor Freeman
* Cc: [email-masked]
* Subject: RE: PKIX WG Agenda for 60th IETF (second try!)
* 
* > * To which value do you intialize max_path_length of point k in
6.1.2
* > * if you want to validate a CA cert that is used to signed another
CA?
* > *
* > [TF] SCVP supports all the inputs as defined in 6.1.1
* >
* 
* Are you saying that 3280 is broken?
[TF] no
* 
* My question is whether you can you validate a CA certificate
* of a partial path where you alreaduy know that you have a subCA.
[TF] We support path validation from defined roots down.
*

---

From: "Trevor Freeman" <[email-masked]>
Date: Wed, 11 Aug 2004 13:58:26 -0700

Hi Peter,
I don't see any clause in 3379 that requires SCVP to support the
scenario you describe. In fact section 4.2 states "Protocols designed to
satisfy these requirements MAY include optional fields and/or extensions
to support relaying, re-direction or multicasting."

Therefore SCVP meets the 3379 requirements. The scenario you describe
requires at a minimum the rely server to have a new validation algorithm
because as you describe  it is not verifying the result itself but
verifying the DPV response from another server. Therefore you are at
liberty to define such extensions.

Trevor

* -----Original Message-----
* From: Peter Sylvester [mailto:[email-masked]]
* Sent: Wednesday, August 11, 2004 9:51 AM
* To: [email-masked]; Trevor Freeman
* Cc: [email-masked]
* Subject: RE: PKIX WG Agenda for 60th IETF (second try!)
* 
* > Hi Peter,
* > The TSA and DPVs responses are both in the paragraph you refer to
and
* > both are outside the bounds of the validation algorithms defined
today
* > so do not constitute information useful to a relying party. So I
think
* > SCVP 15 conforms to RFC3379.  Wherever you define the algorithm that
* > does use such values as part of the validation process you can also
* > define how to return them in the response. The SVP response is
* > extensible so I am confident you can do that.
* 
* 
* The scenario is a local DPV server operating as a locally trusted
* interface like in OCSP. The DPV server has the knoweldge about
* which other DPV servers are to be contacted to validate the cert
* in question.
* 
* The DPV relay thus simply asks the external service (operated closely
* to a CA for example), and then simply confirms the result by
* telling its client that the cert is good 'because the other DPV told
it',
* and it includes the original DPV response.
* 
* This behaviour is IMO an essential feature for the different types
* of relaying.
* 
* it is not up to me to define these things: SCVP needs to support them
* to conform wityh 3379. That's why I propose simply to add a text
* with a response value containing a CMS content-type. I do not think
* that this should require another document.
* 
* 
* 
*

---

From: Peter Sylvester <[email-masked]>
Date: Fri, 13 Aug 2004 11:49:15 +0200 (MEST)

> to support relaying, re-direction or multicasting."

SCVP explicitely supports relaying.

The description of relaying in SCVP implies that the relaying
server obtains a response from a remote server, and has to interprete
it to provide a positive response, since the initial client does
not necessarily trust the remote server. 

> liberty to define such extensions.

There is no need for any extension. 

The relaying server creates a valid path and indicates *ALL* information
that it has used to determine this information. And since SCVP allows
for relaying, it must alow allow for returning the response from the
remote server as is, quite similar as for OCSP reponses etc.

---

From: Peter Sylvester <[email-masked]>
Date: Fri, 13 Aug 2004 13:29:38 +0200 (MEST)

> [TF] SCVP supports all the inputs as defined in 6.1.1

It seems that SCVP pretends to be able to valdidate *ANY* CA certificate
by using the isCA boolean which I think cannot work.

First, we are clearly outside the scope of the 
algorithm inputs of path validation algorithm of 3280, since the
algorithm works is intended to work for EEs:

   The primary goal of path validation is to verify the binding between
   a subject distinguished name or a subject alternative name and
   subject public key, as represented in the end entity certificate,

The algorithm still can work slightly modified if the EE cert is not
present, in order just to validate the first CA. 

But, in order to validate an intermediate CA that has not signed directly
the EE cert, one has to assume that the client has performed the 3280 validation
up to the CA in question, and one has to give correct information to the SCVP
server to do "the rest" or you have to return the intermediate values, 
i.e. the current maximum path length still allowed. 

Assume you want a valid path for CA2 signing CA1 and an EE cert
and you have a situation like

  EE <- CA1 <- CA2 <- CA3withpathlength0 <- CAX .. sometrustanchor
                   <- CA3withpathlength1 <- CAY .. othetrustanchor.

you cannot avoid that the SCVP server returns the first path
which would not be valid to sign EE with an intermediate CA1.

---

From: "Trevor Freeman" <[email-masked]>
Date: Fri, 13 Aug 2004 10:12:32 -0700

Hi Peter,
The question in point still comes back to how was the certificate
validated i.e. the algorithm and the parameters used by the server when
it returned the positive response. SCVP defines a default algorithm
where the server performs the path validation itself and provides an
extension mechanisms to define other algorithms. I don't see any
blocking issues to you defining a new validation algorithm which
encompasses DPV server delegating the validation decision to other DPV
server.
Trevor 

* -----Original Message-----
* From: Peter Sylvester [mailto:[email-masked]]
* Sent: Friday, August 13, 2004 2:49 AM
* To: [email-masked]; Trevor Freeman
* Cc: [email-masked]
* Subject: RE: PKIX WG Agenda for 60th IETF (second try!)
* 
* >
* > Hi Peter,
* > I don't see any clause in 3379 that requires SCVP to support the
* > scenario you describe. In fact section 4.2 states "Protocols
designed to
* > satisfy these requirements MAY include optional fields and/or
extensions
* > to support relaying, re-direction or multicasting."
* 
* SCVP explicitely supports relaying.
* 
* The description of relaying in SCVP implies that the relaying
* server obtains a response from a remote server, and has to interprete
* it to provide a positive response, since the initial client does
* not necessarily trust the remote server.
* 
* > Therefore SCVP meets the 3379 requirements. The scenario you
describe
* > requires at a minimum the rely server to have a new validation
algorithm
* > because as you describe  it is not verifying the result itself but
* > verifying the DPV response from another server. Therefore you are at
* > liberty to define such extensions.
* 
* There is no need for any extension.
* 
* The relaying server creates a valid path and indicates *ALL*
information
* that it has used to determine this information. And since SCVP allows
* for relaying, it must alow allow for returning the response from the
* remote server as is, quite similar as for OCSP reponses etc.
* 
* 
* 
*

---

From: "Trevor Freeman" <[email-masked]>
Date: Fri, 13 Aug 2004 10:14:52 -0700

Hi Peter,
The validation algorithm in 3280 section 6 works for all certificates.
Trevor

* -----Original Message-----
* From: Peter Sylvester [mailto:[email-masked]]
* Sent: Friday, August 13, 2004 4:30 AM
* To: [email-masked]; Trevor Freeman
* Cc: [email-masked]
* Subject: RE: PKIX WG Agenda for 60th IETF (second try!)
* 
* > *
* > * To which value do you intialize max_path_length of point k in
6.1.2
* > * if you want to validate a CA cert that is used to signed another
CA?
* > *
* > [TF] SCVP supports all the inputs as defined in 6.1.1
* 
* 
* It seems that SCVP pretends to be able to valdidate *ANY* CA
certificate
* by using the isCA boolean which I think cannot work.
* 
* First, we are clearly outside the scope of the
* algorithm inputs of path validation algorithm of 3280, since the
* algorithm works is intended to work for EEs:
* 
*    The primary goal of path validation is to verify the binding
between
*    a subject distinguished name or a subject alternative name and
*    subject public key, as represented in the end entity certificate,
* 
* The algorithm still can work slightly modified if the EE cert is not
* present, in order just to validate the first CA.
* 
* But, in order to validate an intermediate CA that has not signed
directly
* the EE cert, one has to assume that the client has performed the 3280
* validation
* up to the CA in question, and one has to give correct information to
the
* SCVP
* server to do "the rest" or you have to return the intermediate values,
* i.e. the current maximum path length still allowed.
* 
* Assume you want a valid path for CA2 signing CA1 and an EE cert
* and you have a situation like
* 
*   EE <- CA1 <- CA2 <- CA3withpathlength0 <- CAX .. sometrustanchor
*                    <- CA3withpathlength1 <- CAY .. othetrustanchor.
* 
* you cannot avoid that the SCVP server returns the first path
* which would not be valid to sign EE with an intermediate CA1.
* 
* 
* 
* 
* 
*

---

From: Peter Sylvester <[email-masked]>
Date: Sun, 15 Aug 2004 14:09:39 +0200 (MEST)

> encompasses DPV server delegating the validation decision to other DPV

I don't need to defined anything since it is already in SCVP.
SCVP explicitely says that it can use the response from another DPV server.

   In order to obtain the revocation status information of any
   certificate from the certification path, the DPV server might use, in
   accordance with the validation policy, different sources of
   revocation information.  For example, a combination of OCSP
   responses, CRLs, and delta CRLs could be used.  Alternatively, a
   response from another DPV server could be used.

And the requirements say that the server must be able to return all
information that is used to base its decision on.

---

From: Peter Sylvester <[email-masked]>
Date: Sun, 15 Aug 2004 13:52:16 +0200 (MEST)

> The validation algorithm in 3280 section 6 works for all certificates.

The algorithm is defined for EE-certs.

---

From: "Trevor Freeman" <[email-masked]>
Date: Mon, 16 Aug 2004 10:03:58 -0700

Hi Peter,
I cannot begin to understand why anyone would set an arbitrary length of
a path i.e. is good as long as there are only 3 CA certificates in the
path, however since you raised the point in conjunction to DPD requests,
then the simplest solution is to allow the client to request all paths.
Trevor

* -----Original Message-----
* From: Peter Sylvester [mailto:[email-masked]]
* Sent: Sunday, August 15, 2004 4:52 AM
* To: [email-masked]; Trevor Freeman
* Cc: [email-masked]
* Subject: RE: PKIX WG Agenda for 60th IETF (second try!)
* 
* > Hi Peter,
* > The validation algorithm in 3280 section 6 works for all
certificates.
* 
* The algorithm is defined for EE-certs.
* 
* > Trevor
* >
* 
* 
* You have not commented the following:
* 
* > *
* > * Assume you want a valid path for CA2 signing CA1 and an EE cert
* > * and you have a situation like
* > *
* > *   EE <- CA1 <- CA2 <- CA3withpathlength0 <- CAX .. sometrustanchor
* > *                    <- CA3withpathlength1 <- CAY ..
othetrustanchor.
* > *
* > * you cannot avoid that the SCVP server returns the first path
* > * which would not be valid to sign EE with an intermediate CA1.
* > *
* 
*

---

From: Peter Sylvester <[email-masked]>
Date: Wed, 18 Aug 2004 12:36:14 +0200 (MEST)

> then the simplest solution is to allow the client to request all paths.

you are insisting that I mentioned a use case for DPD, 
but my the question is for DPV as I said already.
In fact, DPD does not have a problem here, since you can implement
several paths, as you say (using the servercontext parameter).
(We havn't even started to handle policies).

I don't think that servercontext is intended for DPV. 

BTW: The example seems wrong to me, none of the paths is valid.
The CA3 certs are one too low. 

 EE <- CA1 <- CA2 <- CA3withpathlength1 <- CAX .. sometrustanchor
                  <- CA3withpathlength2 <- CAY ..

It seem that you finally admit that there is a problem, and now
you escape to a social argument. if someone thinks that the situation 
is technical non sense, please tell.   
IMO the PKI structure is conformant with the standards.

One may choose a solution to provide the path EE <- CA1 <- CA2
in some way, and ask for a valid path. 

or, one may restruct SCVP DPV processing for certain use cases
in order to ensure that the server can respond to a client. 

Peter

PS: you haven't yet answered to two other remarks.

---

From: Stephen Kent <[email-masked]>
Date: Wed, 18 Aug 2004 18:15:02 -0400

At 1:24 PM -0700 8/18/04, Trevor Freeman wrote:
>Hi Peter,
>I don't know if this is broken or not. I am applying a is "this a real
>or useful problem to solve filer check" before I proceed to problem
>analysis or solution. I have never found the path length as a valuable
>input into an validation criteria. However if there is consensus to
>solve this in the context of SCVP then I will spend some time on it.
>
>Trevor

Trevor,

First i want to thank you for all or your hard work in responding to 
feedback from the list re the latest version of SCVP.

I tend to agree with your observation above, i.e., although one can 
imagine imposing a cert path length limit on returned paths, I'd like 
to see some examples of why we think this is a useful control in 
general.

We do have a facility to do this via the basic constraints extension 
in a CA cert, but we know that this feature is hard to use unless one 
knows the structure of the PKI pointed to by a cross cert that 
incorporates this feature. As a result, I generally suggest not 
making use of this optional part of this extension. I've heard others 
make the same comment, e.g., Sharon Boyen. I realize that 3280 makes 
no comment about this feature, so we have not deprecated it, but ...

Steve