Subject: RE: End-Entity Certificate Policies

From: "Miklos, Sue A." <[email-masked]>
Date: Thu, 2 Sep 1999 08:55:48 -0400

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

-----Original Message-----
From: Mack Hicks [mailto:[email-masked]]
Sent: Wednesday, September 01, 1999 11:18 AM
To: Sharon Boeyen
Cc: 'Charles Moore'; [email-masked]'; [email-masked]'
Subject: Re: End-Entity Certificate Policies

Sharon,

I agree with you. I have a real business need for multiple OIDs in an End
Entity
Certificate.

In the Identrus community, all certificates under the Identrus Root must
have
the OID of Identrus. It is expected that relying parties may be receiving
certificates from multiple participants and sub-CAs within the structure. It
is
easier for the relying party to be able to identify an Identrus certificate
and
its context of use through the Identrus OID. Restricting the number of OIDs
means that the relying party has no way of determining a membership in a
broader
community. Further, the sub-CAs have no way for providing further policy
context
of an end-entity certificate. (I realize that cert path validation would
identify these communities, but the relying party may not have all the
certificates in the path.)

I do not see the any advantage to mandating  only a single OID in an EE
certificate. From a business view, the result is to proliferate the number
of
policy documents.

Mack Hicks

Sharon Boeyen wrote:

> I don't support limiting to a single policy OID or limiting the use of
> qualifiers only to end-entity certs. Even if this was agreed as part of
> the PKIX profile for what CAs were to do, relying parties presumably would
> need to be able to deal with certs that were created outside of PKIX and
> these might very well have multiple policies in the end-entity certs and
> qualifiers in the CA certs. So at best this proposal might impose limits
> on CA behavior for PKIX CAs, but probably couldn't on PKIX relying parties
> unless we want to isolate the PKIX world from the rest of the world :-(
>
> Sharon
>

--
-------------------------------------------------------------------
Mack Hicks, VP     [email-masked]
Bank of America  +1-415-436-5809

---

From: Mack Hicks <[email-masked]>
Date: Thu, 02 Sep 1999 08:51:23 -0700

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:

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