Re: Draft-ietf-pkix-proxy-06.txt

["Von Welch" <welch@xxxxxxxxxxx>]

Jim,

Comments below. We released version -07 that crossed your email by the
way, but with one exception noted below all your questions still
apply.

Von

Jim Schaad writes (16:01 July 23, 2003):
 > 
 > 1. Section 3.3, para 2:  I think that the MAY in this paragrah should be
 > lower case.  I do not see these as a protocal statements, but as saying
 > these are ways that reasonable uniqueness could be obtained for a serial
 > number.  I assume that other methods of doing this are perfectly
 > allowable.

(You mean both MAYs, right?) I think you are right, maybe someone else
can confirm.

 > 2. Section 3.4:  Does the subject name need to be "unique" among all
 > certificates ever issued by a proxy, or just the active certificates?

Ever, unless it's reissuance to the same bearer as described in
paragraph 3.

 > 3. General:  I am still not comfortable that the issuance of Proxy
 > Certificates cannot be restricted (or permitted) by a CA when it issues
 > an EEC.  One method of doing this would be a non-critical ProxyCertInfo
 > extension with a pCPathLengthConstrant of 0 in the EEC.

I really dislike your suggested method because that would make the
presence of a ProxyCertInfo extension ambiguous - right now it
designates a certificate is a proxy certificate. *IF* this is
something that people think is critical, I believe another extension
should be defined to be placed into an EEC to prohibit it from issuing
proxy certificates.

 > 4. Section 2.6:  When creating a new PC, where and how is the
 > negotiations on policy language and policy done?  Should this be
 > documented as a separate step in the text describing how PCs are
 > obtained/issued?  Does something need to be done about potentially
 > asking the relying party as to what policy it requires to perform some
 > task?

Since it is not always possible to even know who all the relying
parties potentially are when a proxy certificate is issued it's not
really possible to negotiate this. Our view is that the set of polices
used in a particular environment will be established out of band in
the environment.

 > 5. Section 3.8.2:  I find the following text
 > 
 >     Note that this 
 >     verification MUST take place regardless of whether or not the PC 
 >     itself contains a policy, as other PCs in the signing chain MAY 
 >     contain conditions that MUST be verified. 
 > 
 > 	to be confusing because I always get policyLanguage and policy
 > mixed up.  I think that all PCs must have policy and so the statement is
 > difficult to parse.  I don't know that this can be simplified without
 > renaming the policy field in the extension.

I think this statement is from when polices were optional and
impersonation was implied otherwise. If it causes real heartburn I
believe it can be removed at this point as it doesn't add anything.

 >  The text in item 1) just
 > before this refers to policy and should probably refer to
 > policyLanguage.

I don't think this would be correct - as understanding the policy
implies understanding the policy language in which it is written, so
the change doesn't add anything, and a relying party need to
understand not just the language, but the policy itself.

 > 6.  Section 4.1.3 next to last paragraph.  Text should be "If steps (a),
 > (b) or (d) fail,..."

Agreed.

 > 7.  Section 4.2:  I have a complete lack of understanding for the last
 > three paragraphs in this section.

These paragraphs are addressing whether or not the {extended} key
usage extensions of it's issuer apply to it. It's really ugly because
these extensions are really ugly (they are in part restrictions and in
part capabilities), I'm not sure how to clarify this.


 > 8.  Section 5.1.2:  Fix "Section Error! Reference source not found"

This was fixed in -07.

 > 9.  
 > 

Is there more that should appear here?

- end comments -