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

["Jim Schaad" <jimsch@xxxxxxxxxx>]

Von,

I've removed those items for which I have no replies.

Jim

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

There is a good reason why we disallow SubjectAltNames in PC's (see my
response to your issue number #13) and suspect this was a carry over.

Let me push back, is there a valid reason to allow an IssuerAltName in a
PC since the Issuer field must be non-empty (i.e. a Proxy Issuer must
have a non-empty Subject)? If not, I'd prefer to keep it out to keep
path validation simpler.

[JLS] One reason for allowing it is that an EE certificate can have a
SubjectAltName, which could be copied into the 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.

We left this open as an option since the unique name is a SHOULD and not
a MUST. I've rewritten this section to clarify:

3.4	Subject

The subject field of a Proxy Certificate MUST be the issuer field (that
is the subject of the Proxy Issuer) appended with a single Common Name
component.

The value of the Common Name SHOULD be unique to each Proxy Certificate
bearer amongst all Proxy Certificates with the same issuer.

If a Proxy Issuer issues two proxy certificates to the same bearer, the
Proxy Issuer MAY choose to use the same Common Name for both. Examples
of this include Proxy Certificates for different uses (e.g. signing vs
encryption) or the re-issuance of an expired Proxy Certificate.

The Proxy Issuer MAY use an approach to assigning Common Name values
that merely ensures a high probability of uniqueness. This value MAY be
the same value used for the serial number.

The result of this approach is that all subject names of Proxy
Certificates are derived from the name of the issuing EEC (it will be
the first part of the subject name appended with one or more CN
components) and be unique to each bearer.

-end new 3.4-

[JLS] I am not really happy about this, but it is acceptable wording.
The problem I have is that a Proxy Certificate bearer is not really a
defined item.

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

(Reference should be item 9 instead of item 7)

The reason for this is that some of the subjectAltName forms are not
hierarchical, so we cannot use our current path validation techniques to
verify the validity of a proxy's SubjectAltName.  This means that
applications will have to locate the EEC to determine things like e-mail
address.

[JLS] The only issue that I have here is that I can see proxy's
potentially being named with some things that might not go well here.  I
don't know if these are real, but could see potentially  wanting to put
IP addresses in as alt names for the proxy.  I hate to see this
restricted out without really thinking hard about some cases where this
might be nice.

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

I believe the third bullet prohibits this.

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

I don't see why this is relevant to 3.6

Question from one of my coauthors:

What this comment seems to be pushing on is whether the signature
algorithm 
can change between the issuer and the subject.  I don't see why not.  In

fact, I can see some value to this, as you might want to secure an EEC
with 
a stronger algorithm and key, but use a lighter weight approach for a 
short-lived PC.  We already change the key length.  What's the problem
with 
change the algorithm?

[JLS]  This is in response to both 13 and 14.  The reason that an RSA
certificate cannot issue a DH certificate, is that an RSA certificate
will assert the keyEncipherment bit, however a DH certificate needs to
assert the keyAgreement bit.  This is not allowed since this is a change
in the set of keyUsage bits in a non-subset manner.  In the same way, a
signing only certificate would have either the digitialSignature or the
nonRepudiation bit set in KeyUsage.  Since the keyEncipherment or
keyAgreement bits are not set, an encryption certificate could not be
issued.  A certificate with only keyEncipherment would be unable to
issue a certificate since the signature operation is not allowed under
its abilities for verification.  This means that in order to issue a
certificate that allows for encryption, you need to start with an RSA
certificate that allows both keyEncipherment and
digitalSignature/nonReudiation.



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

Agreed. Changed to:

2) If the Proxy Issuer is an EEC and the right to perform the requested
action is being inherited from the EEC by the proxy policy, then the
relying party's local policies authorize the request for the entity
named in the EEC.

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

I like your text, but I'd like to keep most of the first sentence that
is there. I have changed this paragraph to:

Note that since a proxy certificate has a unique identity it MAY also
have rights granted to it by means other than inheritance from it's
issuer via its proxy policy. The 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.

[JLS] This reads just fine.

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

The extensions do not appear in PCs.


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

I think you are referring to what happens if the impersonation policy
doesn't appear in the acceptable-pc-policy-set and the you encounter a
proxy with that policy?

In that case, yes it should be a failure, since the relying party
doesn't understand the policy involved. We don't specify currently that
any policy MUST be understood.

In practice I suspect most of the time proxy policies will be ignored
during proxy path validation (i.e. acceptable-pc-policy-set will be
equal to any-policy) and not used until authorization. The
acceptable-pc-policy-set is included in path validation so that a
relying party that handles only inherited rights can fail earlier rather
than later.

[JLS]  If this is the case, then I don't see the benefit of having any
policy work done during validation.  If I pass in an acceptable policy,
I want to say it has policy FOO-BAR.  If there is not the ablity to
create a FOO-BAR chain of policy then it needs to be rejected.  The real
problem however is trying to distinguish between a permission and a
policy.  These are not the same things, but I keep wanting to treat them
as such.  I want to pass in the question "Is there a chain which gives
the permission BLAH to this entity?"  This is basically what happens for
the policy evaluation of identity certificates, and thus I expect the
same type of behavior for this chain validation logic given that you are
using the same term "POLICY".  The correct statement to say for the
initialization statement on policies is "This field is initialized to
the set of proxy policies that are understood by the permission
evaluation code."

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

I agree with this, somehow I was under the impression that the ordered
subject list was also available. I'll add it.

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

Can you elaborate on what you mean here?

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

[JLS]
iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) ppl(21) id-ppl-impersonation(1)
Vs
id-ppl-impersonation   OBJECT IDENTIFIER ::= { id-ppl 1 }

In one case the last number is named, in the other the name represents
the entire OID.  These mean slightly different things in ASN.1.  In one
case it is the entire OID, in the other case is really only represents
the value '1'  Use the full x ::= y in the text and I will be happy.