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

This proposal is for the contents of an "organization" certificate. 
The examples of organization certificates we are trying to satisfy 
here are for 1) web servers operated by an organization such as a 
payer, employer, hospital, clinic, etc.; 2) organizational email 
addresses such as admissions@hospital.com or billing@clinic.com; 3) 
EDI software front/back end servers; 4) devices that need to 
communicate securely and are not tied to an individual; 5) shared 
identities that are role based.  It is important to note that in 
most cases HIPAA requires the identity of the individual 
responsible for the communication, but, under some circumstances, 
shared accounts that are role based are acceptable.

The organization / entity certificate has the following required 
attributes: Country, State/Province, Locality, Street address, 
Common Name, Alternate Subject Name, and DN Qualifier.

The Street Address of the organization is required for 
organizations (it is optional for individuals).

The Alternate Subject Name is required, and there could be more 
than one instance of this attribute.  If the certificate is for a 
server, the alternate name will contain the DNS server name.  If 
the server has a static IP address (don't they all ?) then the IP 
address should also be shown as another alternate name.  If the 
certificate is for a group email address (as in 2) above) then the 
alternate name must contain the email address.  If the certificate 
is for a device that attaches to the net with a dynamic address 
(e.g. POS terminal) then the alternate name contains the device 
Terminal ID or serial number.

Listing the Organization and Organizational Unit(s) is highly 
desirable in organizational certificates, but it is not required as 
the organization could be named in the Common Name (required).

Other extensions containing the NPI, PayerID, EIN, etc. are 
optional and may be listed if the certificate subject so desires, 
as long as they are verified by the RA.

The X.509v3 extensions of "Key Usage", "Certificate Type", "CA 
Policy URL", are required, just like in the personal cert.

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.

If the same subject has more than one certificate, 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.

If the certificate is for an SSL web server, the "SSL Server Name" 
extension is required.  For backwards compatibility with older 
software, it may be advisable to put the server name as both SSL 
Server Name and Alternate Subject Name.  This could change in the 
future.

So, if this will not work, speak up.

Kepa Zubeldia
ENVOY Corporation
Kepa.Zubeldia@envoy.com