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

[Ballot comment]
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.

[Ballot comment]
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 second 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.

[Ballot discuss]
There's no IANA considerations section, and in particular no discussion of where policy languages come from.  I would assume that the preferred path would be IETF consensus per 2434, but I could also see the need for private use values and/or a vendor registry.

3.8.1 -- "If the proxyCertInfo extension is not present..." -- shouldn't that be pCPathLenConstraint?

[Ballot comment]
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?

The authors have resolved all of the concerns that I raised.  The updated I-D cannot be posted until IETF 58 is over.  Once the updated I-D appears, the document will be ready for IETF-wide Last Call.

The authors have resolved all of the concerns that I raised.  The updated I-D cannot be posted until IETF 58 is over.  Once the updated I-D appears, the document will be ready for IETF-wide Last Call.