🚀 go-pugleaf

In article <1991May21.210447.9022@ux1.cso.uiuc.edu>, phil@ux1.cso.uiuc.edu (Phil Howard KA9WGN) writes:
> However, if the end user licensing process involves them assigning the
> actual keys, I certainly won't go for it, free or commercial.  If it
> constitutes simply a registry of public keys (you give them your public
> key) then that seems reasonable as long as there are no restrictions on
> using other unregistered keys.

The procedures are discussed in RFC1114; I commend that to those
interested in RSADSI's role.  Briefly, you will generate your own
public/private key pair.  That's mandatory -- otherwise, whoever issued
the key to you could read any traffic to or from you.  But if you just
have a public key, it's not very useful to others, as there is no
assurance that it's genuine.  That is, suppose I post an article to the
net announcing that the public key for Steven M. Bellovin is 0x123....,
etc.  You'd have absolutely no reason to believe that message.
Instead, my public key would be embedded in a ``certificate'' -- a
string containing not only my public key, but also a digital signature
associated with some certifying authority, typically my company or
organization.  And how do you know that that's valid?  Easy -- the
certificate contains the public key of my organization -- and it is
signed by a meta-certifying authority.  For non-governmental U.S. users,
that authority will be RSADSI.

The normal mode of operation, then, would be for me to go to the AT&T
PEM office.  They'd generate a random public/private key pair for me.
I'd get the private key; the public key would be sent to RSADSI for
signing.  (RSADSI will retain the secret signing key for most companies;
see below.)  They'd endorse it with AT&T's secret key, attach to it
AT&T's public key, and sign that with their own secret key.  And
that in turn would be validated because *everyone* would know RSADSI's
public key; it would be too widely distributed to be forgeable.

The cost of the certificate is $25; it's good for two years.  There
are two reasons RSADSI prefers to retain organizational secret keys; I
quote from the RFC:

   The RFC proposes that RSADSI act as a "co-issuer" of certificates on
   behalf of most organizations.  This can be effected in a fashion
   which is "transparent" so that the organizations appear to be the
   issuers with regard to certificate formats and validation procedures.
   This is effected by having RSADSI generate and hold the secret
   components used to sign certificates on behalf of organizations.  The
   motivation for RSADSI's role in certificate signing is twofold.
   First, it simplifies accounting controls in support of licensing,
   ensuring that RSADSI is paid for each certificate.  Second, it
   contributes to the overall integrity of the system by establishing a
   uniform, high level of protection for the private-components used to
   sign certificates.  If an organization were to sign certificates
   directly on behalf of its affiliated users, the organization would
   have to establish very stringent security and accounting mechanisms
   and enter into (elaborate) legal agreements with RSADSI in order to
   provide a comparable level of assurance.  Requests by organizations
   to perform direct certificate signing will be considered on a case-
   by-case basis, but organizations are strongly urged to make use of
   the facilities proposed by this RFC.

The RFC goes on to note that possession of an organizational secret
key would allow RSADSI to issue false certificates for members
of that organization, but would not allow them to read encrypted
traffic sent to or from legitimate members.  Furthermore, since
only RSADSI would have that secret key, the forgery could be traced
back to them immediately.

As for licensing terms and costs, the RFC says the following:

   The certificate issued to a user for the $25 biennial fee will grant to
   the user identified by that certificate a license from RSADSI to employ
   the RSA algorithm for certificate validation and for encryption and
   decryption operations in this electronic mail context.  No use of the
   algorithm outside the scope defined in this RFC is authorized by this
   license as of this time.  Expansion of the license to other Internet
   security applications is possible but not yet authorized.  The license
   granted by this fee does not authorize the sale of software or hardware
   incorporating the RSA algorithm; it is an end-user license, not a
   developer's license.

You cannot legally ``use your own unregistered key'' within the US;
to do so would be to infringe their patent.

The RFC makes other provisions for people not affiliated with an
organization that does its own certifications, for US government
employees, and for non-Americans.