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

From: "Jim Schaad" <[email-masked]>
Date: Wed, 23 Jul 2003 16:01:59 -0400

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.

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?

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.

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?

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.  The text in item 1) just
before this refers to policy and should probably refer to
policyLanguage.

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

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

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

9.

---

From: "Von Welch" <[email-masked]>
Date: Wed, 23 Jul 2003 17:32:04 -0500

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

 > number.  I assume that other methods of doing this are perfectly

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

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

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

 > asking the relying party as to what policy it requires to perform some

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.

 > 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

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),

Agreed.

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

Is there more that should appear here?

- end comments -

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 25 Jul 2003 20:56:13 -0700

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:[email-masked]] 
> 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
> 
>  > 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.

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

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

> 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

---

From: "Von Welch" <[email-masked]>
Date: Sun, 27 Jul 2003 21:14:51 -0500

Jim,

 Given that this document has passed last call and been sent to the
editor, I'm actually not sure what my ability is to make changes at
this point.

 You've pointed out one objective error in 4.1.3, which I will
certainly try to correct. Your editoral suggestions I take note of and
if it is possible to make changes easily will incorporate. You also
suggestion some additions I feel we're past the point of making unless
the community really feels they are necessary.

 One response to your comments below.

Von

 > otherwise you are restricted on what you can do.  

The issue that is being addressed here is that when a proxy is created
that inherits some rights from the issuer (i.e., the policyLanguage is
not independent) the {extended}keyUsage in the proxy certificate
should be constrained by the {extended}keyUsage of its issuer - a
proxy issuer shouldn't be able to grant to proxy certificate a right
they don't have.

It is an independent proxy, in which case our thinking is that it is
no longer inheriting any rights from the issuer, so it can be treated
as completely distinct. The issuer no longer matters in regards to
authorization rights for the proxy, so this means the
{extended}keyUsage constrains (which are really authorization) are now
free to be anything the issuer wants.

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Sun, 27 Jul 2003 19:40:55 -0700

>editor, I'm actually not sure what my ability is to make changes at

You can always issue a new Internet Draft. Doing so is free. :-)

--Paul Hoffman, Director
--Internet Mail Consortium