RE: NEW Data type for certificate selection ?

[Sarbari Gupta <sgupta@xxxxxxxxxxxx>]

I have been following this thread with great interest. Since the thread
was rekindled, I wanted to offer another usage model that needs a
slightly different selection criterion. I was not sure whether this
model was discussed before on this list.

One of the certificate selection mechanisms in use today is based on
matching the issuer name. SSL implementations allow this form of
selection. There is another variant of this model that may also be
useful. In this variant, the certificate selection is based on a prefix
of the issuer name. For example, the selection may be done based only on
the country name and the organization name components of the issuer DN.
Thus, if a large organization has multiple CAs, the selection criteria
may logically be "a certificate issued by the organization" instead of
the more restrictive "a certificate issued by a particular CA within the
organization".  

Do the X.500 matching rules support this kind of selection? This model
may be useful for SSL connections. It will certainly be useful for
S/MIME implementations; if the peer's certificate is part of an
organization-specific PKI, the S/MIME implementation could conceivably
select an appropriate certificate (for the user) based on a prefix of
the issuer DN of the peer's certificate. Ideally, the S/MIME
implementation would support a configurable set of prioritized selection
criteria that allows the automatic selection of one amongst a set of
user certificates. 

- Sarbari Gupta 
=============================
Sarbari Gupta
CygnaCom Solutions
(703)848-0883 ext 217
sgupta@cygnacom.com
=============================

> -----Original Message-----
> From:	Dwight Arthur [SMTP:dwightarthur@mindspring.com]
> Sent:	Friday, October 09, 1998 3:31 PM
> To:	Stefan Santesson; Alan Lloyd; ietf-pkix@imc.org;
> list@seis.nc-forum.com; cert-talk@structuredarts.com
> Subject:	RE: NEW Data type for certificate selection ?
> 
> 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.