To the list,
Here are a few comments on the last draft.
The confusion between validationAlg and ValidationPolicy still exists.
On one side (section 6.7) it is said that it is not mandatory for a server to support the "default validation policy" but it is still necessary for a server to support all its parameters !
If we had a bundle to include all what is specific to this "default validation policy", then we could make it optional for the server.
The syntax of the validationPolicy item is:
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] SEQUENCE of KeyUsage OPTIONAL,
extendedKeyUsages [7] SEQUENCE OF KeyPurposeId OPTIONAL }
The text states: “At a minimum, conforming SCVP client implementations MUST support the ValidationPolRef item.”
It also states: "Where a validation policy supports additional policy-specific parameter settings, these values are specified using the valPolParams item".
These policy-specific parameter settings are not ADDITIONAL to anything since they are the only parameters and all the others, supposed to be used for they so-called default validation policy are simply ignored.
The name validation policy is one more level of complexity that all servers would have to support. There will not be many server implementations compliant with this specification !
Note also that the "name validation algorithm" is exclusive of the "basic validation algorithm". This does not work.
For the CVResponse the configurationId (was policyID) is still an odd object.
The text states: The configuration ID represents the version of the default validation policy that was used by the SCVP server when it processed the request. See section 6.4 for details.
Since this item is specific to the default validation policy it cannot be mandatory, but it is !
Then how can we have a version of a validation policy ???
The explanations from 6.4 do not help to understand.
Despite my request made among other requests "What needs to be implemented to be able to say that the implementation is (only) DPV conformant ?" the document does not make a clear distinction on the requirements that are only necessary for DPV. This comes from the fact that two different documents would have been much better, but because some people wanted to maintain the acronym SCVP this has not been done.
Did everybody noticed that "S" does not mean "Simple" anymore, but "Standard", once again to keep the acronym.
A very minor point: in section 4.8 there is no way to know what the item represents among the three choices offered to the server.
Finally, since this document was created in the previous century, we had no problem with SHA-1 at that time and hence we used ESSCertID. However, ESSCertID mandates the use of SHA-1.
I would propose to allow to use therSigningCertificat as defined in RFC 3126.
id-aa-ets-otherSigCert OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) id-aa(2) 19 }A New Internet-Draft is available from the on-line Internet-Drafts directories.This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : Standard Certificate Validation Protocol (SCVP) Author(s) : A. Malpani, et al. Filename : draft-ietf-pkix-scvp-21.txt Pages : 78 Date : 2005-10-25 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. It allows simplification of client implementations and use of a set of predefined validation policies.A URL for this Internet-Draft is:http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-21.txtTo remove yourself from the I-D Announcement list, send a message to i-d-announce-request@xxxxxxxx with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings.Internet-Drafts are also available by anonymous FTP. Login with the username"anonymous" and a password of your e-mail address. After logging in,type "cd internet-drafts" and then "get draft-ietf-pkix-scvp-21.txt".A list of Internet-Drafts directories can be found inhttp://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txtInternet-Drafts can also be obtained by e-mail.Send a message to: mailserv@xxxxxxxxxxx the body type: "FILE /internet-drafts/draft-ietf-pkix-scvp-21.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail readerimplementation to automatically retrieve the ASCII version of theInternet-Draft.
ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-scvp-21.txt
Attachment:
draft-ietf-pkix-scvp-21.txt
Description: Binary data