Subject: Re: Comments on ac509prof-01

From: Stephen Farrell <[email-masked]>
Date: Sun, 07 Nov 1999 16:52:58 +0000

Hi Denis,

Sorry to take so long to get back, but at least its before
PKIX meets:-)
 
> 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:

Thanks (and, as always, thanks for taking the time to
comment).

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

We'll take this on board and re do the abstract.

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

Mostly there for editing reasons (I didn't want to muck up and miss
one, which is very easy to do). I might move it to the end and make
it some sort of summary.

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

Nope, its taken out of context. The second list quoted only applies
"   3.   If the AC issuer is not directly trusted as an AC issuer (by
        configuration or otherwise), then the AC issuer's certification
        path must satisfy the additional PKC checks described below"
as spec'd in the first numbered list in that section. Maybe the text
could be clearer on this though.

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

Rather not get re-involved in push-good, pull-bad type discussions. 
Its an explicit requirement that this specification doesn't force
one to choose between push/pull. Also, the text you suggest only 
applies if LDAP is used in the pull model, with LAAP, least privilege
and selection are again AC issuer based (if they're needed).

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

ok.

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

Let's not go there again; its specified, its optional, end of story.
(I hope:-)
 
> 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.

Not sure what the impact of accepting this would be, can you clarify?

Regards,
Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 647 7406
61 Fitzwilliam Lane,                    fax: +353 1 647 7499
Dublin 2.                mailto:[email-masked]
Ireland                             http://www.baltimore.com