Internet X.509 Public Key Infrastructure (PKI) Proxy Certificate Profile
Note: This ballot was opened for revision 10 and is now closed.
(Russ Housley) Yes
(Harald Alvestrand) No Objection
(Steven Bellovin) (was Discuss) No Objection
(Margaret Cullen) No Objection
(Bill Fenner) No Objection
(Ned Freed) No Objection
Comment (2003-12-05 for -** No value found for 'p.get_dochistory.rev' **)
Nits: Section 3.8.2 item 1) "The relying MUST party know how to" -> "The relying party MUST know how to" Section 3.8.2 item 3) a. Non-ASCII character appears where an apostrophe should be. Section 4.1.5 title "Proceedures" -> "Procedures" Appendix B should be marked as needing to be removed prior to publicaton. Questions: This document defines two policy language OIDs (basically "all" and "none"). Presumably more policy language OIDs will be defined. Does it make sense to have a registry for these things, or are these going to be so fine-grained attempting to register even some of them would be pointless? Is OCTET STRING necessarily the right data type for policy values? What if the policy language specifies policies using ASN.1? (I realize you can put arbitrary stuff inside an OCTET STRING, however, in X.400 P2 ASN.1 objects are stuffed inside of a P1 OCTET STRING field, and handling them in a single pass was a nightmare.) Some applications of these sorts of certificates seem to me to involve on-the-fly generation of new certificates. Additionally, each of these certificates is supposed to contain its own public/private key pair (2.6 item 3), and generating such key pairs can be expensive. Should the potential for service denial attacks on automatic proxy certificate generators be mentioned in the security considerations section?
(Ted Hardie) No Objection
Comment (2003-12-17 for -** No value found for 'p.get_dochistory.rev' **)
This isn't a DISCUSS, but I was disturbed by the fact that section 2.7's advertising supplement on ease of use contained this: . For many users, properly managing their own EEC private key is a nuisance at best, and a security risk at worst. One option easily enabled with a PC is to manage the EEC private keys and certificates in a centrally managed repository. When a user needs a PKI credential, the user can login to the repository using name/password, one time password, etc. Then the repository can delegate a PC to the user with proxy rights, but continue to protect the EEC private key in the repository. From my reading, this mechanism is way, way different from the motivation given in section 2.3 and dear old Steve's file transfer. It seems in particular to make this section of 2.4 problematic: One concern that arises is what happens if a machine that has been delegated the right to inherit Steve's privileges has been compromised? For example, in the above scenario, what if the machine running the file transfer service is compromised, such that the attacker can gain access to the credential that Steve delegated to that service? Can the attacker now do everything that Steve is allowed to do? The answer in the case of the attacker taking over the centrally managed repository,seems to be a resounding "Yes!" I realize that this is not actually quite the "delegated right to inherit" being discussed above, since that scenario seems to have Steve getting the time-limited delegated right to his own privileges, but it is still a bit worrying. The Security considerations doesn't seem to cover this at all. I don't think this has any great impact on the working of the protocol, but I would personally suggest ripping the advertising supplement text there right out or putting in the salient Security Consideration of "If you delegate users proxy rights from a central managed repository of their own certificates, boy are you in trouble if someone gets your repository". It may sound obvious, but it probably needs to be said.