[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: legal question about certs

>(disclaimer: again U.S.-centric and IANAL.  Actually, this whole
>discussion has been very U.S.-centric; if we are to constrain
>Internet protocols to legal opinion we should at least get opinions
>covering the wide variety of jurisdictions that are on the Internet).
>Robert Jueneman:
>> This is precisely why, in the ABA Digital Signature Guidelines, and in
>> statutes that several states have passed that follows those guidelines,
>> there is the requirement that the subscriber (subject) of a certificate
>> ACCEPT the certificate prior to it being valid.  
>Do these guidelines and laws cover all possible kinds of certificates, or 
>just identity certificates for legally binding signatures?

A few definitions and guidelines quoted from the ABA Guidelines might be

1.5  Certificate:  A message which at least
(1) identifies the certification authority issuing it,
(2) names or identifies its subscriber,
(3) contains the subscriber's public key,
(4) identifies its operational period, and
(5) is digitally signed by the certification authority issuing it.

1.6  Certification Authority: A person who issues a certificate.  

1.23  Person
A human being or an organization (or a device under the control thereof)
which is capable of signing a message or verifying a digital signature.

1.34 Transnational certificate:  A certificate for a specific transaction
incorporating by reference one or more digital signatures.

1.36  Valid certificate:  
(1) A certificate which (a) a certification authority has issued, and which
(b) the subscriber listed in it has accepted; or
(2) A transnational certificate which (a) a certification authority has
issued, and which (b) the subscriber listed in it has accepted, but limited
to the digital signatures created pursuant to the specific transaction to
which the transnational certificate relates.

1.22  Operational period of a certificate:
The operational period of a certificate begins on the date and time it is
issued by a certification authority (or on a later date and time certain if
stated in the certificate), and ends on the date and time it expires or is
earlier revoked or suspended.

1.11  Digital signature:
A transformation of a message using an asymmetric cryptosystem and a hash
function such that a person having the initial message and the signer's
public key can accurately determine
(1) whether the transformation was created using the private key that
corresponds to the signer's public key, and
(2) whether the initial message has been altered since the transformation
was made.

1.20 Nonrepudiation:
Strong and substantial evidence of the identity of the signer of a message
and of message integrity, sufficient to prevent a party from successfully
denying the origin, submission or delivery of the message and the integrity
of its contents.
1.20.1  The ISO Nonrepudiation Framework treats nonrepudiation as a
technical definition of a security service. The Guidelines define
nonrepudiation not as an automatic result of technical mechanisms, but as a
property which can ultimately only be determined after recourse to available
dispute resolution mechanisms such as a court or arbitrator. The definition
of nonrepudiation in this Guideline 1.20 is intended to express a legal
conclusion or result which flows from the use of digital signatures verified
by certificates in the manner provided in these Guidelines. Nonrepudiation
as defined in this guideline 1.20 is intended to express a legal conclusion
something less than a final determination by a court of last resort, but
something more than a naked rebutable presumption as is now provided by
simple e-mail.

4,1 Generating the key pair
If the subscriber generates the key pair whose public key is to be listed in
a certificate issued by a certification authority and accepted by the
subscriber, the subscriber must generate that key pair using a trustworthy

4.2 Subscriber's obligations
(1) All material representations made by the subscriber to a certification
authority, including all information known to the subscriber and represented
in the certificate, must be accurate to the best of the subscriber's
knowledge and belief, regardless of whether such representations are
confirmed by the certification authority.
(2) A subscriber who provides an otherwise unpublished certificate to a
relying party must disclose that fact to the certification authority.
(3) If the foreseeable effect would be to induce or allow reliance upon a
certificate which is invalid because the subscriber has not accepted it, the
subscriber must not knowingly create digital signatures using a private key
corresponding to any public key listed in such certificate.

4.3 Safeguarding the private key
During the operational period of an invalid certificate, the subscriber
shall not compromise the private key corresponding to a public key listed in
such certificate, and must also avoid compromise during any period of

5.2 Satisfaction of signature requirements
Where a rule of law requires a signature, or provides for certain
consequences in the absence of a signature, that rule is satisfied by a
digital signature which is
(2a) affixed by the signer with the intention of signing the message, and
(b) verified by reference to the public key listed in a valid certificate.

>I fear that such laws may constrain general technologies 
>(e.g., public key decryption of a hash function of another 
>public key), with premature and narrow applications and legal 
>interpretations (e.g., identity certificates for legally
>binding signatures).  Hopefully, such laws only specify
>what legal and technological conditions must be met to 
>for other legal conditions to attain, rather than constraining
>what use particular technologies may be put to, because
>their inventors dubbed them "signatures", "certificates", etc.

Generally, that is the intent and practical effect of those statutes that
have been passed to date. the intent is not to invalidate any existing
practices, but to fairly narrowly define a new set of practices which would
be given a somewhat more exalted status with respect to the burden of proof.

>Legal tradition is a deep well of interpersonal "protocols"
>we can draw upon to our profit, but we should not let the ABA 
>or the legislatures of a few U.S. states dictate technological standards 
>for the worldwide Internet.

No, of course not. However, be aware that corporations are generally risk
averse, and with respect to a technology such as digital signatures, the
risk is that (a) the digital signature might not be binding in circumstances
where it was intended to be, and (b), that the digital signature might be
someone more binding than would have otherwise normally been intended.

Therefore, assuming that you want to eventually develop and sell a product
which makes use of this technology, it would behoove you to make sure that
the technology is going to be acceptable by your customers, and when that
decision is being made it generally won't be made by the technical wonks.

To date, more than 30 states in the US, and something on the order of 39
foreign countries have passed or are giving serious consideration to passing
digital signature legislation. The overwhelming majority of these
legislative initiatives has been closely parallel to the ABA Guidelines.
Although in some cases minor modifications are required in order to adjust
the overall concepts to the peculiarities of that country's legal system,
most of the changes have been relatively minor, and of no technical import.

(California is a significant, and in my view, bone-headed, exception. They
have written a statute which is extremely ill-advised in my opinion, as it
doesn't adequately address many of the fundamental legal issues, and more
importantly says nothing about the allocation of risk and liability between
the various parties, leaving everyone concerned in a very uncertain
position. In addition, they have been so aggressively "technology neutral"
that they have include the concept of biometric technique, i.e., signature
dynamics) within the definition of a digital signature.)

>> ...the subject can disavow any transaction that allegedly
>> signed with their key. 
>Sometimes this is a good thing.  For example, if the verifier
>trusts the issuer, but the subject does not trust the verifier
>to keep the transaction confidential, these parties may
>agree to provide the subject added plausible deniability via
>lack of subject signature.

Why not just send plain text in that case? Or protect the message integrity
with an unsigned message digest??  

I haven't followed all of the various rococo arguments on this list in
particular depth, and am still far from convinced that this effort will ever
see the light of day or be adopted by anyone. But designing in plausible
deniability into a digital signature scheme that is advertised as a "Simple"
PKI should certainly qualify for nomination as oxymoron of the year!



Robert R. Jueneman
Security Architect
Novell, Inc.
Internet Infrastructure Division
122 East 1700 South
Provo, UT 84604