Subject: Re: Comments on draft-ietf-pkix-proxy-04

From: "Von Welch" <[email-masked]>
Date: Tue, 1 Apr 2003 18:26:02 -0600

Jim,

 Thanks for the comments. I've gone through and responded to each
wither with answers, questions, a different opinion or description of
change to the draft.

Von

Jim Schaad writes (23:36 March 21, 2003):
 > 
 > I have the following comments, questions and issues with the draft:
 > 
 > 1.  Formatting:  You should be starting the first column of the text in
 > column #1 not column #10.  As it currently is laid out, I have problems
 > reading it.

Looking around there doesn't seem to be any convention or rule for
this, though ours is more indented than most. Looking at IDs and RFCs
that start on column 1, I find them really hard to read. Column 4
seems to be fairly common and easier to read, so I've reformatted to
that.

 > 2.  Feel free to ignore this comment.  I have a strong preference for
 > statements to be written if A then B not do B if A.  You have several of
 > this variety.  I find this order of writing difficult to read.
 > 
 > 3.  Feel free to ignore this comment.  I have a strong preference for
 > writing protocol statements in a positive manner.  i.e you MUST do this
 > rather than you MUST NOT do that.  From a testing standpoint I claim
 > that I don't know how to test negivate statements, just positive
 > statements.  
 > 
 > 4.  Section 2.3 - I disagree that if stee wants to go offline, he would
 > leave an agent running on his laptop.  Does this agent restart when the
 > laptop goes back on line?

I don't think this point is really central to the issue and worth
discussing unless you think it is really clouding things. The point in
Steve being offline is that he is not available to perform
authentication. Having the agent run when not on the network doesn't
make sense, but that seems to be going into greater than needed
detail.

 > 5.   Section 2.5 - for item 2 on creating identities, would you
 > considere a self-signed certificate to fall into this category?  If so
 > this might be a better example.

I agree it's worth mentioning and added it.

 > 6. Section 2.6 is defined as non-normative, but has a MAY protocol
 > statement in it.  This should be removed.

The following sentence is the offender:

"In order to make the appropriate PC(s) and EEC available for path
validation, the authentication protocol using the PC (e.g. TLS) MAY
pass the entire PC and EEC chain as part of the authentication
protocol."

I don't think this sentence adds anything. I've deleted it.

 > 7.  Section 3.1 - Certificates are not used to sign anything, keys are.
 > Please remove the statement as it does not have anything to do with the
 > Issuer field.

The sentence in question is:

"A Proxy Certificate MUST NOT be used to sign an End Entity
Certificate or a CA Certificate."

Agreed. This is already covered in 2.6 item 2, sentence deleted.

 > 8.  Section 3 - Add the following statement:  "Certificates issued by a
 > Proxy Issuer MUST include the ProxyCertInfo extension and the extension
 > MUST be critical."

I'm concerned here that the sentence above implies that a Proxy Issuer
is something special (akin to a CA). What I have added is:

"All Proxy Certificates MUST include the Proxy Certificate Information
(ProxyCertInfo) extension defined in this section and the extension
MUST be critical."

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

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

 > 11. Section 3.4 - Is there a desire to be able to determine what subject
 > of the EE that issued the first proxy certificate without having to do
 > the entire chain processing?  This would seem to be difficult by just
 > appending some cn= components to the subject name.

The only way to securely determine the subject of the EE that issued
the first proxy certificate is to process the entire chain since that
is the only way to verify a proxy issuer didn't lie. We considered
adding a short cut but felt that would lead to folks insecurely using
it.

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

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

 > 15.  Section 3.7 - Cannot omit ALL usages in the extKeyUsage extension.
 > The extension requires one be present.

Changed third item to clarify:

The Proxy Certificate's extKeyUsage extension MAY omit any OID that is
present in the issuer certificate's extKeyUsage. Note that the Proxy
Certificate's extKeyUsage extension MUST contain at least one OID.

 > 16.  Section 3.9 - Please remove the version field from the extension.
 > Changes in structure and behavior should be addressed by issuing a new
 > OID for a new extension.

After soliciting some opinions, I agree with you that this is the
right thing to do.

 > 17.  Section 3.9 - Does a CA have a way to do the equivalent of a
 > pCPathLenConstraint in an EEC?

No. We thought about allowing this at one point by having a boolean
bit in the ProxyCertInfo extension to indicate if it was a proxy. This
would have allowed a CA to put a ProxyCertInfo extension into an EEC
and do this, but it complicated things more than we thought it was
worth.

 > 18.  Section 3.9.3, bullet item #1 - Why does this statement start "If
 > the PC includes a proxy policy..." This is a required field is it not.
 > It would seem that this should be "The relying policy understands the
 > policy specified and correctly interpets the policy data."

Old text that slipped through. Changed to:

1) The relying party MUST know how to interpret the proxy policy and the request is allowed under that policy.

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

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

 > 22.  Section 4 - This is a standard, it is independent of you "plans"
 > either CRLs are covered by the standard or they are not.  If the are not
 > then that needs to be explicit.  If they are ditto.

Changed last paragrpah of section 4 to:

At this point there is no mechanism defined for revoking proxy
certificates.

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

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

 > 26. Section 5.4.1 - There is a reference to DelegationTrace extension.

Removed.

 > 27.  ASN Module Problems:
 > 	id-pe is defined twice.

Duplicate removed.

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

I'm don't understand, I'm looking at the definitions in 3.9.3 and they
match both in name and value.

 > 	the END statement is missing.

Added.

 > 	id-mod definition can be removed as it is unused.

Removed.

-end-

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 9 Apr 2003 23:42:04 -0700

Von,

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

Jim

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.

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

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.

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.

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

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.

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

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.

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

> name,  policy> pairs so that I can go find the extra permissions  >

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

 > definitions given in the body of the text with regard to naming of  >
> 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.

---

From: "Von Welch" <[email-masked]>
Date: Sun, 13 Apr 2003 09:55:37 -0500

Jim,

Comments/responses below.

Von

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

 > restricted out without really thinking hard about some cases where this

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.

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

 > the set of proxy policies that are understood by the permission

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

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