Subject: Comments on draft-ietf-pkix-proxy-04

From: "Jim Schaad" <[email-masked]>
Date: Fri, 21 Mar 2003 23:36:54 -0800

I have the following comments, questions and issues with the draft:

1.  Formatting:  You should be starting the first column of the text in
column #1 not column #10.  As it currently is laid out, I have problems
reading it.

2.  Feel free to ignore this comment.  I have a strong preference for
statements to be written if A then B not do B if A.  You have several of
this variety.  I find this order of writing difficult to read.

3.  Feel free to ignore this comment.  I have a strong preference for
writing protocol statements in a positive manner.  i.e you MUST do this
rather than you MUST NOT do that.  From a testing standpoint I claim
that I don't know how to test negivate statements, just positive
statements.  

4.  Section 2.3 - I disagree that if stee wants to go offline, he would
leave an agent running on his laptop.  Does this agent restart when the
laptop goes back on line?

5.   Section 2.5 - for item 2 on creating identities, would you
considere a self-signed certificate to fall into this category?  If so
this might be a better example.

6. Section 2.6 is defined as non-normative, but has a MAY protocol
statement in it.  This should be removed.

7.  Section 3.1 - Certificates are not used to sign anything, keys are.
Please remove the statement as it does not have anything to do with the
Issuer field.

8.  Section 3 - Add the following statement:  "Certificates issued by a
Proxy Issuer MUST include the ProxyCertInfo extension and the extension
MUST be critical."

9.  Section 3.2 - Please justify this section.  I know of know reason
why an IssuerAltName should not be allowed in a PC.

10.  Section 3.4 - I have a problem with the requirement that a subject
be unique.  This means that I cannot issue both a signing PC and an
encryption PC to a single proxy agent.  Depending on the algorithm set a
single certificiate cannot be used for both operations.

11. Section 3.4 - Is there a desire to be able to determine what subject
of the EE that issued the first proxy certificate without having to do
the entire chain processing?  This would seem to be difficult by just
appending some cn= components to the subject name.

12.  Section 3.5 - Ditto of item 7.  I can see needing to potentially
define how to do some conversions, are you just trying to avoid that
problem?

13. Section 3.6 - Signing only certificate cannot issue encrypting
certificate.

14.  Section 3.6 - RSA certificate cannot issue DH certificate.

15.  Section 3.7 - Cannot omit ALL usages in the extKeyUsage extension.
The extension requires one be present.

16.  Section 3.9 - Please remove the version field from the extension.
Changes in structure and behavior should be addressed by issuing a new
OID for a new extension.

17.  Section 3.9 - Does a CA have a way to do the equivalent of a
pCPathLenConstraint in an EEC?

18.  Section 3.9.3, bullet item #1 - Why does this statement start "If
the PC includes a proxy policy..." This is a required field is it not.
It would seem that this should be "The relying policy understands the
policy specified and correctly interpets the policy data."

19.  Section 3.9.3, bullet item #2 - This does not seem to be a correct
statement, what if the policy is Independent, it would be indepent of
the EEC's authorizations.  In such a case the proxy could have MORE
abilities that the EEC would imply.

20.  Section 3.9.3 - Paragraph starting "Note that since..." When I
finally got the last sentence parsed, I think I agreed with it.  I would
like to see it written in a clearer manner so I don't have read it
multiple times to understand it.  

Suggested text - Te rights granted to the bearer of a PC are the union
of the rights granted to the PC identity and the inherited rights.  The
inherited rights consist of the intersection of the rights granted to
the PI identity intersected with the proxy policy in the PC.

21.  Section 4 - What about all of the Policy information that was built
in the EEC path validation algorithm.  Is this suppose to be passed in
or are the extensions not to appear in a PC.

22.  Section 4 - This is a standard, it is independent of you "plans"
either CRLs are covered by the standard or they are not.  If the are not
then that needs to be explicit.  If they are ditto.

23.  Section 4 - policies evalution is messed up big time.  At a minimum
you need to put in specialized processing rules for id-ppl-impersonation
and possibly for independent as well.  Consider the following:  I ask
for a specific policy, I find a PC with with impersonation - according
to the rules I must reject the PC chain, but I am sure that is not the
desired behavior.

24.  Section 4 - How does it help to have the proxy_policy_list as an
output of the process?  I would think that I need a list of <subject
name,  policy> pairs so that I can go find the extra permissions
associated with the subject name.

25.  Section 4 - If ACs are to be permitted for anybody other than the
leaf PC, this needs to be folded into the validation algorithm.

26. Section 5.4.1 - There is a reference to DelegationTrace extension.

27.  ASN Module Problems:
	id-pe is defined twice.
	id-ppl-impersonation and id-ppl-independent do not match the
definitions given in the body of the text with regard to naming of
either the OID or the last intenger in the oid string.  The version in
the ASN.1 file is the correct method of naming.
	the END statement is missing.
	id-mod definition can be removed as it is unused.

---

From: "Von Welch" <[email-masked]>
Date: Sat, 22 Mar 2003 10:41:21 -0600

Jim,

 Thanks - this is good feedback. We will go through your items, most
look very reasonable. We'll issue a new draft as well as responding to
your note directly.

Von