Re: AC Scenarios - PULL model

[Steve Hanna <steve.hanna@xxxxxxx>]

Anders Rundgren wrote:
> I think your exposition of Internet Protocols and ACs was very
> interesting. However, I see some problems (maybe due to lack of
> knowledge) with the PULL model in general:
> 
> If we are talking Internet Protocols I guess we should try to decide
> if we are addressing closed PKIs (or closed environments), or the
> open net with many parties of different trustworthiness and
> longevity.
> 
> If we are in a closed ("trusted") environment, AC-like information
> can be gathered by several means including directories.  This is an
> established way of doing things.
> 
> Now, if we instead say that ACs using the PULL model and TLS should
> be used for extranet access we face an AC repository "URL"
> configuration (and access right) problem as AFAIK there is no
> straight-forward way of finding this information in the PKC.
> Particularly not if the AA is disjunct from the CA.

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.

> Conclusion: Solving the AC-PKC binding issue(s) is just one part of
> the AC puzzle.

Well, that's certainly the case!

-Steve