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

From: "Trevor Freeman" <[email-masked]>
Date: Fri, 12 Sep 2003 14:49:05 -0700

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

-----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: Denis Pinkas <[email-masked]>
Date: Mon, 15 Sep 2003 09:23:23 +0200

Trevor,

> requests to other SCVP servers(relay).

There is a third class, as well :

   * Normal clients (as opposed to simple clients) which can directly query 
different SCVP servers, e.g. because they support different validation 
policies and which are using trust anchors and some local conditions. The 
advantage is that the keys of the SCVP servers may easily be changed, 
without the need for a local re-configuration. The local configuration is 
close to the SCVP server class.

IF the SCVP server has no certificate, THEN it can only be accessed by 
simple clients.

IF the SCVP server has a certificate, THEN it can always be accessed: by 
simple clients, normal clients and SCVP servers.

Thus I see advantages to always include the SCVP certificate, even if simple 
clients are free to ignore it when validating the response.

Denis

---

From: "Wen-Cheng Wang" <[email-masked]>
Date: Mon, 15 Sep 2003 18:09:18 +0800

> close to the SCVP server class.

It seems that you belong to a different taxonomy school :-)
The main difference between "Simple clients" and "SCVP servers as clients"
(SCVP Srver relays) is that a SCVP server has its own path construction/validation
modules while a simple client might have no its own path construction/validation
modules (that is why the simple client need to delegate that job to a SCVP server).
I do not see why a simple client can not directly query different servers. Cann't a
simple client query any SCVP server listed in its trusted list?
Therefore, I do not understand the difference between your definition of normal
clients and the definition of simple clients. Does a "normal client" you definied
has its own path construction/validation modules?

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 15 Sep 2003 14:12:11 +0200

Wen-Cheng,

> simple client query any SCVP server listed in its trusted list?

This is one possible case, but not the only one.

> has its own path construction/validation modules?

A "normal client" knows trust anchors (i.e. root CAs) and can query SCVP 
servers that are certified by one of these trust anchors (plus other 
conditions like CP OIDs for example or a given name). He will check the 
revocation status of the SCVP in the normal way, i.e. using CRLs or OCSP 
responses.

Normal = "fat" client. :-)

A simple client does not know what a trust anchor is and directly trusts the 
public key(s) of the servers(s).

Denis

---

From: "Wen-Cheng Wang" <[email-masked]>
Date: Tue, 16 Sep 2003 13:53:33 +0800

Denis,

> responses.must 
That sounds to me that a "normal client" has to have its own path
construction/validation module, which might be a restircted (less capable)
version, so that it can validate any SCVP server certificate that
can be reached by one or more certification paths, which must
start from one of its trust anchors and must can be constructed and
validated by its own (less capable) path construction/validation module.
If so, "normal clients" indeed represent a class between "simple clients"
and "SCVP servers as clients" (SCVP server relays).

BTW, I note that you said 'a "normal client" .... can query SCVP servers
that are certified by one of these trust anchors'. Do you mean that only
trust anchors can issue SCVP server certificates? Or, again, is this just one
possible case, but not the only one? For example, in a hierarchical PKI, can
a lower-level subordinate CA issue SCVP server certificates? At least , I do
not see any restriction imposed in the current SCVP draft on who can issue
SCVP server certificates.

Wen-Cheng

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 16 Sep 2003 08:50:40 +0200

Wen-Cheng,

> SCVP server certificates.

Any CA can indeed issue an SCVP certificate. There may be a hierarchy.
We are in agreement.

Denis