From:	kepa.zubeldia@envoy.com
Sent:	Monday, February 15, 1999 9:10 AM
To:	Interop@afehct.org
Subject:	Proposal #4

Here is what seems to be a consensus solution for the structure and 
naming of the certificates themselves.

The certificate will be created and named by any CA (and their RAs) 
without using a global naming authority.  There is no need to avoid 
name collisions, as each cert will be assigned a unique serial 
number by the issuing CA.  The same person may have multiple 
certificates issued by the same CA.  However, the certificate 
should contain something that helps those searching for it in their 
decision as to which certificate to retrieve.  That additional 
"hint" could be in the directory (see Proposal #3).

The certificate needs to be interoperable among all those that are 
going to rely on the cert.  The cert should not have to change when 
the cert subject changes affiliation, or changes ISP or email 
address, or changes function, or the access privileges or job 
description change.  The cert identifies an individual in a 
persistent manner, and should not reflect variable aspects.

The privileges or access rights are not granted by the cert but are 
granted by the party that relies on the cert.  Access rights and 
privileges should not be part of the cert itself.  Each relying 
party maintains its own Access Control List, using the cert as the 
key to the ACL.

A model for the cert would be a driver's license rather than an 
employee ID card.  The cert goes with the individual as a person, 
rather than as a member of a specific group.

The certificate will have these REQUIRED components: Common Name, 
City/Locality, State/Province, and Country.

The components of the name will be used only for their stated 
purpose.  No "made up" countries, etc.  The components are to 
reflect the information corresponding to the person identified by 
the certificate.

Optionally, the certificate could also contain Street address, 
Organization, and Organizational Unit.  These components should 
only be used inside the cert if there is a relative certainty that 
they will remain constant for much longer than the life of the cert 
(to make renewals easier), and the cert subject actually wants them 
inside the cert for some reason.  For some individuals with a 
common name, it may be very important to have these additional 
components.  This is a decision between the CA/RA and the 
individual requesting the cert.  

In addition, the cert could contain the telephone number or email 
address, as long as these are also constant and the cert subject 
wants them inside the cert.  Other pieces, such as the healthcare 
credentials (MD,RN,DDS,etc.) and/or the NPI or PAYERID may be 
inside the cert, for certain certs, but are not required elements.  
Some of these will appear in the form of "certificate extensions" 
in X.509v3.  We will need OIDs before we can use some of them.

There is a trade off between persistence of the cert and 
specificity of the name.  It is likely that certain common names 
repeat multiple times in the same city, and these different people 
with the same name need to be distinguishable.  In some cases the 
email address may be the only additional information able to 
resolve the conflict.  And the individual, for privacy reasons, may 
not want the street address or email published in the cert.  It is 
the responsibility of the RA or CA to resolve these issues.

Example of cert:

CN: Kepa Zubeldia
L:  Kaysville
SP: Utah
C:  US
SerialNumber: 123456.....7890

Another one:

CN: Fred Jones
S:  4009 NW 57th Street
L:  Oklahoma City
SP: Oklahoma
C:  US
SerialNumber: 123456.....1234
--V3 extension--
NPI:01238765

and another:

CN: Fred Jones
S:  4009 NW 57th Street
L:  Oklahoma City
SP: Oklahoma
C:  US
SerialNumber: 123456.....4321

In this case, Dr.Fred Jones is using his own office address but is 
not giving his NPI in the certificate.  Why is he doing this using 
two certificates ?  I don't know !    It is just an example of a 
situation in which the serial number could be the only difference 
between the two certs, and the directory would have to give some 
indication as to which one to choose.

This is something that did satisfy the needs of the CAs 
participating in the conference call, and probably satisfies the 
needs of all of us.  It could be implemented immediately and easily 
without system changes.  It gives a cert that does not favor any 
private certificate hierarchy over another.  It is easy to 
implement both as LDAP, X.500 (all the DN parts already exist as 
OIDs) and even RDBMS.  And it gives persistent names and human 
readable cert names, which is a bonus that could not be overstated.

So, think about this in your environment, and speak up if it will 
NOT work for you.  I am not asking whether you have a better 
solution or something that works better for you.  We are looking at 
interoperability.  We are looking at a solution that works for 
everyone in healthcare. Of course, if you have a better solution 
that still works for everyone else, or a tweak or change to this 
one that makes it better and still works for all, then speak up.

Kepa Zubeldia
ENVOY Corporation
Kepa.Zubeldia@envoy.com