Comments on ac509prof-01

[Denis Pinkas <Denis.Pinkas@xxxxxxxx>]

First of all, thanks for Stephen and Russ, for providing the
document in time. It has a much better shape and content when
compared to the previous version. I have however several comments:

The document is far too authorization oriented (as the current PDAM
from ISO). While the basic content of the document is in the right
direction, the abstract is not appropriate. The reader does not care
too much about the possible uses of the attribute certificates, but
care about what they are.

The current abstract is:

 Authorization services are required for numerous Internet
protocols,
 including TLS, IPSec, and S/MIME. The X.509 Attribute Certificate
 provides a structure that can form the basis for such services
 [X.509]. This specification defines a profile for the use of X.509
 Attribute Certificates to provide authorization services for
 Internet protocols. Some optional features are also specified which
 are not required for conformance to the base profile.

The document contents however (misplaced in section 4) a very good
abstract that should be reused to replace the current abstract. Here
is a proposal:

   This specification defines a profile for the use of X.509
   Attribute Certificates. Attribute certificates may be used in 
   a wide range of applications and environments covering a broad 
   spectrum of interoperability goals and a broader spectrum of 
   operational and assurance requirements. The goal of this document
   is to establish a common baseline for generic applications 
   requiring broad interoperability and limited special purpose 
   requirements.  In particular, the emphasis will be on supporting 
   the use of attribute certificates for informal Internet
electronic
   mail, IPSec, and WWW applications.


The section 4.2 about Object Identifiers is misplaced, since it is a
recap of what is supported but no explanations are provided at this
time about their rational.


AAControls are introduced in section 4.6.1 where it is said: "

   The AAControls PKC extension, intended to be used in CA 
   and AC Issuer PKCs, *MAY* be used to help answer the question.

However in section 5 on Attribute Certificate Validation we have the
following text:

 2. All PKC's on the path from the AA CA down to and including the
    AC issuer's PKC *MUST* contain an aaControls extension as
defined
    below (the PKC with the AA CA's as subject need not contain
    this extension).
 3. Only those attributes in the AC which are allowed according to
    all of the aaControls extension values in all of the PKCs from
    the AA CA to the AC issuer, may be used for authorization
    decisions, all other attributes MUST be ignored ...

This is contradictory. There are basically at least two environments
where AC can be used: an on-line authorization scheme and a
store-and-forward environment manipulating signed messages linked to
ACs. Only one environment is really addressed here and there is no
reason to impose the use of AAControls to both environments.
Furthermore when using ACs in an on-line access control scheme the
use of AA controls is not a must. If the access enforcement function
uses an authorization scheme using both the name of the Attribute
Authority and the value of the attribute, there is no need to make
sure that the AC is trusted to issue any attribute value. For these
reasons, the use of AAControls is not needed at all. There are two
options: suppress them or make them truly optional.

Other detailed comments

On page 4, we have the following paragraph:

   In other cases, it is more suitable for a client simply to
   authenticate to the server and for the server to request ("pull")
   the client's AC from an AC issuer or a repository. A major
benefit
   of the "pull" model is that it can be implemented without changes
to
   the client or client-server protocol. It is also more suitable
for
   some inter-domain cases where the client's rights should be
assigned
   within the server's domain, rather than within the client's
"home"
   domain.

It would be nice to warn the user about the disadvantages of the
pull model. It is thus proposed to add the following after the
second sentence.

A major disadvantage of the "pull" model is that without any change
a receiving entity does not know which attribute certificate to use
and thus the principle of least privilege cannot be supported. In
addition, all attributes certificates are not necessarily public and
thus instead of providing a complex access control scheme to
restrict the access to those attribute certificates, the scheme is
better suited to public attributes or to attributes used in a closed
domain.

At the top of page 10. The first sentence reads: 
   For any protocol where the AC is passed in an authenticated
message ...

It should be noticed that attribute certificates are not necessarily
used in a protocol, but also in data structures (e.g. a signed
message). The sentence should be changed to:

   For any environment where the AC is passed in an authenticated
message ...


Side comments

Section 4.5.1 is for legacy systems and it is questionable if the
complexity involved by the encipherment does not negate its
practical use. 

In section 4.5.2 (Access Identity), the syntax encourages for a
multiplicity of names, one for each service, whereas the PKI
encourages for the reverse. In fact, in that case attribute
certificates are not more used to carry attributes like roles, but
names instead.

Denis