Subject: Re: NEW Data type for certificate selection ?

From: Stefan Santesson <[email-masked]>
Date: Thu, 01 Oct 1998 14:56:18 +0200

There are similarities with phone numbers, but an even better example is to
compare with plastic cards in your wallet.

Say that every plastic card is a certificate given to you to be used in a
certain context. When you by gas you use your petrol card, when you borrow
books you use your library card.

The service context determines which certificate (plastic) you are using.

In a computer environment this is the same. Depending on the service
context you will use different certificates and different private keys for
signatures and decryption.

To day there is no "good" way to communicate the "service context" to the
certificate selecting function in the client. What is proposed here is that
we define a mechanism for this so that a context aware server may help the
client to select a suitable certificate.

This is relevant for a wide range of application and service levels, from
communication services (SSL/TLS) up to application levels (S/MIME and Java
scripts). But regardless of implementation level a general data type could
be used to specify the certificate match rule. X.509 have defined 2
relevant match rules. certificateMatch and certificateExactMatch.

So all we basically have to do is to convince the TLS, S/MIME and Java
peoples to include this in their protocols and client-server products.

/Stefan

At 01:52 PM 10/1/98 +0100, Andreas Berger wrote:
>Is the problem of selecting certificates somewhat similar to the
>selection of telephone numbers?
>
>Example:
>
>have an application select a FAX number for my home phone from an
>address book entry. The numbers itself (the certificate) cannot be
>distinguished from other numbers, it is the attribute name "FAX, home"
>(or something like this) that shows the designated use of the number.
>
>A little difference exists, in that certificates usually contain some
>information about the intended use. But this information is not encoded
>in a uniform way. The decision is usually left to the application (which
>is the problem to be solved here?).
>
>Andreas
>-- 
>Fifty-three percent of Fortune 1000 executives think the
>Arch Deluxe is something that helps to run a computer.
>-- Jericho Communications
>
>
-------------------------------------------------------------------
Stefan Santesson                <[email-masked]>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. +46-40 152211              
216 42  Malmö                   Fax. +46-40 150790              
Sweden                        Mobile +46-70 5247799

PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------

---

From: Anders Rundgren <[email-masked]>
Date: Sat, 3 Oct 1998 09:39:43 +0200

Tony,
>But unless a third party can be relied
>upon to reimburse me for my losses, when I send a digital check to
>"Acme Hardware" and recieve nothing in return, this third party is
>really not much more than a telephone directory.

Well, I do not share your optimism (?) that such problems have technical
solutions because there are only a few digital ways to adjust for human errors.

That there ever will be third parties that guarantee all kind of losses is
highly unlikely. They simply have to guarantee that the certificates they
issue belongs to known entities.  A DUN-number for a company, a
PPIT for a person or a valid credit-card number for a SET-certificate.
And of course run a CA in a sensible way...
That is not rocket-science and we don't need it either!

Biometrical PIN-code replacements will improve the trust you have in clients.

For servers I see few improvements except maybe that some data
can be searched for at public sites.  I.e. they may have to agree to
that to get a certificate of the type that you want to trust.

Just my 2 öre

Anders Rundgren
Senior Internet E-commerce Architect

---

From: "Dwight Arthur" <[email-masked]>
Date: Thu, 8 Oct 1998 15:28:48 -0400

A similar application has been tested by the Internet Council of the
National Automated Clearing House Association (NACHA) - see
www.internetcouncil.org

The Javascript "crypto.signText()" function implemented in Netscape
Communicator 4.04 permits a solution to the issue you describe. One of the
fields passed to the function delineates acceptable certificates, I believe
it is a list of acceptable signers.
--------------------------------------------------
p:(212) 412-8687                     Dwight Arthur
f:(212) 908-2345        Managing Director: Systems
b:(917) 646-6682      National Securities Clearing
[email-masked]        55 Water Street
http://www.nscc.com        New York, NY 10041-0082

-----Original Message-----
From:	[email-masked] [mailto:[email-masked]] On Behalf Of
Stefan Santesson
Sent:	Wednesday, September 30, 1998 10:44 AM
To:	David Horvath; Alan Lloyd
Cc:	[email-masked] '; [email-masked] ';
[email-masked] '
Subject:	Re: NEW Data type for certificate selection ?

David,

Thank's for putting this issue in the right focus.

Alan, I don't suggest any new certificate extensions
Ed, I don't want to define any universal criteria for how certificate
selection SHALL be done or any who decides what for whom, regulations.

All I want to do is to define some mechanisms that CAN be used, if
required, by local PKI-related services in order to make it POSSIBLE for
them to build working services with STANDARD components.

Let me highlight this again and describe a realistic problem relevant to me.

Bank A offer web-based banking applications. This requires the end user to
get a specific certificate issued by Bank A. The certificate and the
corresponding private key is processed through the standard web browser of
the client

Two certificates and private keys are used in the normal process.
1) Certificate for SSL (TLS) security
2) Certificate for non-repudiation protection of Bank transactions.

In addition to these certificates, a specific end-user may be populated
with several other certificates, un-known to the Bank.

The question is. How can this Bank create a web based application without
distributing a customized client plug-in for the purpose. Well the Bank can
get far using Java Scripts but it will fail due to the problem that the
end-user may have to select a certificate.
Believe me, THIS IS TOTALLY UN-ACCEPTABLE FOR A COMMERCIAL BANK APPLICATION.

I realize that today there is no way to do this without distributing
customized plug-in components to end-users, but I strongly would like to se
options developed that helps getting around this. The current matching
mechanism in SSL and TLS is just not good enough to solve the problem.

So If we instead had a standardized matching rule that could be invoked
into protocols and Java Scripts etc, then the situation would be much more
hopeful for the Bank in my case.

They would then construct a match rule that with high probability would
point out the right end-user certificate and invoke that matching rule both
in the TLS protocol and in the Java Script, forming their secure
transaction application.

It wouldn't have to be perfect, just good enough to handle some 95%+ of the
cases as long as the Bank could detect cases where it didn't work. Then the
non-working cases could be fixed by personal customer service.

I see even more use for this matching rule. It could be used in S/MIME so
specify a preferred encryption certificate for replies to a mail. Of course
this matching rule could be used for X.500 directories as well (that's what
it was built for). MY concern here is however not _where_ the certificates
are stored but, how to select 1 of several known certificates regardless of
where they reside.

Comments?
How do wee proceed ?
Could we have any comments from Microsoft and Netscape ?

/Stefan

At 11:15 AM 9/30/98 -0400, David Horvath wrote:
>--- Message on the SEIS mailing list ([email-masked])
>
>Alan,
>
>While I personally agree that X.500 provides a mature and feature rich
>core to implement certificate repositories, I am having trouble
>understanding some of your assertions as to why X.500 is the answer to
>so many problems.
>
>It seems to me that the first step for locating certificates in a
>repository is to define the fields in the certificate object that are a
>prerequisite to perform the match.  Matching rules are a good start and
>foster the thought process required to provide a well designed solution.
>Once the matching rules are defined, a protocol such as DAP or LDAP V3
>with extensions may be used to exploit the matching rules.  In some
>cases, clients may choose not to use the matching rules and retrieve all
>certificates.  Perhaps matching rules are not supported by the protocol
>(LDAP V2 or HTTP), therefore the client will collect all the
>certificates and perform the match locally.  This may be even more
>efficient than submitting multiple searches with different variations of
>matching rules.  It could easily be more efficient to submit one search
>and retrieve 10 certificates, then to submit 3 searches with different
>matching rules each time until the required certificate is found.  This
>should be defined by local policies based on performance analysis.
>
>Once the rules for matching certificates are defined ( and I think X.500
>matching rules are an excellent start ) the distribution model can be
>analyzed.  This is another case where X.500 may be superior to LDAP, but
>unless you have a well planned global infrastructure neither X.500 or
>LDAP can help with the distribution model.
>
>Dave Horvath
>
>Alan Lloyd wrote:
>>
>>
>> Snip
>>
>> ----------
>> From: [email-masked]
>> To: [email-masked]; [email-masked];
>> [email-masked]
>> Sent: 9/29/98 1:01:30 PM
>> Subject: Re: NEW Data type for certificate selection ?
>>
>> Peter - you went through great lenghts to define the problem with
>> relationships between and searching directory based objects and a
>> distributed information issue and then you say:
>> "
>>  If anyone has any useful solutions for this (apart from "We should
>> force
>> everyone to use an X.500 directory, that would solve everything" :-) I'd
>> be interested in hearing them.
>>
>> "
>> Oh well - that counts me out. I cannot do solutions - without the
>> solution :-)))
>> regards alan
>>
>> Peter.
>>
>
>
>----------------- SEIS mailing list ([email-masked])
>Info about this list: http://www.nc-forum.com/seis
>SEIS Contact: [email-masked]
>
>
>

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 12 Oct 1998 13:03:04 +0200

Dwight and Stephen,

Thank you Dwight for valuable information.

Just some remarks.

1) I did not focus on a prticular selecting mechanism such as policy OID
over Issuer Name. I'm looking for selective mechanisms that will work
generally in standard products in closed and in open environments.

2) Selection by policy OID is covered by the discussed X.500
certificateMatch rule

3) Thank you for pointing out that Netscape have mechanisms for slecting
certificate by issuer in crypto.signText(). This was new to mee. I will
check this within our projects.

3) My primary concern is how to manage certificate selection by using
standard products. I'm not focusing on whether this is a closed or an open
PKI. In my cases the PKI is closed in most cases but the problem is still
relevant.

/Stefan Santesson

At 12:13 PM 10/11/98 -0400, Stephen Kent wrote:
>Dwight,
>
>Thanks for a good characterization of the underlying assumptions that have
>been driving much of this discussion. I agree completely!  In a completely
>open, public PKI model, it's very hard to find the "right" certificate and
>I agree that this sort of PKI model is questionable for many reasons, not
>just in a business context.  I'll send you a paper on the topic from last
>fall, separately, that I believe you will find consistent with the views
>articulated in your message.
>
>Steve
>
>

---

From: Sarbari Gupta <[email-masked]>
Date: Mon, 12 Oct 1998 11:28:43 -0400

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
[email-masked]
=============================

> From:	Dwight Arthur [SMTP:[email-masked]]
> Sent:	Friday, October 09, 1998 3:31 PM
> To:	Stefan Santesson; Alan Lloyd; [email-masked];
> [email-masked]; [email-masked]
> 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.

---

From: [email-masked]
Date: Tue, 13 Oct 1998 15:55:04 +0530

Hello,

A sort of tangential question.

I'm not sure if you have glanced through the I-D on Atomic Certificates.

I was just wondering if anyone had any suggestions as to negotiation of
required Attributes for such a setup.
imho, this concept permits hiding from the user lots of gory details about
required attributes, since the setup
permits it to be automated.

There are two questions here :
Negotiating the trusted root  - (will affect chaining, as has been pointed
out)
Negotiating the required Attributes - (will be very different with Atomic
Certificates, imho)

We are thinking of a trial run on Atomic Certificates, and for that, we
need to have a pilot protocol that uses it.

Any comments are welcome.

Thanks,
Regards,
narry

PS: for those who have not read the draft at
http://www.ietf.org/internet-drafts/draft-raghu-atomic-certificates-00.txt
here's a very brief writeup of the concept.

Atomic Certificates are basically X.509v3 certificates containing NO
subject Name, and containing exactly ONE
extension, with criticality bit set to true. The peer is expected to
collect Attribute Certificates, for different attributes
signed by different CAs over a period of time. The peer would mix-n-match
and send to the other peer ONLY those
certificates that are required by the other peer, for validation. All the
Atomic Certificates have the same public key.
The whole thing centers around the concept that Certificates are not
documents that identify an entity, but are
documents that attest to an attribute of an entity.

---

From: Alan Lloyd <[email-masked]>
Date: Thu, 22 Oct 1998 22:46:48 +1000

Comments in line.

snip - disagree with some but:

I don't want to debate LDAP issues; this is a PKI list. Your e-mail
address
suggests that you may work for a company that believes directories are
the
solution to lots of problems.  Personally, I don't share that belief,
but
the more central issues is that I'd like us to not confuse the current
definition of directory services, as defined in X.500 and LDAP, with
some
possible future set of cert validation services.  About 5 years ago we
developed such a service as part of a DARPA program; it validated certs
that a client could not validate because of algorithm incompatability or
similar constraints.  Been there, done that.  However, the better use of
the service was to collect certs and CRLs for the client and deliver
them
in a form to simplify client cert path validation.  That's not an
unreasonable service, but it's a far cry fro asking a third party to do
the
validation for you.

I have answered some of this in another email.. But why is it that there
is little discussion about trust that includes cert validation services,
stability of software or formal information models for PKIs (not just
object definitions and usage? Or discussion that deals with the fact
that trust is derived from sound scaleable system design and
implementation qualitative features (not theoretical objects in an
abstract system)... and that from the real world perspective we must
operationally deal with multiple CA domains and domain agile devices,
etc, etc from different vendors. In addition the "scale" issues do not
get discussed. ie we seem to ignore the issues re 100s of millions of
users that work under dozens of business domains with many certficates
each.... 

IMHO the only way of dealing with this validation and scaling issue from
a system and information perspective is through a distributed directory
service THAT provides the User and Service information ON WHICH
certficates are placed. AND that CAs and validation functions are
processes that are supported by such distributed object oriented, name
based transaction systems and infrastructure.
Labeling things as third party in this model is also incorrect, the
validation service which is directory attached can be ownwd and trusted
by the CA itself. ie is a third party "label" applied mabove a
functional label or an operational label or an implementation quality
label?

In not sharing my belief re directories are the distributed information
systems for supporting global services - can you enlighten me on how you
would deploy a multi domain CA infrastructure in todays world that
enable single point of authentication (information) for users, simple
client software, and how one can deal with such information over a
distributed global area for 100s of Ms of Users, etc.

By not putting the correct perspective on directories in support of
distributed information functions like CAs - all one is doing is
building islands of mechanisms.

eg its like developing lots of customised PABXs.

Is "trust" relying that a service works and is globally scaleable (eg.
the phone system) eg. The Internet is slow .. I will ring the ISP on the
phone system because I know that always works.
or is trust some theory about abstract objects placed in an abstract
security policy on a yet to be defined unscaleable implementation.?

just views and regards alan 

Steve

---

From: Alan Lloyd <[email-masked]>
Date: Mon, 26 Oct 1998 08:56:57 +1100

Stephen, naturally a directory cannot develop key sets, but many of the
customised database being promoted by CAs should be supported by
directory services - otherwise its a proprietary solution with all the
issues of limited scaling all built in. Plus the fact that directories
provide a uniform authentication and access control regime , and
distribution, makes life much mor sensible for those deploying CAs. 
As for verification, the engineering approach with CAs re CRLs and
complex clients, etc, etc and domain agile requirements just means that
a wide scale, distributed  infrastructure, lightweight client, domain
agile device should be taken. 
I accept that single domain, complex clients and bespoke validation
paths may server highly trusted or dedicated enclaves, but there are
other CA areas that need more of an operational and service based
approach.

Adding validation supporting matching rules to directories and/or adding
directory enabled cert validation processes strikes me as the way to go.
I just cannot see how thin, domain agile client software and the system
scaling issues can be dealt with any other way.

But I am open to ideas.

regards alan

> From:	Stephen Kent [SMTP:[email-masked]]
> Sent:	Tuesday, 20 October 1998 9:15
> To:	Alan Lloyd
> Cc:	[email-masked]
> I can appreciate the directory perspective of "CA-ness" but I don't
> think
> that captures all of the issues being raised here.  CAs exist
> independent
> of directories, so many aspects of a CA may not be captured by by a
> purely
> directory-centric view.  Still, to the extent that folks look to
> directories to help with cert selection, it's good to keep in mind
> what
> features a directory can offer to help in addressing this problem.
> 
> steve