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

["Jim Schaad" <jimsch@xxxxxxxxxx>]

Von,

Comments below.  I was working from what I downloaded before I got on
the plane to fly back, so I was a couple of days out of date, but I just
reviewed the deltas to the -07 version.  I don't see any problems with
added or removed text between -06 and -07.

> -----Original Message-----
> From: Von Welch [mailto:welch@xxxxxxxxxxx] 
> Sent: Wednesday, July 23, 2003 3:32 PM
>
> 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):
>  > 
> 
>  > 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.

I have no objections to using a different method for dealing with this.
I was just trying to come up with a method that made minimal changes to
the document as it currently stands.  

> 
>  > 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.

I can understand the position that the policyLanguage is going to need
to be fixed by the environment.  I think that some text could be added
here about the fact that generally the ProxyCertExtension would be
filled out by the proxy agent and needs to be checked by the PI. It
might be useful in the steps to be explicit about which entity performs
each step.

> 
>  > 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.

Yes, I would like this sentence removed because it is not helpful.

> 
>  >  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.

How about changing " interpret the policy " to "interpret the proxy
policy" in item #1
> 
>  > 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.

Item #1.  Remove all references to key usage and just leave the extended
key usage.  For key usage, this text makes absolutely no sense.

Item #2.  I am not sure that I understand the justification for saying
the if you are independent, then you get to do anything you want, but if
otherwise you are restricted on what you can do.  

> 
> 
>  > 9.  
>  > 
> 
> Is there more that should appear here?

I don't see any item #9 based on a fast scan of the document.  I think I
just missed clearing this out since I did not add a signature to the end
of the message either.

> 
> - end comments -
> 

Jim