RE: NEW Data type for certificate selection ?

["Dwight Arthur" <dwightarthur@xxxxxxxxxxxxxx>]

I apologize for posting this after the thread has been summarized and
closed. The summary did not mention the part of the discussion that
suggested policy oids as the basis for a solution. I would like to expand on
this.

Selecting the right certificate is an instance of the general problem of
building the right chain. This problem, in turn, needs to be closely aligned
with the trust model being used. Many or most of the examples given were
drawn from the so-called "open" or public model in which parties with no
prior relationship (NPR) establish a (very low) level of trust because
someone in the public CA business has issued a certificate asserting that
the subject produced documentary evidence of a certain identity.

Other models, imho more suitable for significant business use, are:

a. The parties have an existing business relationship and one of the parties
has issued the other a certificate as a token of that relationship. This
certificate is then to be used for access control and signing in facilities
offered by the issuer. I believe that Netscape's crypto.signText() function
provides a fully satisfactory method of saying, "I will only accept
certificates I issued." In addition, the emerging AADS approach supports
this without requiring actual certificates.

b. The parties share a relationship with an intermediary (bank, finance
company, expeditor, factor, etc) who guarantees (for a fee) the parties to
each other. Again, crypto.signText() or equivalents could be used to say, "I
am looking for a certificate issued by MonsterBank" or a slightly more
complex form of AADS could be used.

c. The parties share membership in an organization which, through member
agreements, binds all parties to acceptable business terms and risk
management procedures. Similar procedures can be used as in (b): "I am
looking for your certificate issued by S.W.I.F.T."

d. Each party has a relationship with an intermediary that's a member of an
organization such as described in (c). Now we are looking for something more
complex, like, "I will accept and debit card issued by any bank that
participates in NYCE or CIRRUS but not STAR." These relationships should
imho _not_ be recorded in the client certificates as the data may change
during the life of the certificate. Nor, imho, should the server send a list
of the thousands of member banks as a part of its signing request. Instead,
CIRRUS etc should each establish a certificate policy and form contracts
with each participating bank binding it to the policy. It should register
the policy and obtain an OID, then allow each member bank to issue
certificates bearing the OID. Your bank may then issue a certificate to you
carrying the CIRRUS and STAR oids. I may send a signing request calling for
certificates bearing NYCE or CIRRUS OIDs. Your browser would then respond
with your bank certificate because the CIRRUS OID matched. If you have
several matching certificates (because, for example, you have several bank
cards) the browser would ask you to chose, but the list of alternatives
would be only your CIRRUS or NYCE bank cards and would exclude your drivers
license, your library card, etc. Fraudulent certificates issued by
BongoCerts with the NYCE OID would be defeated either by (1) OCSP to the
NYCE responder, or (2) your browser sends a certificate chain including your
certificate from your bank and your bank's certificate from NYCE.

e. Finally, the model that I personally believe will account for the most
profitable segment of eCommerce: the employee card. I do not want to offer
my employee a certificate for accessing our bank, a separate certificate for
accessing our broker, a separate certificate for accessing our office
supplies vendor, and a separate certificate for accessing her 401K plan.
(Too much overhead, doesn't fit on a smartcard, too much risk that we l miss
one when it's time to revoke.) Instead, I want to offer every employee a
certificate that says, "this is an employee of this company" that allows
access to the benefits plans, the ability to initiate (but not authorize)
office supplies purchases, and access to the appropriate gender washrooms. I
may also offer some employees a different certificate (or an attribute
certificate that supplements the identity certificate) that includes a
policy OID that says, this is an officer, the company stands behind and
honors commitments made by this person. In my cross-certification with the
office supplies vendor, I can map my "this is an officer" policy with the
vendor's "authorized approver of purchases" policy. Further, I could map my
"this is an officer" policy to my bank's "authorized signer" policy or I
could create a different "authorized for high value financial transactions"
policy and map it to the appropriate policies of my bank and my broker.
(Note, I am not inventing this policy mapping stuff, it's straight out of
X.509) Now, when some other bank sends my employee a signing request it asks
for something like "a certificate bearing the authorized signer OID issued
by a bank that's a member of some ACH network." In this case, it is
necessary but not sufficient to select the right certificate. It is further
necessary to build a chain of certificates, leading back to some appropriate
root, with the specifies policies (or mapped policies) at every certificate
in the chain.

Note that I am _not_ advocating roles or authorizations in the certificate.
I am advocating policies, represented by OIDs, that specify issues like
acceptable uses of certificates, applicable communities of interest, etc.
where all subjects, issuers, and authorized relying parties are bound by
contract to the policy.