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

["Von Welch" <welch@xxxxxxxxxxx>]

Jim,

Comments/responses below.

Von

Jim Schaad writes (23:42 April 9, 2003):
 > 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.

You are suggesting copying the SubjectAltName from PI to PC? I'm not
sure we've considered this, but I can't figure out any way it would be
useful since to verify a PC's SubjectAltName a relying party would
need to walk the cert chain back up to the EEC anyways so could just
get the SubjectAltName from the EEC.

As it stands currently the proxies and proxy issuers MUST have a
non-empty subject name so all of our path validation uses subject
names. We intentionally tried to avoid having to deal with the
SubjectAltNames, since we couldn't think of a benefit for them, to
keep path validation simpler.

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

As stated, we couldn't think of a way to allow non-hierarchical naming
allowed in the SubjectAltName while allowing those names to be
validated.

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

This sparked a discussion about the KeyUsage and ExtendedKeyUsage
extensions in PCs and our conclusion was these bits are authorization
policy and should be treated in same manner as the proxy policy. What
this means is that if a relying party is basing a decision on one or
more of these bits in a PC, the relying party needs to verify local
policy as to whether the bits are legally set based on their values in
preceding certificates in the chain. For any policy that we thought up
that could be encoded in path validation to control inheritence, we
also thought of reasonable exceptions (especially for PCs with
independent proxy policies).

The result of this is that we will remove any constraints on the
contents of the KeyUsage and ExtendedKeyUsage in a PC, but make it
clear that relying parties that uses these bits as the basis for
decisions MUST verify that the inheritences of the bits meets local
policy. In general we most policies will probably subset, but we
there may be exceptions in that some sites MAY wish to allow
independent PCs to have any legal KeyUsage or ExtendedKeyUsage fields
and some sites may wish to allow the RSA/DH example as you point out.

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

Right, this is talking about known policies languages and not
permissions. I've made the following change in 4.1.1 to clarify:

(c) acceptable-pc-policy-set: A set of proxy certificate policy
languages understood by the policy evaluation code. The
acceptable-pc-policy-set MAY contain the special value any-policy if
the path validation code should not check the proxy certificate policy
languages (typically because the set of known policy languages is not
known yet and will be checked later in the authorization process).


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

Ah, gotcha. These names now refer to the whole OID.

-end-