Subject: Attribute Certificates

From: Denis Pinkas <[email-masked]>
Date: Mon, 05 Jul 1999 10:27:39 +0200

Here are my comments on the Attribute Certificate profile for
authorization (ac509prof-00.txt) - avoiding as much as possible
discussions on the encryption option until the Oslo meeting. :-|

First of all, I welcome this document in general because the
support of Attribute Certificate is becoming very important.
However, I have several reservations on its content, because the
current specification is too large and too complex to implement.
Starting "smaller", i.e. with a smaller set of functionality,
would be more adequate.

The following detailed comments follow the page numbering and are
not classified according to their importance.

1. On page 3, there is statement saying : "A major benefit of the
"pull" model is that it can be implemented without changes to the
client and client/server protocol". There is a major drawback to
do so that should be mentioned in the text: The "pull" model,
without *any* change to the client and client/server protocol
does not allow to fulfil the principle of least privilege in that
sense that the client cannot restrict the set of privileges that
will be used by the server to validate the access. In some cases,
this fact may rule out the support of the pull technique.

2. Could we simply rename "AC issuer": "Attribute Authority"
since the acronym AA is used later on ? :-)

3. On page 5. The text says "The following are the requirements
that the "full" profile defined here meets." The basic question
is how many profiles are being defined there. I would expect the
definition of a basic profile (yet to be defined) and of various
additions to the basic profile (like the support of targeting or
proxying) that form other profiles. This topic needs to be
discussed at the Oslo meeting.

4. I would recommend the use of baseCertificateId to link the
attribute certificate to a public key certificate and warn the
reader about the danger to use entityName and thus while still
allowing its use (?) deprecate its use, because it is less
secure. This may also be a good topic to cover in the "security
considerations" section.

5. In the same way I would recommend the use of baseCertificateID
to identify the certificate of the AA instead of the issuerName
that should be deprecated. To this respect I do not agree with
the text in section 4.3.3. that says the contrary (" ACs
conforming to this profile MUST use the issuerName choice which
MUST contain one and only one GeneralName which MUST contain its
non-null value in the directoryName field "). The argument of
dependency upon the PKI is not a really valid argument to support
the choice that is made there: security should come first.

6. The use of issuerUID currently optional should be recommended
because it provides better protection in case of a CA key
compromise. This may also be a good topic to cover in the
"security considerations" section.

7. In section 4.4.1 there is a question about the need to support
restrictions. Restrictions are very difficult to support in a
distributed environment when the push model is used, because
there is no guaranty that all the restrictions will really be
included in the AC. If all were included, in some cases, some
"unwanted" information would be released to target that do not
have the need to know about these restrictions. The simplest
solution is  not to support restrictions.

8. On page 13. There is a section 4.4.3. on AC Targeting and
Proxying. Since I believe that Targeting and Proxying will not be
in the base profile, moving this section later would be more
adequate.

9. Targeting (i.e. targets field) is nice and easy to understand
when used in a connection oriented mode. However, I have a
reservation with the proxy case (proxies field): how is it really
possible to restrict the proxy to the targets which are of the
same "proxy sets" as itself ? How is this verified on the next
leg ? I got the impression that we could support targeting *for a
connection mode* but the support of proxies is more complicated
and the overall model should be clarified before considering
inclusion of proxies and even delegates in this document.

10.On page 16. There is a section 4.5 on Attribute Types. Since I
believe that Attribute Types (with the exception of 4.5.1 and
4.5.7) are part of the base profile, moving this section earlier
would be more adequate.

11. On page 21. There is a section 4.6.1. on AAControls
addressing the question: Is this AC issuer trusted to issue ACs
containing this attribute"? The question itself is fine, however
the answer to the question might not be adequate. It is hard to
answer that question outside the context of use and maybe it is
where the difficulty lies. If this question is to be answered in
a authorization scheme using ACLs, then the answer lies in the
ACL itself, rather than an extension in the certificate as
proposed. It is then up to the ACL manager to state which
attributes from an AA, if ever presented, will be acceptable. The
proposed solution is first very complicated and second addresses
the problem from the wrong side: a CA cannot know in advance
which attributes a given AA is really able to generate. That
section should be deleted.

12. On page 21. There is a section 5. on Attribute Certificate
Validation. The rules that are mentioned there do not allow to
verify an AC that was issued years before and to test its
validity at the time it was issued. This is however a very
important case. The rules for testing the validity of an AC
should thus not be restricted to real time use in a connection
mode environment. The item 3 about the time of evaluation seems
to mean the current time which is not correct. What is the time
of evaluation should be clarified: it should be the time for
which the validation is being requested. The item 1should be
moved in the first position so that it can apply to the current
item 1 where the validity of the certification path must be
checked at that time rather than the current time.

13. aaControls extensions are mandated. On the contrary, it is
not believed (see top of page 23) that any aaControls extensions
should ever be used. Thus the mandatory clauses 1) 2) and 3) from
the additional certification path checks should all be deleted.

14. Some checks are missing in particular when a target field is
present.

15. In general, the description of the various checks should
follow the description of the various profiles, including the
base profile. This section 5 should be re-written to address
these concerns.

16. The section 8 on conformance should define more profiles. The
basic profile should only mandate the support of attributes
linked to a certificate. All other features should be part of
other profiles, like the targeting of a certificate. These other
profiles should be defined. This means that the title of the
document should be changed from "Attribute Certificate profile
for authorization " to "Attribute Certificate profiles for
authorization".

Denis

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 05 Jul 1999 11:58:03 +0100

Denis,

Thanks for the detailed comments (and for not getting back
into attribute encryption:-)

> current specification is too large and too complex to implement.

FWIW, we have implemented the AC issuer and interop'd with a third
party AC acquirer/verifier without much trouble, so I'd disagree 
about the complexity (but then I would, wouldn't I:-)

> this fact may rule out the support of the pull technique.

Fine, I'd prefer to add least privilege as a benefit of the
"push" model though, how about adding something like the 
following to the end of the "In some environments..." para:

"In addition the push model provides better support for least
privilege as a client may be able to select a "minimal" AC
thus not exposing its full privilege to servers."

> since the acronym AA is used later on ? :-)

I don't think I've a problem with this - I'll check 
the text in the next revision.

> discussed at the Oslo meeting.

I agree that this warrants dicsussion, lets see where we get to
in Oslo. 

(*) You've made a number of comments like "this should be earlier 
in the document" related to profiles. Maybe its worth saying how
we came up with the structure - basically we presented requirements
in section 3, sections 4 - 7 describe fields, ASN.1 and processing
stuff and section 8 describes conformance (basic & proxy-enabled
profiles). I guess we should at least have more text up front
explaining this, though of course, it might change depending
on the general "profiles" discussion.

> secure. This may also be a good topic to cover in the "security

I've no problem with that, (in cases where a PKC has been used for
authentication!), though I believe that some other people will have.

> the choice that is made there: security should come first.

I'd prefer not to make this change, but if that's the consensus...
(Amongst other reasons, I quite like the model where a "foreign" AC 
issuer's public key is recertified by a "local" CA.)

> "security considerations" section.

Hmm... I don't think so - the text says that issuerUID must only 
be present if it is also present in the corresponding
PKC and 2459 says UniqueIdentifiers "SHOULD NOT" be present (cf
2459, section 4.1.2.8). How would you handle a case where the 
issuerUID was present in the AC but not in the PKC?

> solution is  not to support restrictions.

I pretty much agree - we left them in there to see if anyone
would shout "I need these", so far, no-one has.

> in the base profile, moving this section later would be more

See (*) above 

> inclusion of proxies and even delegates in this document.

Enforcement of targeting/proxying depends on the AC verifiers.
Properly using the proxies field means that the protocol used
to carry (or reference) the AC must also provide proof about the
connections which preceeded the current connection. The form
of such proof is out of scope here, but I guess we could provide
some more text.

> 4.5.7) are part of the base profile, moving this section earlier

See (*) above

> where the difficulty lies. 

Fair point, it is hard.

> If this question is to be answered in
> attributes from an AA, if ever presented, will be acceptable. 

But if such an ACL scheme is not in use? 

> The

I disagee - in many cases a CA *can* know in advance which 
attributes are allowed (or disallowed) for an AC issuer.
However, I'm wide open to someone providing a better
solution. (One thing we considered but dropped was to
regard the OIDs in the AAControls as being the top of
an arc - so that 1.2.3 in the permittedAttrs field
would also cover an attribute type of 1.2.3.4.5.6.7 
and so on. Can't recall exactly why we dropped this.)

I think we do need some solution since just assuming that
the question is answered by AC verifier configuration (e.g.
via static ACLs) isn't sufficient.

> checked at that time rather than the current time.

I can add some text defining the "time of evaluation" better.

> the additional certification path checks should all be deleted.

No (unless we completely delete aaControls). The additional 
certification path checks are only needed if the AC issuer 
is not directly trusted as an AC issuer. Maybe we should say 
more about this in point 2.

> 14. Some checks are missing in particular when a target field is

Isn't the reference to 4.4.3 sufficient? If not, why not?

> base profile. This section 5 should be re-written to address

See (*) above

> for authorization " to "Attribute Certificate profiles for

See (*) above

Regards,
Stephen.