Re: AC Scenarios - PULL model

["Anders Rundgren" <anders.rundgren@xxxxxxxxx>]

Steve,

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

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? 

Anders