[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments to SCVP ID 17
Denis,
I was looking forward to reading thoughtful and insightful comments on the new
draft, and was very disappointed to find that the following message was nothing
but insults. To repeatedly suggest that the editors "have not read in detail
RFC 3280" or its various sections is a bit much.
Consider your message deleted.
Tim Polk
Quoting Denis Pinkas <Denis.Pinkas@xxxxxxxx>:
>
> To the co-editors,
>
> 1. I basically agree with the comments from Wen-Cheng sent to the list on
> February 18 : the authors have still not correctly understand the
> difference between “validation policy” and “validation algorithm”.
>
> Sections 1.3 and 1.4 which are the foundations of the document are still
> wrong. It is very painful, time consuming and time wasting to repeat
> again and again the same comments which are not considered by the
> editors.
>
> The authors, who are more and more numerous (since Tim Polk and David
> Cooper have now joined round 17) have not read in detail RFC 3280 and are
> making confusion between terms and are inventing new wordings which add
> to the confusion (see more details below).
>
>
> 2. The first new wording introduced is: “PKI policies” which is a term
> which is defined nowhere in RFC 3280 nor in this document. When it is
> used, it means “validation policy”. Please delete everywhere “PKI
> policy”
> and replace it with “validation policy”.
>
> The author have not read in details RFC 3280 section 6.1.
>
> On page 7 they introduce a new term “basic certification path processing
> algorithm” whereas RFC 3280 uses:
> - “certification path validation” (that is the title of section 6) and
> - “basic path validation” (that is the title of section 6.1).
>
> The major mistake is to refer to section 6.1.1 and then say that the
> inputs in section 6.1.1 have a “Set of Trust Anchors”. This is wrong.
> Section 6.1.1 deals with a *single* trust anchor, whereas section 6.2
> from RFC 3280 deals with multiple trust anchors.
>
> This demonstrates that section 1.3 is wrong.
>
>
> 3. Section 1.4 is about a “validation algorithm”. Does this notion, as
> explained, makes sense ? Is this notion supported in RFC 3379 ? The
> answer is no.
>
> From the introduction, “a validation policy contains one or more trust
> anchors »
>
> From section 1.3, “a validation policy specifies the rules and parameters
> to be used by the SCVP server when validating a certificate”.
>
> Different rules may apply to every trust anchor and to the CA
> certificates from a certification path under every trust anchor. The
> ASN.1 description of ValidationPolicy starting on page 17 does not allow
> to define different rules for different trust anchors. This comes from
> the previous mistakes.
>
> We currently have:
>
> 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 [6] TrustAnchors OPTIONAL,
> keyUsages [7] KeyUsages OPTIONAL,
> extendedKeyUsages [8] SEQUENCE OF KeyPurposeId OPTIONAL}
>
> and
>
> ValidationAlg ::= SEQUENCE {
> valAlgId OBJECT IDENTIFIER,
> parameters ANY DEFINED BY valAlgId OPTIONAL }
>
> If:
> trustAnchors [6] TrustAnchors OPTIONAL,
>
> is changed into:
>
> trustAnchor [6] TrustAnchor OPTIONAL,
>
> then only the algorithm from section 6.1 of RFC 3280 can be used, and it
> would be a pity to make three calls if a validation policy included three
> trust anchors.
>
> PLEASE co-editors, read carefully, and think about it before answering
> too quickly.
>
> The conditions that apply to CA certificates may be very complicated and
> vary from one trust anchor to another. The goal if this document is NOT
> to be able to specific *remotely* every single parameter of section 6.1
> from RFC 3280.
>
> The goal if this document is to support as a whole section 6.2 from RFC
> 3280. Once again, from the introduction, “a validation policy contains
> one or more trust anchors ».
>
> The validation policy could OPTIONALLY include several “target
> certificate specific parameters” as Wen-Cheng proposed, since these
> parameters do not change from one trust anchor to another. I fully agree
> with Wen-Cheng that “target certificate” is more appropriate than “end
> certificate”.
>
> This would also solve the confusion that Wen-Cheng noticed about the
> “name validation algorithm” which would become one of the “target
> certificate specific parameters”. Checking the target certificate DN is
> far more important than checking the CA DNs. If both checks are really
> needed, those checks may be different.
>
> It is obvious that for each certification path the algorithm from section
> 6.1 of RFC 3280 is being used.
>
> A validationAlg parameter is not needed. We could then simply have:
>
> ValidationPolicy ::= SEQUENCE {
> validationPolRef ValidationPolRef,
> keyUsages [0] KeyUsages OPTIONAL,
> extendedKeyUsages [1] SEQUENCE OF KeyPurposeId OPTIONAL,
> nameValidationAlgParms [2] NameValidationAlgParms OPTIONAL,
> otherTests [3] OtherTests OPTIONAL
> }
>
> otherTests could be used for example to test QCStatements extensions.
>
>
> 4. As Wen-Cheng noted, the “default validation policy” does not make
> sense.
>
>
> 5.Section 1.5 states: “However, revocation checking is an optional
> feature in [PKIX-1], and revocation information is distributed in
> multiple formats.” This is incorrect.
>
> RFC 3280 does not say that revocation checking is optional. Only CRLs
> processing is defined in RFC 3280 but we all know that OCSP is an
> alternative method. Revocation checking MUST be done to validate a
> certificate, but may be done using different means. These means may be
> specified in the validation policy.
>
> On page 49 from we have:
>
> Conforming CAs are not required to issue CRLs if other revocation or
> certificate status mechanisms are provided.
>
> When the client sends a DPV request, revocation checking MUST be done.
> When the client send a DPD request, revocation status information MAY be
> returned or not.
>
> This illustrates once again the problem when a single document is mixing
> the protocols for DPV and DPD.
>
>
> 6. It should be remembered that RFC 3379 makes the separation between DPV
> and DPD, while this document mixes them. It is therefor very doubtful to
> say that this document fills in the goals of RFC 3379.
>
>
> 7. “SCVP” is a very bad name when the request is to build only a
> certification path, with or without revocation status (i.e. DPD, leaving
> the validation to the client). The certificate is not VALIDATED by the
> server, and even if it would, the client would not trust it. It is
> apparent that some people would like to keep the “trade name” SCVP, but
> this will add confusion; but maybe this is what is deliberately wanted ?
>
>
> 8. The text correctly states on page 6: “An SCVP request needs only to
> contain the certificate to be validated, the referenced validation
> policy, and any run-time parameters for the request”.
>
> It would be very beneficial to be able to have implementations that only
> support the above requirements for DPV, leaving the security of the
> communication link (i.e. using TLS) . The problem is that is not
> straightforward to derive a profile from this huge “monument” which is
> overcomplicated because it mixes DPV and DPD requirements.
>
> It is strong suggested to revise the document so that this goal can be
> achieved and that conformance clauses can be added to be able to say that
> a given implementation is conformant to the *simple* certificate
> validation request mentioned above.
>
> Unless the editors can provide a profile or/and indications on how this
> goal would be achieved, it is very doubtful that the full protocol will
> be widely implemented and used by applications.
>
> If this is not done, it would then make sense to develop “HSCVP” : Hyper
> Simple Certificate Validation Protocol” or rename the current drat as
> CCVP, as it has always be !
>
> Hyper Simple Certificate Validation Protocol is a protocol which contains
> the certificate to be validated (i.e. just one), the referenced
> validation policy (no other parameter), any useful certificates and
> revocation information (as provided by the client), and where the server
> tells whether the certificate is valid or not against that referenced
> policy (it may also return a “I don’t know” response).
>
> In section 1.5, the text states: “The typical use of SCVP is expected to
> be over HTTP [HTTP] ». I would rather say: “HSCVP is expected to be over
> HTTPS [HTTPS]”
>
>
> 9. Given the time that it took me to comments on only 8 pages of the
> documents (about 7 hours), you can imagine how long it will take me to
> comment on the full document. I believe the topic is extremely important,
> but the editors are wasting my time.
>
> Being the lead editor of RFC 3379, I believe that I have a little
> knowledge on that topic. More consideration should be paid to my comments
> and to the comments from Wen-Cheng. As he correctly said: “how strange it
> is that the authors always reject the suggestions”.
>
>
> 10. Additional minor comments (up to page 8).
>
> Page 5. Section 1. Second paragraph. The text states:
>
> The first class of applications wants just two things: confirmation
> that the public key belongs to the identity named in the certificate
> and confirmation that the public key can be used for the intended
> purpose.
>
> This is not the main goal. Rephrase as:
>
> The first class of applications wants just confirmation
> that the certificate is valid according a given validation policy.
>
>
> 11. Additional minor comment.
> Page 5. Section 1. Second paragraph. The text states:
>
> The second class of applications can perform certification path
> validation, but they lack a reliable or efficient method of
> constructing a valid certification path.
>
> Rephrase as:
>
> The second class of applications can perform certification path
> validation, but lack a reliable or efficient method of
> constructing a valid certification path and the associated
> revocation status information.
>
>
> 12. Additional minor comment.
> Page 5. Section 1.1. Second paragraph.
>
> The primary goals of SCVP are to make it easier to deploy PKI-enabled
> applications and to allow central administration of PKI policies
> within an organization.
>
> Rephrase as:
>
> The primary goals of SCVP are to make it easier to deploy PKI-enabled
> applications and to allow a server to support one or more validation
> policies against which certificates can be tested by applications.
>
>
> 13. Additional minor comment.
> Page 5. Section 1.1. Second paragraph.
>
> SCVP can be used by clients that do much of
> the certificate processing themselves but simply want an untrusted
> server to collect information for them. However, when the client has
> complete trust in the SCVP server, SCVP can be used to delegate the
> work of certification path construction and validation, and SCVP can
> be used to ensure that policies are consistently enforced throughout
> an organization.
>
> Rephrase as:
>
> SCVP, used for DPV, can be used by clients that have complete trust
> in a trusted DPV server. In such a case, the protocol can be used to
> delegate the work of certification validation against a validation
> policy.
>
> SCVP, used for DPD, can be used by clients that do much of
> the certificate processing themselves but simply want an untrusted
> DPD server to collect certificates and revocation status information
> for them.
>
>
> 14. Since both one of the security area directors and one of the co-
> chairs of PKIX are editors, I request that both the other security area
> director and the other PKIX co-chair take a look at the debate: Tim, the
> over-ever optimistic, being both editor of the draft and PKIX co-chair
> cannot be in a position to say when a rough consensus will be reached.
>
>
> 15. Note also that after having waited for months changes and responses to
> comments, it is not acceptable, that - AS USUAL - the document is only
> delivered two weeks ahead the PKIX meeting: it is not possible to review
> in details two major documents of this WG, i.e. SCVP-17 and RFC3280bis in
> only two weeks.
>
>
> 16. Finally, note also that, unless I can finally agree on the document,
> I do not want to have my name placed in the acknowledgments section as it
> is currently mentioned, since, at this time, I am not *in any way*
> supportive of this “monument”.
>
> I certainly participated to the lively debate, but at this time my
> contributions have not yet been able to “greatly improve the document”.
>
> Denis
>
>
>
>
>