From:	kepa.zubeldia@envoy.com
Sent:	Friday, February 12, 1999 9:52 PM
To:	Interop@afehct.org
Subject:	Proposal #1

Today we have had a couple of conference calls with the CAs that 
have volunteered to provide directory services for the pilot. These 
calls have been VERY productive and we have reached some tentative 
agreements that I would like to run by the entire group for feed 
back.  Some of the issues were not resolved, but some issues seem 
to have a consensus that satisfies all of our needs.  Here is one 
of the items that seemed to be acceptable.

The DN (Distinguished Name) in the certificate and/or repository 
will be assigned by any of the participating CAs (and their RAs) 
without using a global naming authority.  In order to avoid name 
collissions, there has to be a disambiguating element, so the same 
person could have multiple certs (e.g. if they need a high security 
and a low security cert), and these certs could be issued by the 
same or by a different CA with the assurance that their DN will not 
collide with any other cert.  Also, there should be no collissions 
in the case of two doctors by the same name that work in the same 
hospital.  The disambiguating element is described below.

The DN needs to be interoperable among all those that are going to 
rely on the cert.  The DN should not change when the cert subject 
changes affiliation, or changes ISP or email address, or changes 
function, or the access privileges or job description changes.  The 
cert identifies an individual.  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.

The DN will have these required components: Country, 
State/Province, City/Locality, Common Name, and the disambiguating 
UniqueID.

Optionally, the DN could also contain Street address, Organization, 
and Organizational Unit.  These could be used as part of the DN, 
but may be better suited inside the certificate and not as part of 
the DN itself.  Even the, they 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, and the cert subject 
actually wants them inside the cert for some reason.

In addition, the cert could contain the telephone number and 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 in the future, for certain certs, but are not 
required elements.

The disambiguating factor will be assigned by the CA or the 
Registration Authority (RA).  It will be variable length 
alphanumeric, with the first three positions identifying the CA, 
and the rest assigned by the CA or its dependent RA.  For example: 
XYZ221234 where XYZ identifies the namespace of the XYZ 
Certification Authority, and then XYZ assigns the first two 
positions (22) to their RAs, and the XYZ RAs assign the rest of the 
digits.  Or, for example ABC00087654321 where the ABC CA uses three 
digits for their RAs and the ABC RAs use 8 digits for their own 
unique number.

As long as we do not have collission in the first three positions 
of the disambiguating factor, we have a unique name that can be 
used for the DN, still be meaningful to a human reader doing a 
search, and not require a global naming authority.  Avoiding 
collisions in the first three letters should be relatively easy, as 
there are not that many CAs.  If necessary we could have someone 
maintain a registry, just in case.

Example of cert:

DN: C=US,SP=Utah,L=Kaysville,CN=Kepa Zubeldia,UniqueID=ARC008765432
C:  US
SP: Utah
L:  Kaysville
O:  ENVOY Corporation
CN: Kepa Zubeldia

Another one:

DN: C=US,SP=Oklahoma,L=Oklahoma City,CN=Fred Jones, 
      UniqueID=GTE15RFTJ6N
C:  US
SP: Oklahoma
L:  Oklahoma City
CN: Fred Jones
NPI:01238765

and another one:

DN: C=US,SP=Oklahoma,L=Oklahoma City,CN=Fred Jones, 
      UniqueID=GTE15RFV43K
C:  US
SP: Oklahoma
L:  Oklahoma City
S:  4009 NW 57th Street
CN: Fred Jones

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 disambiguating factor is the only difference 
between the two DNs.

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 DN 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 human readable DNs, 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
----------------------------------------------------------------------
From:	kepa.zubeldia@envoy.com
Sent:	Monday, February 15, 1999 7:10 AM
To:	Interop@afehct.org
Subject:	Proposal #1 withdrawn (split in two)

My message with the Proposal #1 is confusing because it addresses 
both the discussion about the certificate parameters and the 
directory parameters in the same proposal.

So, with your permission, let me withdraw that proposal #1, and 
split it into two proposals, #3 and #4.

Please ignore proposal #1.

Thanks.

Kepa Zubeldia
ENVOY Corporation 
Kepa.Zubeldia@envoy.com