SCVP: Delegation of Certificate Path Construction and Validation

1. Comments on draft-ietf-pkix-scvp-19.txt IETF Meeting Paris - August 2005 Denis Pinkas (Denis.Pinkas@bull.net)

2. Some extracts • SCVP allows a client to delegate certificate path construction and certificate path validation to a server. The path construction or validation (e.g. making sure that none of the certificates in the path are revoked) is performed according to a validation policy, which contains one or more trust anchors. • A validation policy (as defined in RFC 3379 [RQMTS]) specifies the rules and parameters to be used by the SCVP server when validating a certificate. In SCVP, the validation policy to be used by the server can either be fully referenced in the request by the client (and thus no additional parameters are necessary) or it can be referenced in the request by the client with additional parameters. • When the validation policy defines every parameter necessary, an SCVP request needs only to contain the certificate to be validated, the referenced validation policy, and any run-time parameters for the request.

3. Current syntax of Validation Policy ValidationPolicy ::= SEQUENCE { validationPolRef ValidationPolRef, validationAlg [0] ValidationAlg OPTIONAL, userPolicySet [1] SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER OPTIONAL, inhibitPolicyMapping [2] BOOLEAN OPTIONAL, requireExplicitPolicy [3] BOOLEAN OPTIONAL, inhibitAnyPolicy [4] BOOLEAN OPTIONAL, trustAnchors [5] TrustAnchors OPTIONAL, keyUsages [6] KeyUsages OPTIONAL, extendedKeyUsages [7] SEQUENCE OF KeyPurposeId OPTIONAL }

4. Current syntaxes of ValidationPolRef and ValidationAlg ValidationPolRef::= CHOICE { valPolRefByOID OBJECT IDENTIFIER, valPolRefByURI IA5String} ValidationAlg ::= SEQUENCE { valAlgId OBJECT IDENTIFIER, parameters ANY DEFINED BY valAlgId OPTIONAL }

5. only a limited set of optional parameters The concept of default validation policy is incorrect. It may use any “algorithm”, and in the response it MUST be known which “real” policy has been used. Current text • The validationPolRef item is required, but the remaining items are optional. • The optional items are used to provide validation policy parameters. • When the client uses the validation policy's default values for all parameters, all of the optional items are absent. The validationAlg item specifies the validation algorithm. […] • The default validation policy MUST use the basic validation algorithm as its default validation algorithm. • When using the default validation policy, the client can override any of the default parameter values by supplying a specific value in the request.

6. Issues with the current syntax • The current syntax does not allow to specific individual parameters for each trust anchor, like: userPolicySet inhibitPolicyMapping, requireExplicitPolicy, inhibitAnyPolicy keyUsages, KeyUsages and extendedKeyUsages. • Also, if an additional parameter needs to be added policy (e.g. a QCStatement test), it currently needs to be added as : • a parameter of the “validation algorithm”, instead of • a parameter of the “validation policy”.

7. Example with current syntax • A validation policy is supporting several trust anchors, each one with its own certificate policy, path length and naming constrains, but the client may request to have a QCstatement equal to a specific value. • There would be the need to have two OIDs: • one for the validation policy, and another • one for the validation algorithm, while the specific parameter to support the QCstatement would be a parameter of the validation algorithm (instead of a parameter from a validation policy) : ValidationPolicy ::= SEQUENCE { validationPolRef ValidationPolRef, validationAlg [0] ValidationAlg OPTIONAL, }

8. The syntax should be simplified and changed into : ValidationPolicy ::= SEQUENCE { valPolId OBJECT IDENTIFIER, parameters ANY DEFINED BY valPolId OPTIONAL } • Then a specific validation policy, based on the algorithm described in RFC 3280, should defined «id-svp-basicValPol», with its own parameters : userPolicySet [1] SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER OPTIONAL, inhibitPolicyMapping [2] BOOLEAN OPTIONAL, requireExplicitPolicy [3] BOOLEAN OPTIONAL, inhibitAnyPolicy [4] BOOLEAN OPTIONAL, trustAnchors [5] TrustAnchors OPTIONAL, keyUsages [6] KeyUsages OPTIONAL, extendedKeyUsages [7] SEQUENCE OF KeyPurposeId OPTIONAL } Section 6.1 from 3280bis specifies a single trustAnchor.

9. Advantages • The request and mandatory-to-implement clients parameters becomes much simpler. • For thin clients, there is no need to support (i.e. to incorporate in the client code) parameters like : userPolicySet inhibitPolicyMapping, requireExplicitPolicy, inhibitAnyPolicy keyUsages, KeyUsages and extendedKeyUsages.

10. Default validation policy • When a default parameter is being used, usually it is left empty by the client. Why would this draft make an exception ? • validationPolicy in Queryshould be optional. • Then, when the default validation policy is being invoked by the client, the server MUST return the real OID of the validation policy (which MAY only have fixed parameters), ... but the current text is silent about this.

11. policyIDfromCVResponse • « The policy ID representing the version of the default validation policy that was used by the SCVP server when it processed the request ». • A validation policy is fully defined by an OID. An OID has no version. • Please suppress.

12. validationPolicyAttr RespValidationPolicy ::= SEQUENCE { validationPolicy ValidationPolicy, validationPolicyAttr SEQUENCE SIZE (1..MAX) OF AttributeOPTIONAL } • validationPolicyAttr exists in a response, but not in a request ?!?

13. In addition ... • The use of valPolRefByURI does not appear to be adequate. • The IESG has refused in the past to accept the use of URIs for long term and stable references.(RFC 4043 - Permanent Identifier)