Re: End-Entity Certificate Policies

[Mack Hicks <mack.hicks@xxxxxxxxxxxxxxxxx>]

Sandi

As you may well imagine, in our case with many financial institutions
participating in a certificate hierarchy, it is virtually impossible for
all institutions to agree on minor details of policy. Our attempt to
address this issue is to have an overarching  policy that says: this
certificate is part of the hierarchy (proven by cert. path). The other
policies (optional) will be used by institutions to further define their
policies which may have applicability both within the hierarchy and
within other hierarchies.

All the policies domains for the EE are known in advance through
contract between EE and Institution. The relying parties may not know of
a particular EE's additional policy domains, but these can be made clear
by on-line query to the relying party's institution. We see no need to
generate additional certificates or attribute certificates since
additional information can be obtained on-line from the relying party's
institution who communicates with the EE's institution.

Mack

"Miklos, Sue A." wrote:

>
>
> Please forgive a potentially ignorant question, but I am at a loss to
> understand the operational perspective when putting multiple policy
> oids (or any attribute values) into a certificate when it is initially
> generated and signed.  Is the thought that when an EE gets a cert,
> that all of the appropriate policy domains will be known and
> populated, in advance?  Will the addition of subsequent oids require
> generating new certs (and the accompanying revocation of the 'old'
> certs)?
>
> Sandi Miklos
>

--
-------------------------------------------------------------------
Mack Hicks, VP     mack.hicks@bankofamerica.com
Bank of America  +1-415-436-5809