Well folks,
Here is a draft of our low assurance PCA statement. This PCA is
intended to fulfill our commitment to provide PERSONA certification
services as well as facilitating a near-term test environment for
certificates. Unfortunately, I will not be able to attend the
Thursday PEM session at the IETF, however, I will be hanging around
Monday through Wednesday (and reading my e-mail) and will try to touch
base with anyone who is interested in discussion. Our
high-assurance/residential PCA statement is held up due to lack of
trusted hardware for certificate-signing (sigh).
Questions, comments, criticisms are welcome.
Cheers,
Steve Dusse
Crypto-Weenie
----------------------------------------------------
RSA Data Security, Inc.'s
"Low Assurance" Certification Authority
Policy Statement
C) 1992 RSA Data Security, Inc.
Draft: 7/9/92
-SD
0. PCA Scope Statement
The community that this PCA will serve is unrestricted. The goal of this PCA
is to facilitate the rapid and widespread dissemination of public-key
certificates with a relatively low level of identification assurance. The
purpose of such dissemination is to allow the immediate evaluation, testing
and use of the technology which utilizes these certificates without the more
extensive planning and procedures necessary to implement the higher levels of
trust required by most environments. This PCA also addresses the needs of
the members of the Internet community that have expressed the desire for
"anonymous" or "persona" certificates since a name that is requested in a
certificate-signing request under this authority need not represent the
identity of the requestor.
1. PCA Security and Privacy
This PCA will utilize best efforts to store and control use of the private
component of this PCA's RSA key pair to prevent its compromise.
Certificate-signing requests and fulfilled certificates will be stored on a
generally unsecured server with the goal of providing this information freely
to the Internet community to facilitate testing and to allow preemptive
prevention of duplication of names in certificate-signing requests.
2. Certification Policy for CAs and Individual Users
This PCA will certify any CA or individual wishing to participate in this
hierarchy within the rules set forth by the ICA and by this PCA statement.
CA Certificates
Any CA wishing to be certified by this PCA must submit a certificate-signing
request. Since there is no standard format for CA certificate-signing
requests, the CA may opt to utilize the user certificate-signing request
format specified in I-D [FORMS] or any format which is mutually agreed to by
the requestor and this PCA. The request should contain, at a minimum, the
distinguished name and public component of the RSA key pair of the CA and a
desired validity interval (start date and end date) for the requested
certificate, all signed by the private component of the RSA key pair of the
CA or an Organizational Notary for the CA. An Organizational Notary for a
particular CA can be identified by submitting a certificate for the
Organizational Notary signed by the CA that is requesting certificate-signing
from this PCA.
The distinguished name and public component contained in CA
certificate-signing request will be checked against a list of the
distinguished names and public components contained in certificates already
issued by this and other PCAs via a database mechanism provided by the ICA.
A CA certificate-signing request will not be fulfilled if the request
contains the same distinguished name and public component as a non-revoked
certificate that has already been issued and the validity ranges of the
issued certificate and the requested certificate overlap.
CAs in this hierarchy should employ reasonable measures to protect the
private components of their RSA key pairs. However, the protection of a such
private components will generally be a local matter, similar to the
protection of the private components of RSA key pairs for users. CAs can
issue certificates to subordinate CAs and to end-users within the guidelines
set forth by the ICA, i.e., subject names must be subordinate to the issuer
name and end-users are not permitted to create certificates.
Persona User Certificates
A distinct CA in this certification hierarchy will be established by this PCA
for the issuance of "persona" certificates to individuals. Any individual
wishing to be certified by the "persona" CA must submit a certificate-signing
request in the format specified by I-D [FORMS]. There will be no identity
verification applied by this PCA to the "persona" certificate-signing
requests. Distinguished names contained in certificate-signing requests will
be checked against a list of the distinguished names contained in
certificates already issued by this CA. A certificate-signing request will
not be fulfilled if the request contains the same distinguished name as a
non-revoked certificate that has already been issued and the validity ranges
of the issued certificate and the requested certificate overlap.
Under the "persona" CA, individual distinguished names will be certified on a
first-come first-served basis. Since the distinguished names will be
subordinate to the issuer (see section 4) there will be no need for name
conflict resolution outside of this hierarchy. Since there will be no
identity verification applied to the certificate-signing requests, there will
be no restrictions made on the content of requested distinguished names
outside of the restrictions outlined in section 4. THEREFORE, A CERTIFICATE
SIGNED BY THIS CA DOES NOT "VOUCH" FOR ANY BINDING BETWEEN THE REQUESTED
DISTINGUISHED NAME AND THE IDENTITY OF ANY ENTITY, REAL OR FICTITIOUS. This
CA reserves the right to deny a certificate-signing request or to revoke a
user certificate that contains a name that is found to be generally abusive,
offensive or in conflict with the registered trademark of an organization
unless the requestor shows proof of permission to use such trademark.
Requested Validity Intervals
CA and individual "persona" certificate-signing requests will not be
fulfilled if the requested start time of the certificate is greater than
seven (7) days prior to the time of request or the requested start time of
the certificate is greater than sixty (60) days after the time of request.
This prevents a CA or user from requesting certificates for validity ranges
too far into the past or future while allowing the entities enough time to
renew existing certificates. A certificate-signing request will not be
fulfilled if the requested validity interval is greater than two (2) years or
less than one (1) month.
3. CRL Management
Certificate-Revocation Lists (CRLs) will be generated by this PCA and the
subordinate "persona" CA monthly. CRLs for this PCA and the "persona" CA
will be forwarded to the ICA for service to the Internet Community. All
other subordinate CAs in this hierarchy are required by ICA policy to
generate and submit to this PCA a CRL upon initial certification and
periodically thereafter. This PCA will forward submitted CRLs to the ICA for
service to the Internet Community. This PCA places no additional
restrictions upon the frequency and duration of the CRLs generated by
subordinate CAs.
Certificate revocation is initiated by the entity that requested the
certificate-signing. Entities should request certificate revocation if they
suspect that the private component of their RSA key pair has been
compromised, if identifying information contained in the certificate has
changed, or if they wish to test functionality associated with revocation.
A CA under this PCA can request certificate revocation by sending a PEM
message to this PCA, signed by the CA or by the Organizational Notary (ON)
that requested certification for the CA. The PEM message body must
unambiguously request certificate revocation for the corresponding CA
certificate, e.g. "Please revoke this certificate".
An individual "persona" user can request certificate revocation by sending a
PEM message to the "persona" CA signed by the user with the private component
of the RSA key pair corresponding to the public component in the certificate
to be revoked. The PEM message body must unambiguously request certificate
revocation, e.g. "Please revoke this certificate."
If the revocation request header includes a return address, this PCA or
"persona" CA, respectively, will provide a PEM confirmation of the revocation
request signed by an ON of this PCA or "persona" CA. Once revoked, the
requestor's certificate serial number will appear in the CRL for this PCA or
"persona" CA until the revoked certificate naturally expires.
4. Naming Conventions
The issuing authority for this PCA will have the following distinguished name:
countryName = US
organizationName = RSA Data Security, Inc.
organizationalUnitName = Low Assurance Certification Authority
The subject names that can appear in CA certificates are constrained only by
the policies set forth by the ICA.
The issuing authority for the "persona" CA will have the following
distinguished name:
countryName = US
organizationName = RSA Data Security, Inc.
organizationalUnitName = Persona Certificate
The subject names that can appear in individual "persona" certificates are
constrained in the following manners:
- Subject names must be subordinate to the issuer name (must contain all of
the issuer's listed attribute-value assertions, encoded identically),
- Subject names may only contain a single additional terminal commonName
attribute.
Certificate-signing requests that violate these constraints will be rejected.
5. Business Issues
Because the creation and use of RSA certificates in North America is covered
by the RSA Public-Key Cryptography Patent (U.S. Patent # 4,405,829),
certificates generated by this PCA can only be used in conjunction with RSA
implementations that have been licensed for use by RSA Data Security, Inc.
Fees
There will be a processing fee for the registration of each CA under this PCA.
There will be no processing fee for fulfillment of each individual "persona"
certificate-signing request under this PCA.
There will be a processing fee for fulfillment of certificate-revocation
requests by CAs under this PCA and by "persona" individuals.
6. Service Provision
Certificate-signing Requests
CA certificate signing can be requested by sending a certificate-signing
request signed by the CA or by an Organizational Notary for the CA to the
following address:
ca-low-request(_at_)rsa(_dot_)com
If a request is rejected, this PCA will send back a message via PEM signed by
an ON for this PCA which indicates the reason for rejection. Otherwise, if
the certificate-signing request is fulfilled, this PCA will send back a
message via PEM which includes the signed certificate and a current CRL for
this PCA.
Individual "persona" certificate signing can be requested by sending a
certificate-signing request (see I-D [FORMS]) to the following address:
persona-request(_at_)rsa(_dot_)com
If a request is rejected, the "persona" CA will send back a message via PEM
signed by an ON for the CA which indicates the reason for rejection.
Otherwise, if the certificate-signing request is fulfilled, the "persona" CA
will send back a message via PEM which includes the signed certificate,
issuer certificates necessary to "chain" to the root, and current CRLs for
the issuers in the chain.
Certificate-revocation Requests
Certificate revocation for CA certificates is requested by sending a PEM
message, signed by the CA or by the Organizational Notary for the CA that
requested the certificate, to the following address:
ca-revocation-request(_at_)rsa(_dot_)com
Certificate revocation for individual "persona" users is requested by sending
a PEM message, signed by the user with the private component corresponding to
the public component in the certificate to be revoked, to the following
address:
persona-revocation-request(_at_)rsa(_dot_)com
In either case, the PEM message body must unambiguously request certificate
revocation (ex. "Please revoke this certificate.") and the message must have
a valid signature. If the message header includes a REPLY TO: field or a
FROM: field, an acknowledgement will be sent to the user via PEM signed by an
ON for this PCA or "persona" CA. A certificate-revocation request will be
rejected if the required fee is not received within ten (10) days of the
electronic request.
Payment
The certificate-signing fee and revocation fee for CAs can be submitted via
Postal Money Order or company check or any other form of payment that is
mutually acceptable by the CA and this PCA. To preserve anonymity, the
revocation fee for individual "persona" certificates must be submitted via
Postal Money Order. Payment for certificate signing must be accompanied by
the digest of the "to be signed" portion of the certificate-signing request.
Payment for certificate revocation must be accompanied by the serial number
of the certificate to be revoked. The fees for multiple revocation requests
can be combined in a single money order. Checks and postal money orders are
made payable to:
RSA Data Security, Inc. - Certification Services
Payment and correspondance can be mailed to:
Certification Services
RSA Data Security, Inc.
10 Twin Dolphin Dr.
Redwood City, CA 94065
Alternate arragements can be made by writing or calling:
1-800-PUBLIK-E
THESE SERVICES ARE NOT YET ACTIVE.