Internet X.509 Public Key Infrastructure Operational Protocols: Certificate Store Access via HTTP
RFC 4387

Note: This ballot was opened for revision 09 and is now closed.

(Harald Alvestrand) Discuss

Discuss (2004-09-27 for -)
I do not think this should go forward without a longer review than I can give it before the telechat.

Glancing at RFC 3275 (XML Signature syntax and processing) and section 2.4 of this document, I'm forced to conclude that either the stuff they want to specify is completely specified in RFC 3275 or it is not specified at all.

Section 3 on specifying five different DNS-based mechanisms for finding a certificate repository does not convince me it's either minimal or adequate for the task at hand; except for method 3.1, it requires (as far as I can tell) manually configuring a DNS name for the "service provider", whatever that is. (service provider for the user whose identity is to be verified? how do we find that out? for the user of the service? why not configure the URL rather than the service provider name?)

See also Michael's review - in Comment.
Comment (2004-09-27 for -)
No email
send info
Reviewed by Michael Patton, Gen-ART

His review:

Summary: This draft is basically ready for publication, but has
concerns that should be considered before publication.

As a general comment, although reading the document made my head hurt,
I believe that was just because of all the intricate connections to
other security stuff that I'm just not that familiar with.  Other than
that it seemed reasonably well written and clear, except for one
concern with an over long section (see next paragraph).  I especially
liked the section on being "technology neutral" and suggesting an
implementation using "trained chimpanzees" and "books" :-).



My only real concern is that Section 2.5 seems a bit long.  This
creates some minor readability problems.  If any non-trivial work is
done on the document, I'd suggest breaking it up a bit.  In fact, I
think 2.5 should probably be promoted to a top level section
(i.e. Section 3, bumping the number on following sections) with
subdivisions, however that would require promoting Section 2.6 as
well.  I also note that Section 2.5 duplicates parts of the Security
Considerations but with different words.  I'd suggest that a reworked
Section 2.5 could describe it better and that the Security
Considerations section could just mention it and refer back to the
appropriate subsection, thus making the document more concise.  On the
other hand, the parts of Section 2.5 that duplicate the Security
Considerations could be removed and a simple "additional
considerations are given in the Security Considerations section"
reference used instead.  This might make 2.5 acceptable without the
other changes.  Additionally, it seems there are some items in Section
2.5 that should be included in the Security Considerations, but aren't
(specifically the paragraph starting "Pre-constructed URIs ..." but
maybe others)


The last sentence of the second paragraph of Section 3.5 makes some
unsupported assertions about the difficulty of using CNAME RRs and
their not working across domains.  I don't believe either of those
assertions and think that sentence is at best misleading and
potentially damaging as it may lead readers down the wrong path.



Minor comments:
---------------

At the beginning of Section 2.1 I'd suggest expanding "column in the
tables" to "column in the tables below"

I'd like to suggest that you see if Keith concurs with their
assertions about RFC3205 concerns.

The description (in Section 3.2) of use of DNS SRV RRs should probably
mention the priority and weight fields and their application.  I
assume they intend the default usage from RFC2782, but I think for
completeness that should be explicitly said.

I am somewhat disconcerted by the paragraph at the start of Section
3.5 that states that a certain amount of the complication of this spec
is due to an attempt to be compatible with limitations of aome
implementations of a single vendor, while in Section 2.5 there is a
description of specific non-compatibility with a number of
implementations.  I lament the days when the IETF really was vendor
neutral.


Simple typos:
-------------

Section 2. "an error conditions" => "an error condition"

In the table in Section 2.2, the third column for "name" needs to be
indented one more space.

Several locations: "sanitisation" => "sanitization"

Section 2.5 "provide a slight a performance" =>
	    "provide a slight performance"

Section 3.5 "the mechanism describe here" =>
	    "the mechanism described here"

(Russ Housley) Yes

(Steven Bellovin) No Objection

(Brian Carpenter) (was Discuss) No Objection

(Margaret Cullen) No Objection

(Bill Fenner) No Objection

(Ted Hardie) (was Discuss) No Objection

(Scott Hollenbeck) No Objection

(David Kessens) No Objection

(Allison Mankin) No Objection

(Thomas Narten) No Objection

(Jon Peterson) No Objection

Comment (2004-09-27 for -)
No email
send info
ToC and pagination would be nice.

Off the bat, I'd think that the most important threat against this sort of system would be impersonation of the certificate store by an attacker (passing the wrong certificate back to a querying party). However, the Security Considerations focus largely on threats against the back-end store itself rather than the protocol, so I assume this threat must already be understood to be mitigated (a pointer to somewhere providing that rationale would be handy). Perhaps this is because these certificates are assumed to be self-validating. But what are the implications of the use of this mechanism with self-signed certificates? If the last sentence of 3.1 suggests that self-signed certificates are in scope of this mechanism, I'm surprised that more text isn't devoted to the virtues of HTTPS.

(Bert Wijnen) No Objection

(Alex Zinin) No Objection