Subject: RE: How a SCVP client authenticates the SCVP server?

From: Stephen Kent <[email-masked]>
Date: Fri, 12 Sep 2003 18:26:57 -0400

At 14:49 -0700 9/12/03, Trevor Freeman wrote:
>Hi Wen-Cheng,
>First off consider there are two classes of SCVP clients.
>* Simple clients who only originate SCVP request and
>* SCVP servers who can both service requests and originate their own
>requests to other SCVP servers(relay).
>
>The validation requirements are quite different between the two. For
>simple clients the trust mechanism cannot rely on any form of
>certificate validation, but will be achieved by out-of-band
>configuration of the SCVP server's public signing\authentication key or
>a symmetric shared key. For SCVP server making request of other SCVP
>servers, then chain validation is legitimate option since the discovery
>and use model is quite different as are the constraints - or relative
>lack of them- on the servers capabilities. Beyond having certificates
>conformant to 3280 and having a specific key purpose, I don't think we
>need to be more prescriptive.

Trevor,

You are right that there are two different client types here, which 
suggest to me that we may need two different characterizations of 
what these distinct client types need to support re SCVP server 
validation, and we should further distinguish between DPD and DPV 
use, since the security implications are very different.

Steve

---

From: Wen-Cheng Wang <[email-masked]>
Date: Sat, 13 Sep 2003 10:34:43 +0800 (CST)

Hi, Trevor,

It seems that you are trying to tell us:

1. For simple clients, they must authenticate the SCVP server
   in the fashion of either mode 1 or mode 2 I metntioned.
2. For SCVP servers who act as a SCVP client (a SCVP relay),
   they can authenticate the SCVP server in the fashion of mode 3
   I mentioned.

Is my interpretation correct?

If so, don't you think the text of the current SCVP ID need to be
changed to support mode 1?

Best Reagrds,
Wen-Cheng

Trevor Freeman wrote:
> Trevor
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Wen-Cheng Wang
> Sent: Friday, September 12, 2003 5:00 AM
> To: [email-masked]
> Subject: How a SCVP client authenticates the SCVP server?
> Folks,
> After the past [SCVP-AIA] discussions and reviewing
> the current SCVP ID, I feel that it seems to be
> unclear that how a SCVP client validates the
> signature on the SCVP response signed by the SCVP
> server. Since this topic is not directly related to
> SCVP-AIA, I would like to discuss it in another thread
> and hope to get some feedbacks from this WG. Especailly,
> I hope the editors of SCVP ID can tell us what is
> in their mind when designing the protocol and the
> message format.
> When asked how a SCVP client validates the signature
> on the SCVP response, I believe that the most intuitive
> answer will be "Use the public-key of the SCVP server
> to verify the signature." However, the truth is that
> things might not be as simple as they are looked like.
> Before a SCVP client using the public-key of the SCVP
> server, the client MUST make sure the public-key is
> trustworthy. The question how can the client trust the
> public-key of the SCVP server? During the [SCVP-AIA]
> discussions, at least three possibilities are mentioned:
> 1. The SCVP server first delivered its own public-key to SCVP
>    clients via an out-of-band trusted channel. A SCVP client
>    must securely stored the public-key of the SCVP server in its
>    local environment in advance and then it can use the public-key
>    to verify the signature of the SCVP server.
> In this mode, the SCVP server need not to have its own
> certificate and of course does not need to include its own
> certificate in the certificates field within the signed SCVP
> response (i.e., a CMS SignedData). (Note: the current SCVP ID
> does not allow this mode because it says "The SCVP server MUST
> include its own certificate in the certificates field within
> SignedData" in its section 4.
> Note that, in this mode, the public-key of the SCVP server
> must be delivered to SCVP clients via an out-of-band
> trusted channel. (Similar to the way to deliver root key to
> relying parties.)
> There is one issue need to be discussed for this mode. Since
> the SCVP server does not have its own certificate, how can it
> identify itself in the signed SCVP response? Because the signed
> response is actually a CMS SignedData, the SCVP server must
> try to identify itself by using a SignerIdentifier structure,
> which is
>   SignerIdentifier ::= CHOICE {
>           issuerAndSerialNumber IssuerAndSerialNumber,
>           subjectKeyIdentifier [0] SubjectKeyIdentifier }
> IMO, the SubjectKeyIdentifier field might be the only choice
> since IssuerAndSerialNumber makes no sense in this case. The
> problem is there is currently no unique way for generating
> Key Identifier. For example, if the server side calculates
> its own key identifier as 160-bit SHA-1 hash value of its
> public-key while the client side uses 0100 + the least
> significant 60 bits of the SHA-1 hash value, there will be
> an interoperability problem.
> Therefore, if the SCVP is going to support this mode, the protocol
> might need to define an unique way for generating key identifier.
> (At least, within the scope of SCVP.)
> 2. The SCVP server first signed itw own certificate (i.e., a
>    self-signed certificate) and delivered the self-signed certificate
>    to SCVP clients via an out-of-band trusted channel. A SCVP client
>    must securely stored the self-signed certificate of the SCVP server
>    in its local environment in advance and it can use the public-key
>    in the self-signed certificate of the SCVP server to verify
>    the signature of the SCVP server.
> Note that, as the same reason why a self-signed certificate of a
> root CA must be deliverd to relying parties via an out-of-band
> trusted channel, the self-signed certificate of the SCVP server
> must be delivered to SCVP clients via an out-of-band trusted
> channel. Also, a SCVP client must securely stores the self-signed
> certificate of the SCVP server in its local environment and then
> use the public-key within the certificate to verify the signature
> of the SCVP server.
> My opinion is mode 2 is actually equal to mode 1 except that
> the OCSP server can now identify itself by using either
> IssuerAndSerialNumber field or SubjectKeyIdentifier field
> in a SignerIdentifier structure and it burdens the SCVP server
> with the overhead of creating its own self-signed certificate.
> Personally, I am not in favor of mode 2 because I believe that
> a SCVP server is simply an EE from the viewpoint of the PKI and
> I doubt whether a self-signed EE certificate is a legal X.509
> certificate and I also doubt whether PKIX should encourge an EE
> to create its own self-signed certificate.
> 3. The SCVP server certificate should be signed by a CA. The SCVP
>    server can then include its own certificate in the signed SCVP
>    response. After receiving the signed response, a SCVP client
>    must validate the SCVP server certificate first to determine
>    whether it is a trusted SCVP server. And then the SCVP client
>    can use the public-key in the SCVP server certificate to verify
>    the signature of the SCVP server.
>    
> It seems that the procedure describe in mode 3 is very reasonable
> and straightforward. Believe me, it is not that simple. Please
> note that a SCVP client must validate the SCVP server certificate
> first after receiving the signed response and before can use the
> public-key in the SCVP server certificate to verify the signature
> of the SCVP server. That is sort of similar to ask an OCSP
> client to check the status of the OCSP server certificate before
> it can use the public-key in that certificate to verify the
> signature of the OCSP server. It is a chicken-and-egg problem.
> Let's think about why a RP (a certificate-using application) wants
> to delegate the job of certification path construction/validation
> to a SCVP Server. I believe that one possibile reason is the
> implementator of the certificate-using application is not capable
> of implementing the complex certification path
> construction/validation algorithm and therefore decide to delegate
> that job to a SCVP server because he/she heard of the SCVP is the
> savior of the certificate-using application implementator.
> Unfortunately, the application implementator will eventually find
> that he/she still need to implementing the complex certification
> path construction/validation algorithm because the SCVP client
> side must validate the SCVP server certificate first and that
> might invloves constructing a certification path from the SCVP
> server certificate to the RP's trust anchor and the validating
> the certification path. Therefore, I do not know how mode 3 works
> if every certificate-using application does not have its own
> certification path construction/validation module. Ironically, isn't
> the original idea of SCVP is to eliminate application implementators'
> burden for implementing the complex certification path
> construction/validation.
> I believe that mode 3 is what in the SCVP ID editors' minds when
> they design the protocol. Unfortunately, the current SCVP ID does
> not tell us how a SCVP client can authenticate the SCVP server.
> At least, the following issues should be discussed.
> 1. Who should sign the SCVP server certificate?
> 2. What is the format of the SCVP server certificate?
>    (Is there any special requirements for the format of
>     the SCVP server certificate? or is it just a normal EE
>     signing certificate?)
> 3. How a SCVP client can validate the SCVP server certificate
>    without its own certification path construction/validation
>    module?
> Can anyone clarify these issues?
> Best Regards,
> Wen-Cheng Wang

---

From: "Trevor Freeman" <[email-masked]>
Date: Fri, 12 Sep 2003 22:19:07 -0700

Hi Wen,
I would not make that strict interpretation. In all non error cases the
SCVP is signed. The signature is either a signed data signature using a
3280 cert or authenticated data MAC which may contain a 3280 cert.  I do
not see you mode 1 or 2 as fitting at description. Mode 3 is closer
except the simple client simply needs a key hash and to be able to parse
the cert to find the public key and do a comparison. The intent of the
MAC is to allow client the simplest of validations modes possible. 

Trevor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Wen-Cheng Wang
Sent: Friday, September 12, 2003 7:35 PM
To: Trevor Freeman
Cc: [email-masked]
Subject: RE: How a SCVP client authenticates the SCVP server?

Hi, Trevor,

Best Reagrds,
Wen-Cheng

---

From: Wen-Cheng Wang <[email-masked]>
Date: Sat, 13 Sep 2003 14:14:14 +0800 (CST)

Hi, Trevor,

Do you mean that the SCVP server still needs to apply a server 
cetificate from a CA even in the case where all its intended clients are simple clients? (Note: I am talking about the case where
SignedData is used. Let the AuthenticatedData case be
temporary out of the scope of our discussion.)
However, in your last mail, you tell us that "for simple clients, the
trust mechanism cannot rely on any form of certificate
validation...". I do not understand if the SCVP server certificate is 
no use in the case where all the intended clients are simple clients,
why does the SCVP server still need to have a server certificate?
Why not let th SCVP server directly distribute its own public-key
to all its clients via an out-of-band trusted channel?

It does not make sense to me if you require the SCVP server to
apply a server certificate from a CA but tell the client that it does
not to validate the server certificate and does not need to check
whether the server certificate is revoked by its issuer.

Wen-Cheng