Internet X.509 Public Key Infrastructure Operational Protocols: Certificate Store Access via HTTP
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 -)
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 -)
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.