Subject: Question: Using Certificate Extensions for Applications

From: Keith Johnston <[email-masked]>
Date: Thu, 18 Mar 1999 16:22:26 -0600

Hello all,

I am on a project where we want to use digital certificates to
authenticate various server processes to each other over SSL.  What we'd

like to do is define a certificate extension that has the name of the
server in it, and then have each customer create certificates with the
standard fields (organizaiton, country, etc) set to their information,
and the extension field set to the name of the server.

But the question I have is - will Verisign or Entrust (or any other
well-known CA) sign these certificates with the extension field?  I
don't see how they could, since they would have no way of verifying, for

example, that the person applying for the certificate even had a copy of

our software.

Is there any standard way of doing this?

Thanks,
Keith Johnston

---

From: Keith Johnston <[email-masked]>
Date: Thu, 18 Mar 1999 17:44:48 -0600

Hello all,

How do I go about getting an OID for my own private certificate extension.
I'd like to make sure it doesn't collide with any existing OIDs.  Or perhaps
there is an existing OID that I could use.  The field I want to put into the
certificate is essentially application-specific information, identifying one
server out of many.  Seems like something that a lot of distributed
applications would need.

Any info would be appreciated.

Thanks,
Keith Johnston

---

From: Stephen Kent <[email-masked]>
Date: Fri, 19 Mar 1999 13:02:06 -0500

Keith,

>and the extension field set to the name of the server.

I would stgrongly recommend against creation of an extension for this
purpose. What you seem to want is a cert that identifies a user executing a
process on a server.  If so, then you should issue a cert that has a
subject name with sufficient info to uniquely identify the processes in
question.  X.509 has a naming model that presumes that the subject name
uniquely identifies the subject, period.  If the intent here is to identify
the subject in the context of the server, then one should construct a
subject name that does so.

Another approach to this problem might be to issue a single public-key
certificate to the user and then have each server be a CA and issue
attribute certs to the users, tied to the public key certs.  However,
unless I have misunderstood the scenario you are trying to support, I would
not recommend this appraoch over the one I described above.

>example, that the person applying for the certificate even had a copy of

You're mixing two types of CA companies here.  VeriSign primarily issues
certs as a service and thus your question is apporpriate in that many folks
feel that a CA ought to verify all of the data in a cert before issuing it.
Entrust is a provider of CA technology, not services, and there the
question is how easily could one add a new type of extension to their CA
product to accommoadte such data.  My company, CyberTrust is both a CA
service provider and a CA technology
provider, so we might have two different answers to this question,
depending on whether you were asking us as a service provider or a
technology provider :-)

>Is there any standard way of doing this?

No, and if I understand the scenario you have in mind, there probably ought
not be one.

\Steve

---

From: Keith Johnston <[email-masked]>
Date: Fri, 19 Mar 1999 15:00:34 -0600

> subject name that does so.

OK, I see your point - think of the server as a particular user.  And this
works fine if the customer has their own CA software - they would be perfectly
willing to sign a certificate that has a name like
"c=us,o=MyCompany,cn=ProcessFooBar".  But Verisign or Thawte (OK - Entrust
doesn't provide a signing service - I was mistaken there) wouldn't know how to
prove that you are really running ProcessFooBar on your server, or even what
ProcessFooBar is.  So I don't see how this works with an external CA that
doesn't understand what it is you are trying to do.  Sure, they can sign
certificates with DNS names or a persons name, but a process name?

Another alternative we are investigating is allowing each server process to map
a certificate distinguished name to a process identity.  This could mean that
JoeBob could get 5 or 6 certificates from Verisign, each with the same DN, but
different serial numbers.  Then each process would have a hashtable that maps
the serial number to the process name.  Each process could then authenticate to
the others.  But that's kind of annoying to have to distribute that map
around.  Sure, you could put it in LDAP or on some central server, but then
you've got a single point of failure or a complicated caching/replication
system.  So putting the process name in the certificate is really, really cool,
because all each server needs is a copy of the CA certificate.

Thanks for your comments, I look forward to your response.

Keith

---

From: Tony Bartoletti <[email-masked]>
Date: Fri, 19 Mar 1999 18:54:09 -0800

Keith,

Naive question, perhaps, but if I understand you correctly, you want
processes (or servers) to authenticate each other, irrespective of the
"person" (if any) that may have started the process, or be at the controls.

If this is the case, why not be your own CA?  I assume you would know if
a particular server/ethernet-address/IPAddress binding was correct or not.

Is there an independent need that these certificates be available through
(say) Verisign or Thawte?

___tony___

>Thanks for your comments, I look forward to your response.

Tony Bartoletti                                             LL
Center for Information Operations and Assurance          LL LL
Lawrence Livermore National Laboratory                LL LL LL
PO Box 808, L - 303                                   LL LL LL
Livermore, CA 94551-9900                              LL LL LLLLLLLL
phone: 925-422-3881   fax: 925-423-8002               LL LLLLLLLL
email: [email-masked]                                   LLLLLLLL

---

From: Juergen Walter <[email-masked]>
Date: Mon, 22 Mar 1999 13:09:55 +0100

> "person" (if any) that may have started the process, or be at the controls.

I tend to use attribute certs in the situation described by Keith.
Attribute certs contain a DN or an ID of public key certificate.
Therefore an attribute cert binding to a "person" over DN or cert ID is
given.

I would like to consider a similar problem. What is to do if I want to
certifiy a server public key. Who is the subject? Is it the server or
the entity responsible for it? What cert extensions are commonly
recognized in server certificates?

I prefer a human being as subject. All other informations should be
contained in the cert extensions.

Has somebody seen a solution where a separation of duty scheme is mapped
to certs? I mean the case whereby two entities share the responsibility
over one signature key. Any thoughts about this problem?

Juergen

--------------------------------------------------------------------
Juergen Walter                  
DEH information systems GmbH    WWW: http://www.deh.de
Weissenfelser Strasse 46a       Germany
D-06217 Merseburg               Tel.: +49 3461 3318-25
Email: [email-masked]            Fax:  +49 3461 415072
-------------------------------------------------------------------- 

-- 

with regards

---

From: Tony Bartoletti <[email-masked]>
Date: Mon, 22 Mar 1999 10:12:56 -0800

>contained in the cert extensions.

I agree that Attribute certificates would be more natural for this
situation.  However, I also tend to object to the notion that subjects
need to be human beings.

As far as I can see, ALL PKI certificates ever do is cryptographically
bind a "name" (DN, AltName, ...) and other attributes to a public key.
The presumed binding of this "name" to something "real" is accomplished
only in the minds of those who accept the signatory's (CA's) stated
verification procedures.  It is a semantic layer removed from the
mechanics of the certificates themselves, and should have remained so.

Otherwise, we are building an "Earthling Identification Infrastructure",
rather than engineering a Public Key Infrastructure.

If PKIs did not appear until the year 2099, the first applications
might have been "robot authentication", in which case "Manufacturer"
might have had a prominent position in the DN.  Then, people might
ask "Why is the cert schema so unfriendly to humans?  Humans have no
Manufacturer."

Or is the infrastructure designed mainly to serve "paying customers"?

___tony___

Tony Bartoletti                                             LL

---

From: Keith Johnston <[email-masked]>
Date: Mon, 22 Mar 1999 17:07:26 -0600

Yes, you have understood correctly.  And yes, there is a need that these
certificates be available through an external CA.  We cannot assume that our
customers are willing to buy CA software and manage it.

Thanks for your comments!  We are still waiting to here from Verisign and Thawte as
to whether or not they will sign certificates with extensions.

Keith

---

From: Stephen Kent <[email-masked]>
Date: Wed, 24 Mar 1999 09:38:04 -0500

Juergen,

>recognized in server certificates?

The server's name, e.g., as a DNS name, should be used as the Subject, or
subject alt name. I would not put the name of the entity responsible for
the server in the cert, especially if the entity is a person!

>contained in the cert extensions.

Usually access control decisions are be made based on the purported
identity, and it is easiest to get this from the Subject name.  For
example, browsers using SSL compare (a aprt of) the Subject name against
the URL to make sure that the server is the one the user intended.  Now,
I'd prefer if the server name were expressed as a pure DNS name, either as
a sequence of DC attributes or as a suitable subjectAltName. Hopefully that
will come, over time.

If you put in the name of the person responsible for managing the server,
you would have to revoke and reissue the certs whenever management
responsibilities.  If one puts in the "responsible" organization name, this
too is not always easy. What if the server is running on a machine run by
an ISP?  Is the ISP the responsible entity, or the organization that
"appears" to be running the server?

Also, if I were to lookup a certificate for a sever in any form of
directory, I probably know the name of the server I want to access, but
have no clue about the name of the person or an ISP managing the server.
All reasonable respositories will be able to serach and retrieve certs
based on subject names but not all may be able to search on other extension
values.

>over one signature key. Any thoughts about this problem?

One can do this in different ways, depending on the technology underlying
the protection of the privayte keys. Most of those ways are then not
visible to a relying party.  One might have used various shared key
generation schemes, or you might use a product that embodies multi-party
control to enable use of a signing key (e.g., the SafeKeyper works this
way).  I have not seen approaches that try to express separateion of duty
explicitly in a certs for a single signing key, although one could imagine
expressing this notion (but not the identities) via the policy info
extension.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 24 Mar 1999 06:36:35 -0500

>certificates with DNS names or a persons name, but a process name?

Well, because the process name is qualified by the server name, the
argument should be that you can demonstrate that you are the "owner" of the
DNS name for the server, and then the process name is obviously within your
purview and thus you are the appropriate registration authority for that
name.  I think CyberTrust would probably issuing a certificate under this
model, as it is analogous to the sorts of checks we do when issuing SSL
certs to servers for use under our roots in the Netscape and IE browsers.

>because all each server needs is a copy of the CA certificate.

You are right, that would be annoying, and you would probably make errors
in the process, so I would recommend against this approach.

Steve

---

From: Juergen Walter <[email-masked]>
Date: Thu, 25 Mar 1999 11:17:12 +0100

Stephen,

> the server in the cert, especially if the entity is a person!

I see the advantage of this approach too. But such certificates focus on
server authentication. A relying party receives the assurance that the
denoted server is the server that it is claimed to be. The entity (a
person or organization) who is responsible for server operations may be
not mentioned. Please note that many enterprises around the world have
names originated by the (first) owner e. g. Ford. Server names derived
by the name of the person who is responsible is not so strange as it
seems to be at a first glance.

> >contained in the cert extensions.

OK, I should consider organizations as well. Today´s bussiness differs
from bussiness when Ford established his factory.

> a sequence of DC attributes or as a suitable subjectAltName. Hopefully that

When the server´s DNS name contains at least the organization
responsible the name may be meaningful for the relying party. Whenever a
server´s affiliation changes the DNS name may be misleading. Is it then
acceptable for the relying party to look up a special service provider
in such cases?

> responsibilities.

Management fluctuations may be of some interest for the relying party,
especially why certificates provide security.

>  If one puts in the "responsible" organization name, this

Then the server may have a DN pointing to the ISP. But the ISP may have
not any knowledge about the service provided by the server. A
certificate may help to make it clear who is responsible for the
particular server. For example, it should be clear who is responsible
for an e-bussiness server. It should be expressed in the certificate.
One may think about the right place ie cert extensions or subject or
subjectAltName. Is there a specific attribute available for this
purpose?

> based on subject names but not all may be able to search on other extension

This is the operational advantage of server´s DNS name. Nevertheless at
least the organization responsible for it should be known to the public.
An appropriate certificate extension may a way to express
responsibilities.

[snip]

-- 

Juergen