Re: AC Scenarios - PULL model

[Steve Hanna <steve.hanna@xxxxxxx>]

Anders Rundgren wrote:
> > ac509prof (section 5) says that "The AC issuer MUST be directly trusted
> > as an AC issuer (by configuration or otherwise)." It also says (section
> > 1.1) "This specification deals with the simple cases where one authority
> > issues all of the ACs for a particular set of attributes."
> >
> > Therefore, I expect that the AC verifier will only have a single trusted
> > AC issuer (or one for each set of attributes). Because of this, the AC
> > verifier (in the pull scenarios) should be able to pull all ACs from a
> > single repository or AC issuer (or one for each set of attributes).
> > There is no need for the PKC to include information about where to find
> > ACs. In the AC pull scenarios, the AC verifier will have this
> > information already configured. This model works in either an intranet
> > or an extranet case. The PKC may be issued by a third-party CA. But the
> > AC will always come from the single trusted AC issuer.
> 
> That's my definition of a system that does not scale and have severe
> built-in security problems.  I.e. multi-party update/access to a single repository
> containing fairly dynamic individual-specific information.

When a repository is used with the pull model, a single AC issuer writes
ACs to the repository (presumably with authentication and access
control). One or more AC verifiers fetch ACs from the repository (also
probably with authentication and access control). The issuer,
repository, and verifiers are contained within a single administrative
domain and access to the respository is restricted to authorized parties
(the issuer and the verifiers). The AC holders may be from other
domains, but they need not even know that ACs are being used. I don't
see the scaling issues and "severe built-in security problems" that you
referred to.

Of course, the AC verifiers could also fetch ACs directly from the AC
issuer (via LAAP or a similar protocol). This allows the AC issuer to
issue ACs on demand, which may provide better performance in some
circumstances.

> A single issuer is *not* a requirement so far as I can see.  It that
> really is the case this scheme needs a *major* fix which I BTW see no
> chance of accomplishing.

As I previously noted, ac509prof specifically limits itself to the case
"where one authority issues all of the ACs for a particular set of
attributes." X.509 does not include such a limit. So if this is a
problem (and it would be helpful if you would point out why you think it
is), it could certainly be remedied by removing this restriction from
ac509prof and returning to the less restricted X.509 model.

Frankly, I do not find it useful for you to claim you have found scaling
problems, security problems, or other problems if you cannot describe in
clear and unambiguous terms what those problems are. Vague
pronouncements such as the ones in your most recent notes are more often
the cause of scaling and security problems than a solution to them.

> Question from a directory "Newbe": Can interlinked directories
> administered by the "business parties" themselves, form a virtual
> single repository (and therefore single verifier configuration),
> supporting multiple AC issuers?

It is certainly possible to link multiple directories together to form a
single "virtual repository". In practice, this is often complicated by
firewalls and access control issues. Do you really want to publish your
employee list and even ACs to the world? But I'm not yet convinced that
it is necessary to support multiple AC issuers, especially in the AC
pull model.

In any case, this has little to do with Holder formats.

-Steve