Subject: Comments on draft-ietf-pkix-ac509prof-03

From: Denis Pinkas <[email-masked]>
Date: Thu, 25 May 2000 17:39:54 +0200

Comments on document ac509prof-03

Foreword. The comments are numbered and presented in sequence,
following the page numbering of the document. However they are not
all of equal importance.

1. Page 3. Section 1. The introduction is too long and too much
access control oriented. This comment was made originally on the
first version but has not been corrected. Since the last call is now
being made (maybe to trigger reading the whole document in detail),
it is now the time to fix it.

It is important to say first what an AC is and why attributes are
not included in the certificates (before saying what it can be used
for). The proposal which follows has been using the current text
which has been re-shuffled to cover the point. It has also be
augmented to cover the fact that access control is simply one of
three security services able to take profit of the content of an AC.

The following is proposed to replace the whole section 1:

" 1.Introduction

X.509 public key certificates (PKCs) [X.509-97, X.509-DAM, PKIXPROF]
bind an identity and a public key. An AC is a structure similar to a
PKC; the main difference being that the AC contains no public key.
An AC may contain attributes that specify group membership, role,
security clearance, or other authorization information associated
with the AC holder. The syntax for the AC is defined in
Recommendation X.509, making the term "X.509 certificate" ambiguous. 

Some people constantly confuse PKCs and ACs. An analogy may make the
distinction clear. A PKC can be considered to be like a passport: it
identifies the holder, tends to last for a long time, and should not
be trivial to obtain. An AC is more like an entry visa: it is
typically issued by a different authority and does not last for as
long a time. As acquiring an entry visa typically requires
presenting a passport, getting a visa can be a simpler process.

Authorization information may be placed in a PKC extension or placed
in a separate attribute certificate (AC). The placement of
authorization information in PKCs is usually undesirable for two
reasons. First, authorization information often does not have the
same lifetime as the binding of the identity and the public key.
When authorization information is placed in a PKC extension, the
general result is the shortening of the PKC useful lifetime. Second,
the PKC issuer is not usually authoritative for the authorization
information. This results in additional steps for the PKC issuer to
obtain authorization information from the authoritative source.

For these reasons, it is often better to separate this authorization
information from the PKC. Yet, this authorization information also
needs to be protected in a fashion similar to a PKC. An AC provides
this protection; it is simply a digitally signed (or certified) set
of attributes.

An AC may be used with various security services like: 

   1. access control in a client-server protocol environment, 
   2. data origin authentication in either a client-server protocol 
      or a store-and-forward environment, and
   3. non-repudiation in a store-and-forward environment.

PKCs allow to provide an identity to access control decision
functions. However, in many contexts the identity is not the
criteria that is used for access control, but rather the role or the
group-membership of the accessor. This class of access control
functions are called role-based access control.

When making an access control decision based on an AC, an access
control decision function may need to ensure that the appropriate AC
holder is the entity that has requested access. For example, one way
in which the linkage between the request and the AC can be achieved
is if the AC has a reference to a PKC for the requester and that the
private key corresponding to the PKC has been used to authenticate
both the AC and the access request.

ACs may also be used in the context of a data origin authentication
service and of a non repudiation service. In theses contexts, the
attributes contained in the AC provide additional information about
the attributes from the signing entity. This information can be used
to make sure that the entity is authorized to sign the data. This
kind of checking depends either from the context where the data is
exchanged or from the data that has been digitally signed."

In the remaining of the document the bias towards access control
needs to be corrected. To this extend the following change relates
to this argument:

2. Page 4. Section 1.2. End of the first sentence. Delete " to
access control decision functions".

3. Page 4. Section 1.2. This section is too much oriented towards
the benefits of the "pull", whereas "push" is much better. In order
to correct this, it is proposed to add the following sentence at the
bottom of the page 4:

"The additional benefit is that only what the other party "needs to
know" is presented and thus there is no access control to be
exercised on which ACs should be made available to AC users."

4. Page 5. Section 1.2. This section is too much oriented towards
the benefits of the "pull", whereas "push" is much better. In order
to correct this, it is proposed to add the following sentence after
the second paragraph.

"A major drawback of the "pull" model is that it may require to
exercise an access control service to decide which ACs can be pulled
by access control decision functions. It is also less suitable for
some inter-domain cases where the client's right should be assigned
in the client's domain, rather than within the server's domain."

5. Page 6. Client definition. This definition should be modified to
indicate that it is specific to connection mode and access control.
Proposal: In a connection mode, the entity which is requesting the
action for which access control is being exercised.

6. Page 6. Server definition. This definition should be modified to
indicate that it is specific to connection mode and access control.
Proposal: In a connection mode, the entity which requires access
control to be enforced.

7. Page 6. Section 3. The section called "requirements" is
confusing. This seems more a list of design goals, rather than
requirements. Maybe the real question is whether this section should
be called design goals or conformance clauses, ... or even something
else ? A related question : is this section really needed ?

8. Page 6. Section 3. Time/validity requirements: If this is to be
interpreted as a conformance clause, then in many contexts, short
lived ACs are sufficient. Using CRLs or OCSP responses for attribute
certificates makes a much more complicated implementation. The
standard should thus mandate support for short-lived ACs, but not
for long-lived ACs whether it is applicable to AC issuers or AC
verifiers. Change the sentence into: Support for short-lived ACs is
required for both AC issuers and AC verifiers. If this is to be
interpreted as a design goal, then the text should read: "ACs should
be able to be used to carry short-term attributes as well as
long-term attributes.

9. Page 10. Section 4.2.2. Holder. First sentence. We should
RECOMMEND the use of the baseCertificateID and in the conformance
clause mandate its support. Proposed rewording. Instead of: "... the
holder field SHOULD use the baseCertificateID " replace with "...
the use of the baseCertificate in the holder field is RECOMMENDED."

10. Page 11. Section 4.2.2. After the third paragraph of this page,
add: "See the security consideration section which mentions some
name collision problems that may arise when using the entityName
option."

11. Page 11. Section 4.2.2. After the previous addition, add: "
Implementations conforming to this profile are not required to
support the use of the entityName field." 

12. Page 12. Section 4.2.6. Greenwich Mean Time does not exist
anymore and has been replaced by UTC. BTW, UTC and GMT mean the same
time, but standards should reference UTC.

13. Page 12. Section 4.2.6. Last sentence at the bottom, which says
:"AC users MUST be able to handle an AC which, at the time of
processing, has its entire validity period in the future (a
post-dated AC).". The sentence should be expanded to cover the case
of old ACs as well. Proposal: :"AC users MUST be able to handle an
AC which, at the time of processing, has parts of its validity
period or all its validity period in the past or in the future (a
post-dated AC)".

14. Page 12. Section 4.2.9. The first sentence says: "The extensions
field generally gives information about the AC as opposed to
information about the AC holder". The first extension on the next
page negates this statement. It is proposed to replace the sentence
by the following: "The extensions field gives information either
about the use of the AC, the AA or about the AC holder".

15. Page 15. Section 4.3.2. I could not understand the sentence :
"The targetCert CHOICE is only present ..." since in the syntax
there is no CHOICE.

16. Page 17. Section 4.3.6. No Revocation Available. I would move
this extension in a new section 4.2.10 so that we can mandate the
support of that extension for conforming implementations, since this
is what section 6 mandates. I would add: "Implementations conforming
to this profile are required to support the use of the noRevAvail
extension."

17. Page 17. Section 4.4. Attribute types. I would prefer to rename
that section "Useful Attribute types" to show better that none
needed to be supported.

18. Page 17. Section 4.4. About the IetfAttrSyntax. The use of
policyAuthority is interesting. However, there is a potential
security risk here. When using GeneralNames (without further
restrictions) there is no guarantee that the name of the policy
authority is understood in the same way by various AAs and AC users.
Also a name could be re-used creating some ambiguities. 

A name that is unique and cannot be re-used is required for secure
implementations. An OID fulfils this requirement. A URN does not
since the same name can be resold to another organization (and thus
be re-used).

When this field is present, it is thus proposed to RECOMMEND (or
mandate ?) the inclusion of an OID in GeneralNames to point to the
organization and allow the addition of a DN or a URN that may be
used as an *hint* to know the name of the organization.

19. Page 18. Section 4.4.1. Service Authentication Information .
This attribute definition should be moved in section 7.1 since it is
an encrypted attribute.

20. Page 18. Section 4.4.2. Access identity. The name is confusing.
Use "Service Identification" instead of Access Identity would be
much better. An Access Identity is an identity that is
understandable by any service, which is not the case here. Define
SvceAuthInfo here since Service Authentication Information should be
moved in section 7.1.

21. Page 19. Section 4.4.5. Role. I do not see the rational for some
limitations that are introduced here. The text states:

RoleSyntax ::= SEQUENCE {
          roleAuthority   [0] GeneralNames OPTIONAL,
          roleName        [1] GeneralName
    }

The roleAuthority field MUST NOT be used. The roleName field MUST be
present, and roleName MUST use the uniformResourceIdentifier CHOICE
of the GeneralName.

Why must the roleAuthority field NOT be used ? 
Why must the roleName use the uniformResourceIdentifier CHOICE ?
Why is the case of the roleAuthority different from the
policyAuthority ?

22. Page 22. Section 5. Typo: "timelyand"

23. Page 23. Section 6. Why making crlDistributionPoints,
authorityInformationAccess mutually exclusive ? For PKCs we allow
both. So why should we make that restriction for AC ? I would like
to get the rational.

Denis

---

From: Russ Housley <[email-masked]>
Date: Tue, 30 May 2000 18:56:42 -0400

Denis:

I guess that I do not object to the bulk of the rework in the Introduction 
that you propose.  This paragraph is an exception.  I do not agree at all.

>    3. non-repudiation in a store-and-forward environment.

1.  Access control is not limited to interactive protocols.  For example, 
an AC containing clearance may determine whether e-mail should be sent to a 
particular recipient or not.

3.  Some protocols that are defined as interactive have portions of the PDU 
that persist.  For example, signed portions of the SET protocol were 
intended to provide proof that the cardholder's private key was involved in 
the transaction.  I would consider this non-repudiation, or at least 
support of non-repudiation.  I can easily imagine an AC specifying a 
short-term credit limit being included in such evidence.

In other words, I do not think the type of protocol determines which 
security services can be supported by an AC.

Russ