Subject: How a SCVP client authenticates the SCVP server?

From: "Wen-Cheng Wang" <[email-masked]>
Date: Fri, 12 Sep 2003 20:00:24 +0800

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: "Santosh Chokhani" <[email-masked]>
Date: Fri, 12 Sep 2003 12:41:16 -0400

Well put.

I always assumed that option 3 is not viable for the reasons cited.

I always assumed that if the client relies on SCVP for path validation, it
will have one or more SCVP servers as it trust anchor(s) as opposed to
having Certification Authority(s) as its trust anchor(s).

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Wen-Cheng Wang
Sent: Friday, September 12, 2003 8:00 AM
To: [email-masked]
Subject: How a SCVP client authenticates the SCVP server?

Folks,

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:

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

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.)

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.

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.

Best Regards,
Wen-Cheng Wang

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 15 Sep 2003 09:47:26 +0200

Santosh,

> having Certification Authority(s) as its trust anchor(s).

As you know, ISO is currently attempting to provide a definition for what is 
a trust anchor in a PDAM. Although not finally approved, it is along the 
following lines:

"trust anchor: The public key of a CA that is trusted by a certificate using 
system and used as the starting trusted public key for validating signatures 
on certificates and/or CRLs in a certificate chain."

Since the definition clearly mentions a CA, the wording "SCVP servers as it 
trust anchor(s)" is not appropriate. Since an SCVP server is not a CA, its 
public key cannot be considered to be a "trust anchor".

Call it "directly trusted key", if you wish, but do not use the wording 
"trust anchor".

Denis.