I am pleased to present the first published version of RSA Data
Security's Low Assurance PCA policy statement. Among other things, this
outlines the procedures for using the free RSA Persona Certification
EMail Responder.
The text version follows. This and other versions (EPS, Word Doc, RTF)
of the policy statement as well as C source code for our Low Assurance
PCA DN and key can be found on our anonymous ftp server, rsa.com in
the pub/low_assurance_pca directory.
Cheers,
Steve Dusse
Crypto-Weenie
----------------------------------------------------------------------
RSA Data Security, Inc.
"Low Assurance" Certification Authority
Policy Statement
Copyright 1993 RSA Data Security, Inc.
Update: 1-January-94
Expires: 1-July-94
Steve Dusse & George Parsons
The information contained in this PCA policy statement is accurate on
the date specified at the beginning of this policy statement and will
be updated on the expiration date. RSA reserves the right to make
appropriate changes to these policies.
1. PCA Identity
1.1 Business Identity:
RSA Data Security, Inc.
100 Marine Parkway
Redwood City, CA. 94065
Phone (415) 595-8782
Fax (415) 595-1873
ca-info(_at_)rsa(_dot_)com
The above EMail address is for general information regarding the
PCA. Please refer to Section 8 on Service Provision regarding
the appropriate EMail addresses for the different services that
this PCA provides.
1.2 PCA Name Information
This PCA uses the following distinguished name:
countryName = US
organizationName = RSA Data Security, Inc.
organizationalUnitName = Low Assurance Certification Authority
The following hex bytes represent the Low Assurance CA
distinguished name encoded according to the ASN.1 Distinguished
Encoding Rules (DER).
30 5f 31 0b 30 09 06 03 55 04 06 13 02 55 53 31
20 30 1e 06 03 55 04 0a 13 17 52 53 41 20 44 61
74 61 20 53 65 63 75 72 69 74 79 2c 20 49 6e 63
2e 31 2e 30 2c 06 03 55 04 0b 13 25 4c 6f 77 20
41 73 73 75 72 61 6e 63 65 20 43 65 72 74 69 66
69 63 61 74 69 6f 6e 20 41 75 74 68 6f 72 69 74
79
The following hex bytes represent the Low Assurance CA public
key encoded according to the ASN.1 Distinguished Encoding Rules
(DER).
30 7c 30 0d 06 09 2a 86 48 86 f7 0d 01 01 01 05
00 03 6b 00 30 68 02 61 00 b0 b4 0e 9a 3a 46 4e
87 03 ff b8 db ca d8 af 41 f3 c3 f4 13 1c f6 57
1e 39 a5 35 49 b4 20 94 dc 92 f8 ee 1e a1 03 5f
94 21 2b 75 1a 3b 07 44 5d bd d6 ef 4d 7e 23 00
f4 2c f5 73 47 90 bc e8 ba 51 7f a8 19 ee f7 5f
17 46 dc e5 ff d1 23 fe 64 2e 68 94 b3 81 de 5a
40 28 8d d6 d7 14 af 84 ef 02 03 01 00 01
1.3 PCA Public Key Information
The following hex bytes represent the Low Assurance CA public
key modulus encoded as a byte vector, most significant byte
first.
b0 b4 0e 9a 3a 46 4e 87 03 ff b8 db ca d8 af 41
f3 c3 f4 13 1c f6 57 1e 39 a5 35 49 b4 20 94 dc
92 f8 ee 1e a1 03 5f 94 21 2b 75 1a 3b 07 44 5d
bd d6 ef 4d 7e 23 00 f4 2c f5 73 47 90 bc e8 ba
51 7f a8 19 ee f7 5f 17 46 dc e5 ff d1 23 fe 64
2e 68 94 b3 81 de 5a 40 28 8d d6 d7 14 af 84 ef
The following hex bytes represent the Low Assurance CA public
key exponent encoded as a byte vector, most significant byte
first.
01 00 01
2. PCA Scope
The community that this Policy Certification Authority (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 use, testing, and
evaluation 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 operates a Certification Authority (CA) that 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 requester.
3. 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 copies of 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.
4. 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 IPRA and by this PCA
statement.
4.1 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
Internet RFC1424 or any format which is mutually agreed to by
the requester and this PCA. The request should contain, at a
minimum, the distinguished name and public component of the RSA
key pair of the CA. Some form of identity verification will be
performed to attempt to validate that the requester has the
right to use the requested distinguished name. In general,
however, such verification will be performed with a low level of
assurance. As such it should be noted that it will not be
difficult for a dedicated attacker to obtain a certificate with
a "fake" name.
The distinguished name and public component contained in a 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 IPRA. 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 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 in Internet RFC1422, i.e., subject names
should be subordinate to the issuer name, CA names must be
registered with the IPRA. Certificates created by end-users will
not be recognized by this PCA.
4.2 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 RFC1424. 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 or any name which is
proven to this PCA to belong to an entity other than the
requester unless the requester shows proof of permission to use
such trademark or name.
4.3 Certificate Validity Intervals
CA and individual "persona" certificate-signing requests will
not be fulfilled if the requested start time of the certificate
is 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 one
(1) year or less than one (1) week.
5. CRL Management
Certificate-Revocation Lists (CRLs) will be generated by this PCA and
the subordinate "persona" CA periodically. CRLs for this PCA and the
"persona" CA will be forwarded to the IPRA for service to the
Internet Community. All other subordinate CAs in this hierarchy are
required to generate and submit to this PCA a CRL upon initial
certification and periodically thereafter such that there always
exists a valid CRL for each CA. This PCA will maintain a server to
serve CRLs from CAs in this hierarchy and forward submitted CRLs to
the IPRA 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 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 a CA or Persona user revocation request mail 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 requester's certificate
serial number will appear in the CRL for this PCA or "persona" CA
until the revoked certificate naturally expires.
6. 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 IPRA.
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.
7. Business Issues
The use of Public-Key Cryptography may be covered by U.S. Patents #
4,405,829; 4,200,770; and 4,218,582; and all foreign counterparts.
Certificates provided under this PCA are provided "as is" without any
warranty whatsoever. In no event will RSA be liable to any
individual or organization for indirect, incidental, special,
consequential or exemplary damages arising out of or related to the
use of these certificates, including but not limited to lost profits,
business interruption or loss of business information.
7.1 Fees
There will be a processing fee for the registration of each CA
under this PCA. There will be a processing fee for fulfillment
of certificate-revocation requests by CAs under this PCA.
There will be no fee for fulfillment of each individual
"persona" certificate-signing request or certificate-revocation
request under the Persona CA.
8. Service Provision
8.1 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 PEM message
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 RFC1424) to the following address:
persona-request(_at_)rsa(_dot_)com
If a request is rejected, the "persona" CA will send back a PEM
messagesigned 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 PEM message which
includes the signed certificate, issuer certificates necessary
to "chain" to the root, and current CRLs for the issuers in the
chain.
8.2 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-low-revocation-request(_at_)rsa(_dot_)com
The PEM message body must unambiguously request certificate
revocation (e.g. "Please revoke this certificate.") and the
message must have a valid signature. An acknowledgment will be
sent to the user signed by an ON for this PCA.
A certificate-revocation request will be not be fulfilled if the
required fee is not received within ten (10) days of the
electronic request or credit arrangements have not been made.
Certificate revocation for individual "persona" users is
requested by sending a PEM message, signed 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
The PEM message body must consist of a single line with the text
"Please revoke this certificate." and the message must have a
valid signature. An acknowledgment will be sent to the user
indicating that the revocation was performed.
8.3 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. Payment for certificate signing must be accompanied by the
desired subject name or 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. Checks and postal money orders are
made payable to:
RSA Data Security, Inc. - Certificate Services
Payment and correspondence can be mailed to:
Certificate Services Center
RSA Data Security, Inc.
100 Marine Parkway
Redwood City, CA 94065
Phone Number:(415) 595-8782
Fax Number:(415) 595-1873
Alternate arrangements can be made by writing or calling.