Subject: Re: Lightweight Certificate Validation Protocol (LCVP)

From: "Denis Pinkas" <[email-masked]>
Date: Wed, 9 May 2007 14:41:44 +0200

This is a collective answer to Stefan, Paul, Peter and Steve. 

The purpose of this e-mail is to define the target for LCVP (see section A), 
and to highlight the sentences in SCVP which prevent to define a profile 
for implementing a level of functionality and simplicity equivalent to LCVP
(see section B).

It also includes a field by field comparison between LCVP and SCVP. 
(see section C). 

The last point is for the editors of SCVP (see section D). 

A - LCVP objectives

LCVP has the following six main objectives: 

   a) the definition of a protocol supporting Delegated Certificate 
      Validation (DCV) only,

   b) the definition of a protocol to be used by clients which do not 
      need to demonstrate to somebody else that they got a given response 
      from a given server,

   c) the definition of a protocol, and thus an interface, easy to use, 
      as simple as possible, for application developers that are *not* 
      PKIX experts,

   d) the definition of a protocol usable either to validate 
      electronic signatures conformant to RFC 3126 or to revalidate them,

   e) the ability to build thin clients conformant to a specification 
      supporting either validation for the present time or revalidation 
     (for a time in the past),

   f) the ability to build thin servers conformant to a specification 
      supporting either validation for the present time or revalidation 
     (for a time in the past),

Implementers of LCVP will be able to claim conformance to the specification 
for client software only, server software only, or both; for either validation or 
revalidation, or both.

B - There exists currently twelve sentences in SCVP which prevent to define a profile 
for implementing a level of functionality and simplicity equivalent to LCVP:

1 - Page 10.

   All SCVP clients and servers MUST support SignedData for signed
   requests and responses.

2 - Page 12:

   Conforming servers MUST be able to parse CVRequests that contain any
   or all of the optional items.

3 - Page 15:

   Conforming SCVP Server implementations MUST be able to process
   CertReferences with multiple certificates.

4 - Page 15:

   Conforming SCVP server implementations that support
   delegated path validation (DPV) as defined in [RQMTS] MUST support
   the id-stc-build-valid-pkc-path and id-stc-build-status-checked-pkc-
   path checks.

    - id-stc-build-valid-pkc-path: Build a validated certification path
       to a trust anchor (revocation checking not required);

    - id-stc-build-status-checked-pkc-path: Build a validated
       certification path to a trust anchor and perform revocation
       status checks on the certification path.

Comment:  The support of id-stc-build-valid-pkc-path, which is mandatory for SCVP, 
does not make sense for LCVP.  With LCVP, ALL the checks to be done are hidden 
behind the OID of the validation policy.  The client cannot influence in any way 
the checks to be done. 

5 - Page 20 : 

   Conforming SCVP servers MUST be able to process a ValidationPolicy
   that contains any or all of the optional items.

6 - Page 30:

responseFlags

   SCVP clients and servers MUST support the default behavior.

Comment: This means that both clients and servers MUST support protectResponse 
and cachedResponse, which is unnecessary for LCVP.

7 - Page 40:

    2. The server MUST protect all other success responses.  If the
       server is unable to return a protected success response due to
       local policy, then it MUST return an error response.

8 - Page 41: 

For protected requests and responses, SCVP servers MUST support SignedData;

9 - Page 41: 

   Where a protected response is required, SCVP servers MUST use 
   SignedData or AuthenticatedData, even if the transaction is 
   performed using a protected transport (e.g., TLS).

Comment: This is clearly the most important sentence, since it mandates signed data, 
even if TLS is being used.

10 - Page 42: 

   The CVResponse MUST contain the serverConfigurationID item.

11 - Page 42:

   Conforming SCVP clients MUST be capable of processing a CVResponse 
   with the following optional items: respValidationPolicy; requestRef; 
   requestorName; replyObjects; and respNonce.

Comment: This means that clients MUST support components that will not even be present 
in the request: requestRef, requestorName and respNonce. All of them are unnecessary 
for LCVP.

12 - Page 43:

   Conforming SCVP clients MUST be capable of processing a CVResponse 
   that includes the serverContextInfo.

Comment: This is unnecessary for LCVP.

C - Field by field comparison between LCVP and SCVP.

LCVP request

The main parameters for an LCVP request are:

     certToValidate               CertOrCertRef,
     valPolicyRef                 ValPolicyRef             OPTIONAL,
     validationData               ValidationData           OPTIONAL,
     returnValidationData         BOOLEAN DEFAULT FALSE,
     validationTime               GeneralizedTime          OPTIONAL,
                                  -- only present for revalidation

1) certToValidate

The major difference with SCVP is the way to transmit the full certificate:

With SCVP:
       cert          [0] Certificate,

With LCVP:
       certificate   [0] OCTET STRING,

The implication is that LCVP clients only need to locate, copy and paste 
the certificate which remains opaque.

2) valPolicyRef

With LCVP, in order to use the default validation policy, the client simply omits the parameter 
in its request, since it is OPTIONAL:

     valPolicyRef            ValPolicyRef OPTIONAL,

With SCVP, in order to use the default validation policy, since the validationPolicy parameter 
is mandatory, the client MUST specify an OID :

     validationPolicy        ValidationPolicy,

   The object identifier that identifies the default validation policy
   is:

     id-svp OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
            dod(6) internet(1) security(5) mechanisms(5) pkix(7) 19 }

     id-svp-defaultValPolicy OBJECT IDENTIFIER ::= { id-svp 1 }

This is extra complexity, but this has a major impact for the response.  
See the comment on this parameter for the response.

3) validationData

Both SCVP and LCVP support this information. SCVP supports two parameters: intermediateCerts 
and revInfos. With LCVP this information is directly reusable with RFC 3126, to support the validation 
of electronic signature: a simple copy and paste operation is sufficient.

4) returnValidationData

Both SCVP and LCVP support this information.  In LCVP it is a boolean, whereas with SCVP 
two OIDS have to be used. It is extra complexity.

5) validationTime

Both SCVP and LCVP support this information.

LCVP response

The main parameters for an LCVP response are:

       validationStatus           CertStatus,
       valPolicyRef               ValPolicyRef,
       validationTime             GeneralizedTime,
       subjectPublicKeyInfo       SubjectPublicKeyInfo,
       fullSubjectName            FullSubjectName,
       keyUsage                   KeyUsage           OPTIONAL,
       extKeyUsage                ExtKeyUsageSyntax  OPTIONAL,
       certificate                OCTET STRING       OPTIONAL,
       validationData        [0]  ValidationData     OPTIONAL,

1) validationStatus

The CertStatus from LCVP returns:

   CertStatus ::= ENUMERATED {
       valid                (0) ,  -- valid certificate
       invalid              (1) ,  -- invalid certificate
       temporaryInvalid     (2) ,  -- temporarily invalid certificate
       unknown              (3)    -- validity unknown
   }

The ReplyStatus from SCVP returns:

     ReplyStatus ::= ENUMERATED {
         success                    (0),
         malformedPKC               (1),
         malformedAC                (2),
         unavailableValidationTime  (3),
         referenceCertHashFail      (4),
         certPathConstructFail      (5),
         certPathNotValid           (6),
         certPathNotValidNow        (7),
         wantBackUnsatisfied        (8) }

  - valid from LCVP is equivalent to success from SCVP.
  - invalid from LCVP is equivalent to certPathNotValid from SCVP.
  - temporaryInvalid from LCVP is equivalent to certPathNotValidNow 
    from SCVP.
  - unknown from LCVP is equivalent to certPathConstructFail from SCVP.

The understanding is harder for non PKI experts.

However, this is not the end of the story, since ReplyCheck also includes a status:

         --  0: Valid
         --  1: Not valid
         --  2: Revocation Off-line
         --  3: Revocation Unavailable
         --  4: No known source for revocation information

Application developers may have problems to interpret both statuses and make sure 
they are consistent.

There is also a third status to analyse: ResponseStatus.

LCVP supports one status for errors and another status for the application. In this way, it is easier 
to be used by non PKI experts.

2) valPolicyRef

Both SCVP and LCVP return this information. However, there is a major difference when the server 
default validation policy is being used. 

SCVP will return the OID of the default policy:

     id-svp OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
            dod(6) internet(1) security(5) mechanisms(5) pkix(7) 19 }

     id-svp-defaultValPolicy OBJECT IDENTIFIER ::= { id-svp 1 }

SCVP does not allows the client to verify that the server default validation policy matches the needs 
of its application.  On the contrary, LCVP always returns a meaningful OID, which allows to make 
that verification.

3) validationTime

LCVP defines the validationTime as:

   If that field was missing in the request, then it SHALL correspond 
   to the date the thisUpdate field from the CRL relative to the 
   certificate, or to the thisUpdate field from an OCSP response 
   relative to the certificate.

SCVP defines the replyValTime as:

   If the validationTime is not present, the server MUST respond 
   as if the client provided the date and time at which the server 
   processes the request.

The consequence is the following: SCVP cannot be used to validate certificates used to validate 
electronic signatures when the signature policy includes a grace period. See the details in LCVP 
or in RFC 3126.

4) subjectPublicKeyInfo

Both SCVP and LCVP return this information. It is always returned with LCVP, whereas it must 
be requested with SCVP using id-swb-pkc-public-key-info in wantBacks.

5) fullSubjectName

SCVP does not return separately this information. Clients using SCVP may rebuild this information 
using several sources of information: the subject field and/or the subject alternate name from the 
certificate and then the DN from every certificate present in the CertBundle. This is extra code 
to write and this is not trivial for non PKI experts.

6) keyUsage

SCVP does not return separately this information, but the full certificate. Clients using SCVP must 
explore the OIDs from Extensions and find out the right OID to extract this field. This is extra code 
to write and this is not trivial for non PKI experts.

7) extKeyUsage

SCVP does not return separately this information, but the full certificate. Clients using SCVP must 
explore the OIDs from Extensions and find out the right OID to extract this field. This is extra code t
o write and this is not trivial for non PKI experts.

8) certificate

SCVP returns Certificate whereas LCVP returns OCTET STRING. Normally, the fields that are 
previously returned are sufficient. If not, the client will then need to parse the certificate to extract 
the other fields it might need. With SCVP, all the fields are decoded, but the client software package 
will be more complicated and larger.

With SCVP the certificate is only returned, if id-swb-pkc-cert is included in wantBacks. With LCVP 
the certificate is always returned, if not present in the request.

9) validationData

Both SCVP and LCVP return this information. However, with LCVP this information is directly reusable 
with RFC 3126, to support the validation of electronic signature: a simple copy and paste operation 
is sufficient. This is more complicated with SCVP.

D - A change should be done in SCVP during the 48 hours period reserved for editorial changes.

Page 48:

     CertReference ::= CHOICE {
       pkc                   PKCReference,
       ac                    ACReference }

Denis

---

From: Peter Sylvester <[email-masked]>
Date: Wed, 16 May 2007 18:53:09 +0200

>    a) the definition of a protocol supporting Delegated Certificate 
That can be achieved using a profile of SCVP
>       need to demonstrate to somebody else that they got a given response 
This doesn't mean that you cannot use a protocol that provided this, in 
fact, you
do not distinguish between clients and servers. If a client can 
authenticate a
server in whatever way, just ignore the signature.
>       as simple as possible, for application developers that are *not* 
At least a developer must find a certificate or reference in the 
structure and
decide that it wants to validate it. The client also has to know for 
what purpose
the certificate is used, e.g. signature verification or encryption. The 
application
does not need to know anything about PKI, i.e; CAs,n traust anchors, is that
what you mean?
>       electronic signatures conformant to RFC 3126 or to revalidate them,
Not at all.
There you ask for a protocol to verify a signature, not a certificate. 
So, if at
all, I would take the signtaure part of a CMS with or without content 
and present
it to a service.
>      (for a time in the past),
reverification is one of the opetional features in 3126. I don't buy 
this idea.
>      (for a time in the past),
IMO the client should be thin first, what means thin of the server is 
not s clear.

> for client software only, server software only, or both; for either validation or 
Ok.
>    All SCVP clients and servers MUST support SignedData for signed
Strictly speaking this sentence doesn't mean that they MUST generate them.
>    or all of the optional items.
Parsing is not the problem. A server can always return error saying that it
doesn't support them. A client implmentation does not need to provide
an API or encoding parts for non supported features. So the client becomes
thin.
>    CertReferences with multiple certificates.
I don't really think that this is an important point not to use SCVP, I 
would
indeed always like to support verification of all encryption certs for all
the recipients at once.
> behind the OID of the validation policy.  The client cannot influence in any way 
Where is the problem?
>    that contains any or all of the optional items.
This phrase has always amused me, since it confuses optional in the sense
of asn.1 and the possibility or not to allow a client to set it. IMO, a
server can always refuse to take any of the ASN.1 optional parameters.
> and cachedResponse, which is unnecessary for LCVP.
There may be some need for textual change here.
>        local policy, then it MUST return an error response.
Isolated, this sentence seems ok, but the restricted means of what is 
protected
may be a problem. What you are suggesting is to choose appropriate working
that allows a client/server communication using almost any other 
authentication
method.
> For protected requests and responses, SCVP servers MUST support SignedData;
So?
> even if TLS is being used.
A client can ignore the signature, that is simple, and well, just use a 
very signature
key in case. :-)
>    The CVResponse MUST contain the serverConfigurationID item.
So, this doesn' seem to me a big overhead.
> in the request: requestRef, requestorName and respNonce. All of them are unnecessary 
But if you don't use them in the client, you don't have to process them, 
copying
some values in a server id not a big deal.
> Comment: This is unnecessary for LCVP.
And you don't get it because you perform only certficate validation and not
path determination.

> C - Field by field comparison between LCVP and SCVP.
I don't think I'll go into the following because I do not see a need fpr 
LCCP,
at best a few adjustments in wording in SCVP.