From:	kepa.zubeldia@envoy.com
Sent:	Friday, February 26, 1999 5:29 PM
To:	Interop@afehct.org
Subject:	Proposal #5

This is a proposal on the components of a Personal Certificate 
without credentialing information.  There will be other proposals 
coming soon on "entity" certificates and on "credentialed" 
certificates.  This proposal on "Personal" certificates builds up 
on the previous proposals discussed a couple of weeks ago.

The following naming components will be required in all personal 
certificates:  Country, State/Province, Locality (City), Common 
Name, DN Qualifier.

The following components are optional, at the discretion of the 
certificate subject, but the RA may require listing some of them in 
case of potential conflict:  Organization, Organizational Unit, 
Street, Telephone, email address.  Potentially there could be 
multiple instances of some of them, especially OU and phone.  The 
RA must verify the information contained in the cert, including 
these optional values, to be correct for the cert subject.

Keep in mind that whenever these optional attributes are used, the 
personal certificate then becomes tied to the Organization or 
Organizational Unit, etc. and therefore it loses portability and 
may have to be reissued if the affiliation changes.  It is up to 
the certificate subject to decide whether the need is for a 
certificate to be generic and portable, or to be more specific and 
less portable. The CA/RA should allow that flexibility.  
(Remember... the certificate should not be the access control 
mechanism, only the identification mechanism.  Access control is 
managed elsewhere (i.e. directory)).

If the same subject has more than one certificate (e.g. one for 
encryption and one for digital signatures), the second and 
subsequent certs must contain a "comment" component that is free 
text in which the cert subject describes what the difference is 
between this cert and other certs held by the same subject.  If the 
subject only has one cert, the "comment" component is optional.

All personal certs will have, at a minimum, the following X.509v3 
extensions:  "Key Usage", "Certificate Type", "CA Policy URL".  In 
addition, if the cert is to be used for S/MIME, the "Alternate 
Subject Name" must be present and contain the email address of the 
subject.

All of these required X.509v3 extensions will have the criticality 
flag set to "not critical".  This may change in the future when we 
see PKI applications that understand these attributes and handle 
the criticality flag correctly.  But for now, they will all be 
flagged as "non critical" even though they are required for 
healthcare.

Additional certificate extensions.  Some of the CAs may use 
additional X.509v3 extensions for items like the UPIN, NPI, 
PayerID, EIN, SSN, DEA, etc.  However, these may have privacy 
restrictions when put in the certificate, and may be better suited 
to be in the directory instead of the certificate.  For now, we 
have the option of putting these and other extensions in the cert, 
and we will see how this affects interoperability.

Also, once the NPI final rule comes out, we may have to adjust the 
cert and directory contents according to what HIPAA considers 
confidential or not in the NPS.  Just keep that in the back of your 
mind.

If this does not work in your environment to identify warm bodied 
individuals, speak up.

Kepa Zubeldia
ENVOY Corporation
Kepa.Zubeldia@envoy.com