PEM appears to account for message integrity, originator authentication and
possibly confidentiality. However there seems to be no PEM capability to deal
with nonrepudiation.
Your question is not as naive as it might have appeared at first glance, nor is
the matter quite as simple as some have indicated.
Nonrepudiation (as the term is most often used) is primarily a legal matter,
not a technical matter, although PEM provides some mechanisms to assist in this
area.
PEM certainly accounts for message integrity (the message has not been modified
since its creation); originator authentication (the person who signed this
message was in possession of the secret key which is part of a pair of keys,
the public portion of which is bound to a user whose name/e-mail
address/"identity" is provided in an X.509 certificate; and optionally
confidentiality (cryptographically-enforced by-individual need-to-know controls
determined and applied by the originator).
"nonrepudiation" looks to be a method that ensures
the submission of binding proposal (such as a bid)
by a vendor/trading partner cannot be denied.
Currently, if I send registered mail with the Post Office,
I get back a signed receipt that the addressee did get
my letter. The receiver may not have opened it, but it was
definitely received.
There appears to be nothing like this in PEM.
Is this correct?
This is a relatively minor portion of the total spectrum of nonrepudiation,
specificially nonrepudiation of receipt. You are correct that PEM does not
provide this feature. X.400 alleges that it does, but it can only confirm that
the MTA transferred the message to the UA -- it cannot provide any assurance
that the message was actually received, processed, or read by a human user.
Proving that a message was received without the intervention of a trusted and
tamper-proof UA would be extremely difficult. More to the point, it isn't
particularly useful -- most of the time you can get the recipient to sign an
acknowledgement that says something like "I acknowledge receipt of a message
whose message digest was blah, and date/time blah." If the recipient won't sign
such a receipt the originator can generally call off the entire transaction. As
someone else pointed out, the post office Registered Mail receipt only confirms
the receipt of the envelope -- it says nothing about the contents.
The more difficult issues in the area of nonrepudiation are being addressed by
a working group of the American Bar Association's Science and Technology
Section, Information Security committee, and they are about to show up in
public as a result of efforts now underway in the State of Utah and the Utah
Department of Courts to draft legislation that specifically empowers the use of
digital signatures for purposes of commerce and trade. The draft Digital
Signature Guidelines with Model Legislation document that has been produced to
date is 84 pages long, and is replete with legal citations and footnotes. And
contrary to what might be expected from a bunch of lawyers, the scientific and
cryptological foundations have been and are being quite thoroughly addressed.
As I said earlier, nonrepudiation is ultimately a matter for the courts to
decide, and the primary issue is the where the burden of proof lies in legally
establsihing the facts of a situation. The more bulletproof and ironclad the
technical foundations for a system might be, the more the burden of proof will
shift to the defendent, but nothing is ever considered to be absolutely
infallible.
The primary technical consideration in this area involves the establishment
beyond a reasonable doubt, to an independent third party, that the person who
apparently signed the document (as indicated by the digital signature) was in
fact the signer. Thir major issue here is whether the private key necessary to
sign a document could have been stolen or misapproriated from the authorized
key holder. Becasue we don't want people to be able to write checks in
disappearing ink, the general principle should be that to whatever extent a
person has some moral responsibility and/or legal liability for his signature,
that responsibility and liability should persist until the binding between the
public key and the user's identity is publically disavowed though the
Certificate Revocation process.
So one of the major issues in nonrepudiation lies in preparing a defense
agasint the person who falsely claims that his private key was stolen or
compromised, AND THAT THE PERPETRATOR BACKDATED THE MESSAGE so as to make it
look as though it was signed before the certificate was revoked.
The mechanism used to ascertain the validity of a certificate at any point in
time is somewhat cumbersome, as it depends on a double negative that is delayed
in time. If, at some point in time after the message in question was signed,
the recpiient can produce a Certificate Revocation List which does NOT contain
the certificate in question, then it must be assumed that the Certification
Authority that stands behind that certificate had not in fact revoked it.
However,at present the digital signature itself does not contain a date/time
stamp, and even if it did, it would in most cases be under the control of the
originator and therefore not considered to be particularly trustworthy. So in
order to more firmly establish nonrepudiation, it is necedssary to go to a
trusted third party such as a notary, and ask the notary to affix a trustworthy
time stamp on the document itself (or on the message digest), AND (ideally) to
enquire of the CA as to the CURRENT validity status (within the period between
initial validity date and the expriation date, and not revoked for cause) of
the certificate in question, and then wrap both the message digest and the
statement of current validity with the digital signature of the notary. This
still doesn't establish the actual time of receipt of the message -- it could
have been sitting around for days before the notary got around to it, but it at
least establishes the latest time it could have been signed.
Although there are a number of valid reasons why the existing CRL mechanism was
designed that way, it is certainly the case that for many transactions the
latency between the transaction and the next scheduled publication of a list of
revoked certificates may be too long to be useful. In this case it may be
necessary to send the message in question to the Certification Authority
itself, and let the CA affix its signature attesting to the validity of the
certificate at that moment.
Although the PEM specification does not provide any particular protocol for
this purpose (using either solution), and therefore there is a question of
interoperability and machine interpretation, the necessary mechanisms to do
this are provided. For the general e-mail case, full-blown nonrepudiation is
seldom likely to be needed. For more business-oriented applications such as
EDI, it is expected that a more standardized process would be appropriate and
would be devised.
Another aspect of legal nonrepudiation concerns the issue of authority to sign
a particular transaction, and here the legal systems differ signficantly from
country to country. In the US, the Uniform Commercial Code provides for an
assumption of apparent authority -- i.e., if someone signs a pruchase request,
the vendor has a reasonable right to assume that the individual was in fact
authorized to sign it. There are limits, however, and for complex and
high-value transactions lawyers in the US are expect to conduct a due process
investigation so that the secretary or janitor can't sign a purchase order for
a $10 billion aircraft carrier, for example. In international trade, civil law
notaries perform essential the same function, details omitted.
At present, the X.509 certificate used by PEM does not provide for an explicit
indication of an individual's authority, although there are some attributes
that could be included in the Distinguished Name portion of the certificate
that can provide at least a hint of authorization, such as the Organizational
Role attribute. In general, however, version 1 and 2 of X.509 does not provide
an adequate mechanism for such purposes. Version 3 of X.509, which is in the
final stages of adoption as a Technical Corrigendum to the '93 X.500 spec,
provides the ability to add optional attributes to the basic X.509 certificate,
as well as a way of specifying whether a proper understanding of such an
attribute is optional or mandatory (critical). A basic set of proposed
extension attributes has been defined, but other standards organizations,
notably X9.30 are also working the same issues and there may be some overlap in
approach to such issues. At present, the positon taken within the PEM
specification is that such extensions may be possible in the future and should
be encouraged, but version 3 of X.509 has not been formally adopted, nor has
the issue of a core set of extended attributes been considered or resolved.
There are a couple of more issues regarding nonrepudiation that should be
considered.
As Robert Shirey indicated, quoting RFC1421,
Based on these principles, the following facilities are provided:
1. disclosure protection,
2. originator authenticity,
3. message integrity measures, and
4. (if asymmetric key management is used) non-repudiation of
origin,
but the following privacy-relevant concerns are not addressed:
1. access control,
2. traffic flow confidentiality,
3. address list accuracy,
4. routing control,
5. issues relating to the casual serial reuse of PCs by
multiple users,
6. assurance of message receipt and non-deniability of receipt,
7. automatic association of acknowledgments with the messages
to which they refer, and
8. message duplicate detection, replay prevention, or other
stream-oriented services
In retrospect, I would have said that 5, 6, 7, and 8 relate to integrity
issues, and 7 and 8 in particular bear heavily on nonrepudiation.
Consider the case of the naive user, who, when asked a questions, sends back a
signed message that says only "Yes." This of course is fraught with peril, for
the "Yes" could be attached to virtually any question, from "Will you marry
me?" to "Do you agree that we have just verbally agreed that you will
immediately transfer to me all of your worldly goods and let me sleep with your
wife, in consideration of which I have given you the sum of $1.00?"
It isn't clear that PEM particularly needs to address this issue. Hopefully,
users would not be quite so stupid, but would instead refer back to the message
in question, perhaps by referring to the message digest.
However, point number 8 raises another issue which I only recently realized,
and that involves the vulnerability to a replay attack.
Consider the case of someone who signs an electronic funds transfer
authorization to the effect "please debit my acount number #xxxxx in the amount
of $1000, and credit it to the account #yyyyy of Mr. Z."
What happens if Mr. Z somehow obtains a copy of that signed transaction, and
submits it to the originator's bank as often as he pleases. My books are still
packed after yet another office move, but unless my memory fails me, THERE IS
NOTHING PROVIDED IN PEM THAT WOULD PROVIDE EITHER A DATE/TIME
STAMP OR A TRANSACTION NUMBER TO SUCH A TRANSACTION.
Anyone who has a compliant PEM implementation available can quickly verify this
assertion -- just sign a given piece of text two times in a row, and see if the
results are identical. If they are, then the originator has no effective
defense against a replay attack.
Again in retrospect, and I certainly wish that I/we had spotted this problem 5
years ago, I have to conclude that the basic ASN.1 definition of the SIGNED
attributein x.500 is fundamentally flawed, and should be corrected by adding
both a date/time stamp (perferably UT time to the second) AND a sequence number
to the basic definition of a signature.
Although the date/time in the signature cannot necessarily be presumed to be
trustworthy or accurate, it does carry some presumptive weight. If either party
can provide evidence that the date/time had been reasonably accurate for
messages sent before and after that message, and that the message was received
by the recipient within X minutes of the apparent time of signing, that would
ocarry some real weight. Moreover, like a predated or postdated check, it
provides the recipient with a readily available reasonableness check. Although
a perpetrator might submit N copies of a given transactions in a single day, or
even in a single week without detection, it is much less likely that he could
do this for months or years.
Although a date/time field provides a strong reasonableness check that the
recipient can perform (and arguably has to duty to do as part of his minimal
due process), the use of a sequence number in combination with the extended
attributes provided by X.509 v3 provides for a much finer level of control. For
partiuclarly high value transactions, it might be reasonable for the CA to
create a certificate that grants the originator to create only N signatures,
from sequence number M to M+N. The certificate itself can be replicated without
harm but if the originator create more than N signatures something is obviously
wrong.
It has to be mentioned that the possibility of a replay attack is not prevented
by the usual notarial process of confirming a certificate's validity. Indeed,
the perpetrator might send two copies of identical documents and signatures to
two separate notaries for confirmation of the message's validity, and there is
no way that the two notaries or the recipient would necessarily determine that
in fact this was one message received two times, albeit with two different
notarial stamps.
I hope that I am wrong, and that somewhere in the PEM spec there is a provision
for a date/time stamp, at least. If not, I think that the problem ought to be
fixed, either through a Defect report and Corrigendum to he X.500 SIGNED
attribute, or, less desirably, by a modification to the MD5/RSA message digest
and signature algorithm definition. If all else fails and neither of those two
approaches are viable, then PEM, PEM/MIME, etc., can add implement either a
unique sequence number or an Initialization Vector (nonce field) that changes
with each message.
What are some ways have nonrepudiation while using PEM?
This is probably more than you wanted to know, but I hope it has been helpful.
Mike Bridges
NASA/AMES
Regards, Bob
--------------------------------
Robert R. Jueneman
GTE Laboratories
40 Sylvan Road
Waltham, MA 02254
Internet: Jueneman(_at_)gte(_dot_)com
FAX: 1-617-466-2603
Voice: 1-617-466-2820