Subject: Proxy -05 comments

From: "Jim Schaad" <[email-masked]>
Date: Sun, 4 May 2003 00:00:38 -0700

Comments are divided into two sections, those of substance and
nit-picking.

Substance:

1.  I still get confused because of the language used between PKC policy
and PC policy.  To clarify this I would like to see the following items
changed:

A) change acceptable-pc-policy-set to acceptable-pc-policy-language-set
B) change any-policy to any-policy-language and assign an OID for this
C) in 4.1.3 (c) the discription of the tuple is harder than it needs to
be.  "containing the certificate subject name, proxyPolicy, key usage
extension..."

2) The following text:
    *  InheritAll, as defined by the oid value iso(1) identified-
       organization(3) dod(6) internet(1) security(5) mechanisms(5) 
       pkix(7) ppl(21) inheritall(1)

	says that the ASN.1 module needs the following change

 id-ppl-inheritall           OBJECT IDENTIFIER ::= { id-ppl 1 } 
	
	to

 id-ppl-inheritall           OBJECT IDENTIFIER ::= { id-ppl
inheritall(1) } 

3)  The following text:
    *  Independent, as defined by the oid value iso(1) identified-
       organization(3) dod(6) internet(1) security(5) mechanisms(5) 
       pkix(7) ppl(21) independent(2)

	says that the ASN.1 module needs the following change

 id-ppl-independent     OBJECT IDENTIFIER ::= { id-ppl 2 } 

	to

 id-ppl-independent     OBJECT IDENTIFIER ::= { id-ppl independent(2) } 

4)  If I have the following chain of certificates, please explain why it
should be rejected

	EE	subject="cn=me"
	PC1	subject="cn=me,cn=1"  Policy=id-pp-inheritall
	PC2	subject="cn=me,cn=1,cn=1" Policy=MySpecialPolicy
	PC3	subject="cn=me,cn=1,cn=1,cn=1" Policy=id-pp-independent

If I set acceptable-pc-policy-set to "inheritall, independent" this get
rejected, but the evaluation code would seem to be fine in terms of
evaluating this policy as MySpecialPolicy does not get involved in
making any proxy decisions for PC3.  It's proxy rights are independent
of any previous statements.

Nits:

1.  Certificates don't issue anything, holders of certificates issue
things.  In section 2.1 I suggest the following text:

  * PI: A "Proxy Issuer" is an entity with an End Entity Certificate or
a Proxy Certificate that issues a Proxy Certificates.

2.  Sec 3.8 - second to last paragarph.  MUST NOT rather than MUST not
--- alt. MUST be absent.

3.  inheritAll and Independent oid definitions in the text.

4.  I don't like this sentence for independent.

       The only rights this PC has are those granted explicitly to it. 

	I suggest

	The only rights the holder of this PC has are those explicitly
granted by other  means than the proxy certificate.

Jim

---

From: "Von Welch" <[email-masked]>
Date: Wed, 7 May 2003 15:38:54 -0500

Jim,

Responses and questions below.

Thanks,

Von

 > A) change acceptable-pc-policy-set to acceptable-pc-policy-language-set

Done.

 > B) change any-policy to any-policy-language and assign an OID for this

In keeping with the naming for other policy language OIDs I changed
the name to id-ppl-anyLanguage and got an OID for it.

 > be.  "containing the certificate subject name, proxyPolicy, key usage

Changed.

 >  id-ppl-inheritall           OBJECT IDENTIFIER ::= { id-ppl

I'll admit I'm past my level of ASN.1 knowledge here. Is there a
semantic difference between what I have and what you are suggesting or
is this syntax for the compiler? My concern here is what is there is
what I was assigned, if what you are suggesting is equivalent I have
no problem with it and will change it.

 >  id-ppl-independent     OBJECT IDENTIFIER ::= { id-ppl independent(2) } 

Ditto response to #2.

 > of any previous statements.

The intent was to allow for conditions of use to be expressed in
policies that would be unsafe to ignore. For example, a policy could
state that a relying party must check a CRL at http://xxxxx before
using the proxy. However, reviewing 3.8.2 I see that we never about
this and I can see your point of view.

I believe what you are suggesting is that any unrecognized policy
should be treated as id-ppl-independent?

Let me run this by a coauthor or two and get back to you.

 > a Proxy Certificate that issues a Proxy Certificates.

True enough. I added a little text here to keep the relationship we
were trying to express:

* PI: A "Proxy Issuer" is an entity with an End Entity Certificate or
Proxy Certificate that issues a Proxy Certificate. The Proxy
Certificate is signed using the private key associated with the public
key in the Proxy Issuer's certificate.

 > 2.  Sec 3.8 - second to last paragarph.  MUST NOT rather than MUST not

Corrected to "MUST be absent".

 > 3.  inheritAll and Independent oid definitions in the text.

Agreed. I've removed the definitions in the text and added a
reference to Appendix A.

 > granted by other  means than the proxy certificate.

But this isn't technically correct as there could be rights granted
directly to the identity in the PC.

-end-

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 8 May 2003 10:15:09 -0700

Von,
>  > Comments are divided into two sections, those of substance 
> and  > nit-picking.  > 
>  > Substance:
>  > 
>  > 2) The following text:
> I'll admit I'm past my level of ASN.1 knowledge here. Is 
> there a semantic difference between what I have and what you 
> are suggesting or is this syntax for the compiler? My concern 
> here is what is there is what I was assigned, if what you are 
> suggesting is equivalent I have no problem with it and will change it.

No they are not the exactly the same, but this is what the is in the
body of the text.  An alternate is to change the text to 

id-pp-inheritall ::= .... 

But the text in the body and the text in ASN.1 module need to match.

>  > 4)  If I have the following chain of certificates, please 
> explain why it  > should be rejected  > 
>  > 	EE	subject="cn=me"
>  > If I set acceptable-pc-policy-set to "inheritall, 
> independent" this get  > rejected, but the evaluation code 
> would seem to be fine in terms of  > evaluating this policy 
> as MySpecialPolicy does not get involved in  > making any 
> proxy decisions for PC3.  It's proxy rights are independent  
> The intent was to allow for conditions of use to be expressed 
> in policies that would be unsafe to ignore. For example, a 
> policy could state that a relying party must check a CRL at 
> http://xxxxx before using the proxy. However, reviewing 3.8.2 
> I see that we never about this and I can see your point of view.
> 
> I believe what you are suggesting is that any unrecognized 
> policy should be treated as id-ppl-independent?
> 

I wasn't really thinking that the PC2 policy was the same as
independent, just the fact that it's not relevent as all inherited
rights (from policy) are now ignored by the independent.

> Agreed. I've removed the definitions in the text and added a 

This takes care of problems 2 and 3 above.

> But this isn't technically correct as there could be rights 
> granted directly to the identity in the PC.

I don't see the difference between these staements.  The holder of the
PC has an identity, rights granted directly to that are done by means
other than the proxy certificate.

Jim

---

From: "Von Welch" <[email-masked]>
Date: Thu, 8 May 2003 13:40:30 -0500

> rights (from policy) are now ignored by the independent.

Imagine your chain above ended with PC2 and you didn't recognize it's
policy language. In terms of processing, when an unrecognized policy
language is encountered the two choices would be to either fail or
proceed and treat PC2 as independant (no rights inherited from PC1).

 > other than the proxy certificate.

Your wording leads me to believe the PC is ignored entirely - the
only rights are those "granted by other means than the proxy
certificate". This to me includes the PC identity as well as inherited
rights.

How about the following?

<quote>
The only rights the holder of this PC has are those granted by means
other than inheritance from it's proxy issuer (e.g. rights issued
directly to the identity in the proxy certificate).
</quote>

Von

---

From: Laura Pearlman <[email-masked]>
Date: Thu, 08 May 2003 15:20:51 -0700

> proceed and treat PC2 as independant (no rights inherited from PC1).

I think that the proxy processing should support policies that are
intended to prevent the use of compromised certificates (for example,
policies that enforce certificate revocation mechanisms or that say
that a proxy certificate is valid only from one host).  If
MySpecialPolicy in the example above is such a policy, and a relying
party ignores it while evaluating PC3, then the danger is that PC2 may
have been compromised, and some third party may have used the
compromised PC2 to create an independent proxy (PC3') with the same
subject name as PC3.  Even though PC3 itself does not grant any rights
to its bearer, it's possible (and likely) that additional rights will
have been granted to PC3 via some external mechanism -- which means
that if MySpecialPolicy is ignored, then a third party can use PC3' to
gain whatever rights have been (externally) granted to the holder of
PC3.

So I think there are two reasonable alternatives:  either always fail
when an unrecognized policy is encountered, or change ProxyPolicy
to include the concept of critical and non-critical policies.

		-- Laura

---

From: "Von Welch" <[email-masked]>
Date: Thu, 8 May 2003 22:05:40 -0500

Laura, Jim:

 While I see both your points (critical/non-critical policies and
being able to ignore unrecognized policie languages in certain
situations), I'm inclined for the sake of simplicity to stick with a
relying party failing if a unrecognized policy language is found. This
leaves the door open for the possibility of "conditions of use"
polcies in the future.

 It also seems safer to me in that we really haven't thought through
all the subtleties of loosing the restriction, so I'd prefer not to at
this point in the game unless one of you feels has a strong use case.

Von

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 8 May 2003 20:03:52 -0700

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Von Welch
> Sent: Thursday, May 08, 2003 11:41 AM
> To: [email-masked]
> Cc: 'IETF-PKIX'
> Subject: RE: Proxy -05 comments
> 
> 
> 
>  > > I see that we never about this and I can see your point 
> of view.  > > 
>  > > Let me run this by a coauthor or two and get back to you.  > 
>  > I wasn't really thinking that the PC2 policy was the same 
> as  > independent, just the fact that it's not relevent as 
> all inherited  > rights (from policy) are now ignored by the 
> independent.
> 
> Imagine your chain above ended with PC2 and you didn't 
> recognize it's policy language. In terms of processing, when 
> an unrecognized policy language is encountered the two 
> choices would be to either fail or proceed and treat PC2 as 
> independant (no rights inherited from PC1).

I agree in this case there would be a failure at the time of evaluation
for rights.  I don't believe in the case listed above that I need to do
any evaluation of the rights for PC2 if PC3 exists. 

>  > I don't see the difference between these staements.  The 
> holder of the  > PC has an identity, rights granted directly 
> to that are done by means  > other than the proxy certificate.
> 
> Your wording leads me to believe the PC is ignored entirely - 
> the only rights are those "granted by other means than the 
> proxy certificate". This to me includes the PC identity as 
> well as inherited rights.
> 
> How about the following?
> 
> <quote>
> The only rights the holder of this PC has are those granted 
> by means other than inheritance from it's proxy issuer (e.g. 
> rights issued directly to the identity in the proxy 
> certificate). </quote>

I have no problems with this text.

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 8 May 2003 20:07:33 -0700

Laura,

Now you are changning the meaning of this.  The Policy Language gives
rights, not additional items to be enforced.  The only right that is of
interest here is the right to issue a PC, which is controled by a
different field here (I don't have the name in front of me at the
moment).

Things like CRLs should be dealt with by advertising them, not by adding
other things that say you need to check a CRL before using this.
Remember that policy is evaluated by a completely different piece of
code that the chain evaluation code.  Thus the two should not mix for
purposes of standards.

jim

> [mailto:[email-masked]] On Behalf Of Laura Pearlman
> Sent: Thursday, May 08, 2003 3:21 PM
> To: Von Welch
> Cc: [email-masked]; 'IETF-PKIX'
> Subject: Re: Proxy -05 comments 
> 
> 
> 
> Von Welch writes:
> >
> recognize it's 
> I think that the proxy processing should support policies 
> that are intended to prevent the use of compromised 
> certificates (for example, policies that enforce certificate 
> revocation mechanisms or that say that a proxy certificate is 
> valid only from one host).  If MySpecialPolicy in the example 
> above is such a policy, and a relying party ignores it while 
> evaluating PC3, then the danger is that PC2 may have been 
> compromised, and some third party may have used the 
> compromised PC2 to create an independent proxy (PC3') with 
> the same subject name as PC3.  Even though PC3 itself does 
> not grant any rights to its bearer, it's possible (and 
> likely) that additional rights will have been granted to PC3 
> via some external mechanism -- which means that if 
> MySpecialPolicy is ignored, then a third party can use PC3' 
> to gain whatever rights have been (externally) granted to the 
> holder of PC3.
> 
> So I think there are two reasonable alternatives:  either 
> always fail when an unrecognized policy is encountered, or 
> change ProxyPolicy to include the concept of critical and 
> non-critical policies.
> 
> 		-- Laura
>

---

From: "Von Welch" <[email-masked]>
Date: Fri, 9 May 2003 10:11:23 -0500

Jim,

 Our emails crossed last night, but I'm still holding my opinion that
while I think you may be right in that we could allow this behavior,
I'm concerned about making this change for two reasons: 1) encoding
this will be difficult - you now have to look ahead to figure out if a
failure to understand a policy language is critical or not and 2) this
change seems risky due to lack of thought about it and it potentially
opens holes in the current model which I see as being safer since it
fails on any unrecognized policy language.

 So I would like to deferr considering this change until a future
specification when we've had more experience and time to think about
it unless you think it's absolutely critical.

 I'm going to go ahead and push a new version of the draft today with
the minor corrections from the last week.

Von