Internet X.509 Public Key Infrastructure: Certification Path Building
draft-ietf-pkix-certpathbuild-05

[Ballot comment]
The main text sentence describing applicability is bit understated, though the Abstract is clear enough.
I think too, that some apps developers will not find an exact enough match, though finding
useful information. 

Overall I think the level set is quite good, and well caveated.

[Ballot comment]
Reviewed by Brian Carpenter, Gen-ART

His review:

Probably no-objection, but I have a couple of queries and nits.

Disclaimer: 74 page draft on a topic where I am an anti-expert. YMMV.

>    This document was written to provide guidance and recommendations to
>    developers building X.509 public-key certification paths within their
>    applications.

Q1: Was there a positive choice *not* to make this a BCP, and does
that choice imply any doubt about the recommendations?

Q2: I found no mention of the proxy certificate mechanism,
already implemented in grids, RFC 3820. Doesn't this affect the
way certification paths are built?

Nit 1: no IANA Considerations section

Nit 2: There's a reference to [RFC 2396], which is being updated. But
in any case, this reference is not cited in the text, so what is
it for? Same for [RFC 1738] - maybe all the informative references
should be checked.

[Ballot comment]
RFC-Editor gave me a tool with which they check references.
It found:

!! Missing Reference for citation: [PCA]
  P012 L028:    with one CA (known as a "principal" CA [PCA]) in each participating

!! Missing citation for Informative reference:
  P073 L007:      [MINHPKIS]  Hesse, P., Lemire, D., "Managing Interoperability

!! Missing citation for Informative reference:
  P073 L052:      [PKIXALGS]  Bassham, L., Polk, W. and R. Housley, "Algorithms and

!! Missing citation for Informative reference:
  P073 L044:      [X.501]    ITU-T Recommendation X.501: Information Technology -

[Ballot discuss]
The Security Considerations fail to discuss an important DOS attack, and
  with some simple guidance, it is easliy avoided.  In an early SSL
  implementation, the signature was checked before the cert path was checked.
  There is no point checking the cert path if the signature is not
  valid, right?  Well, the attacker sent a completely bogus certificate
  that contained a 16K-bit public key.  The server had to be rebooted to
  stop the signature checking.  If the path was checked first, the bogus
  certificate would have been detected, and the signature checking
  operation would never have started.  We have the same situation here.
  Signature checking needs to follow cert path construction.  Then, it
  needs to proceed from the trust anchor to the target cert.  This will
  prevent this same attack via a bogus intermediate cert.