Internet X.509 Public Key Infrastructure (PKI) Proxy Certificate Profile
draft-ietf-pkix-proxy-10

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?

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.