Subject: SCVP Analysis

From: Michael Myers <[email-masked]>
Date: Thu, 15 Jul 1999 06:38:14 -0700

All,

The SCVP draft raises some interesting questions which deserve discussion on
the list.  Below are some thoughts to get that started.  Having gone through
this process, it's very clear to me at least that needs for delegated path
validation can more easily be met with a very simple extension to OCSP.  The
work would be very minimal compared to implementing a totally different
protocol to do exactly the same thing.

Mike

REQUEST SYNTAX AND SEMANTICS

1.  Optional use of a RequestHash  in lieu of a digitally signed request.
----------------------------------------------------------------------
The need to integrity-protect the request hasn't been established.  How is
this request-response protocol different from, say, LDAP?

It seems that requestHash is actually presumed to be sufficient for the
non-repudiation needs of accountability in some environments.  If so, this
needs to be made explicit and-more importantly-discussed on the list as such
a resolution impacts assumptions underlying current trade in certificate
validation services.

If however the authors assert that the requestHash field is unreliable for
service accountability and is meant rather simply as an integrity check, the
requirement for integrity protection equally merits discussion of the
security risks being addressed.  Perhaps the authors have some insight into
security risks that were overlooked in prior PKIX protocols now standing as
RFCs.

Should that discussion conclude that the request syntaxes of PKIX protocols
need to be integrity protected, it seems we may need to amend the
request-response protocols PKIX has currently sent up to IESG which do not
provide such protection.

Should that discussion otherwise conclude that certificate validation
protocols are unique among other protocols in their need for integrity
protected requests, at a minimum this may affect RFC 2560 (OCSP), which
bears a striking architectural similarity to the proposed protocol.

In the absence of resolution of either of these positions, the functionality
seems superfluous.

2.  Explicit specification of a request being a path validation request vs.
a revocation status check.
----------------------------------------------------------------------
The proposed BIT STRING construct fails to adequately accommodate future
evolution of the semantics of certificate validation.

In a more general framework, one could specify request types using OID-based
extensions as we do today with X.509, and as currently established by RFC
2560 (OCSP).

3.  Optional inclusion of the subject certificate in the request.
----------------------------------------------------------------
This seems to be a reasonable requirement.

4.  Optional support for PGP style public key management.
----------------------------------------------------------------
As discussed on the floor in Oslo, inclusion of this functionality would
require a revision to the PKIX charter.  PKIX was specifically established
to address X.509 certificates.

5.  Optional request for the value of subject public key, subject name,
certificate chain or revocation proof.
----------------------------------------------------------------
If it is the objective of the proposed protocol to fully delegate path
validation to an external server, then this functionality isn't in line with
that model.  This looks more like a lightweight data access protocol. 

Further, requests for the public key and subject name seems odd against the
prior capability to include the certificate in the request, which obviously
assumes the requester has the certificate.

So in this instance the server is acting like a remote certificate parser.
If that's indeed the authors' intent, then the proposed functionality is
incomplete.  For completeness, they should consider remotely parsed access
to:  subject alt name extension for IPSEC; certificate policy values for the
policy engines; subject directory attributes for environments using that
extension.

We have three system level-functions being addressed by this protocol:

1.  Fully delegated path validation;
2.  Lightweight PKI data access; and
3.  Remote certificate parsing.

The need for the first capability has been fairly obvious for years.  The
latter two are of questionable value, with perhaps the exception of
returning back the intermediate chain.

6.  Optional specification of intermediate certificates to use as a
supplement to the validation path of the subject certificate.
----------------------------------------------------------------
In the context of the legal framework underpinning the use of certificates
for electronic commerce, the issuer of a certificate issued that certificate
with a very specific trust chain model in mind.

The proposed functionality seems to suggest that the authors are asking PKIX
to support the notion of the "re-purposing" of certificates for uses beyond
those intended by the original issuer.

Was this the authors' intent?  If not, then what problem is this proposed
functionality solving?

7.  Optional specification of trusted roots the server must rely on.
----------------------------------------------------------------
Same issue as above.

Is it the authors' proposition that the issuer of a certificate is *not* the
final arbiter of the trustworthiness of that certificate?  (noting that
"issuer" could be an entity that directs another entity to manufacture and
distribute a certificate on its behalf).

8.  Optional configuration identifier that points to a pre-defined set of
the above options.
----------------------------------------------------------------
This seems to be a reasonable requirement.

9.  Extensions may be critical or non-critical.
----------------------------------------------------------------
Recent experience has shown that this is inadvisable.  The XML DigSig group,
for example, has specifically deprecated proposed use of critical flags for
well-known reasons.

RESPONSE SYNTAX AND SEMANTICS

10.  "Unrecognized" error codes related to the above optional request
protocol elements.
----------------------------------------------------------------
No issues, other than alignment with the prior analysis.

11.  Validation response values for "valid", "notValid",
"temporarilyUnknown" and "unknown".
----------------------------------------------------------------
This seems to be a reasonable requirement.

Except perhaps for "temporarilyUnknown".  What does a client do with that?

12.  Optional inclusion of an errorMessage text string
----------------------------------------------------------------
This seems to be a reasonable requirement.

13.  Optional inclusion of subject public key value, subject name or path
validation chain, consistent with prior request.
----------------------------------------------------------------
See point #5 above.

14.  Optional inclusion of requestHash appearing in request.
----------------------------------------------------------------
See point #1 above.

15.  Optional inclusion of revocation proof content.
----------------------------------------------------------------
See point #5 above.

16.  Optional use of a digital signature
----------------------------------------------------------------
This is the same as OCSP: some error conditions don't need to be signed.
However, the proposed protocol goes on to assert that other types of
responses don't need to be signed if conveyed over a secure channel.

An optional signature on an affirmative response is equivalent to an
unsigned CRL.  It can't be used to support non-repudiation.

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 15 Jul 1999 16:42:18 +0200

Michael,

You didn't loose time since the last meeting. :-)

As I mentioned during the Oslo session I think it would be nice to add some new
fields to the existing OSCP propocol to transform it into a SCVP protocol. It
would have been great if you could have made a proposal before the current SCVP
document was posted. This did not happen. We are not going to look backwards, so
let us look forwards. Rather than looking at the details, it appeared to me that
we first need to agree on the scope of the document.

The current scope, which is copied below, is not adequate

" The SCVP protocol allows a client to offload certificate handling to a
server. The server can give a variety of valuable information about the
certificate, such as whether or not it is valid, what the public key
and subject of the certificate is, and so on."

I would propose to reformulate it this way:

" The SCVP protocol allows a thin client to offload certificate validation to a
trusted server, for a given instant of time, according to a given validation
policy known from that trusted server. The server will give an indication
whether the validation was successful or not and, if requested, may also give
back the certification path and the revocation information (CRLs or OCSP
responses) used to perform that validation. The requester may supply in his
request certificates and or revocation information that may be used by the
server to perform that validation."

If we can agree on the scope then writing the ASN1 should be quite easy. :-)
Since the tiny syntax is now gone away, having an ASN1 description should not be
a problem anymore.

We should not try to fix the current SCVP document but write a new one, re-using
OCSP whenever possible. Ideally, a document co-authored by yourself together
with Ambarish Malpani and Paul Hoffman would certainly be appreciated.

Denis

---

From: Antonio Maña <[email-masked]>
Date: Fri, 16 Jul 1999 12:49:03 +0200

> protocol to do exactly the same thing.

I share your opinion.

> ...

The new version of PGP will support X.509 certificates, so it seems
that this opens the door to the generalised use X.509 certificates.
In this situation I do not believe that including PGP certificates
is worth the effort.
See
http://www.pgpinternational.com/product/pgp60features.html

Cheers,
Antonio Maña.

  +--------------------------------------------------------+
  !           _   ,                                        !
  ! Antonio Mana Gomez               eMail: [email-masked] !
  !              http://www.lcc.uma.es/~amg                !
  +--------------------------------------------------------+
  ! Departamento de Lenguajes y Ciencias de la Computacion !
  !      E.T.S.I.Informatica.        Desp. 1.2.B.19        !
  !                  Campus de Teatinos.                   !
  !                 29071 MALAGA (SPAIN)                   !
  +--------------------------------------------------------+
  ! Phone: (+34) 5 213 27 54        Fax: (+34) 5 213 13 97 !
  +--------------------------------------------------------+
  ! KEY SERVER:                                            !
  !   Cert'eM at http://socrates.crypto.lcc.uma.es         !
  +--------------------------------------------------------+