Non-repudiation

Gentle PEM nuts:

As I wait for a TIS-PEM distribution, which never seems to come, I have
been experimenting with decoding some of the PEM messages which have
been sent to this list.  Interestingly enough, I have found that the
TIS-PEM messages appear to follow the standard, however they do not
exhibit the property of non-repudiation.  I list below what I have found
in the hope that someone can show how this could be.

RFC11421 says:  ----------------------------------------------------

3.  Services, Constraints, and Implications

   This RFC defines mechanisms to enhance privacy for electronic mail
   transferred in the Internet. The facilities discussed in this RFC
   provide privacy enhancement services on an end-to-end basis between
   originator and recipient processes residing at the UA level or above.
   No privacy enhancements are offered for message fields which are
   added or transformed by intermediate relay points between PEM
   processing components.

   If an originator elects to perform PEM processing on an outbound
   message, all PEM-provided security services are applied to the PEM
   message's body in its entirety; selective application to portions of
   a PEM message is not supported. Authentication, integrity, and (when
   asymmetric key management is employed) non-repudiation of origin
   services are applied to all PEM messages; confidentiality services
   are optionally selectable.
    .
    .
    .
   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,


4.6.1.1.1 ENCRYPTED

   The "ENCRYPTED" specifier signifies that confidentiality,
   authentication, integrity, and (given use of asymmetric key
   management) non-repudiation of origin security services have been
   applied to a PEM message's encapsulated text.  ENCRYPTED messages
   require a "DEK-Info:" field and individual Recipient-ID and "Key-
   Info:" fields for all message recipients.

---------------------------------------------------------------------

First of all I should note that there is a discrepancy about when
non-repudiation is actually provided, but, be that as it may, it is my
contention that non-repudiation is only present in the case where the
"Originator-Certificate" Field is provided.  In the case where
"Originator-ID-Asymmetric" Field is provided, there is no protected name
of the originator, thus there is no origin to protect.  Now some may say
that the "To:" field in the header could provide this, but that field is
not protected against alteration, and, in fact, mail gateways are in the
very business of altering that field.  My own copy of the pem-dev
mailings does not including anything like a meaningful "To:" field which
is why I have had to ask several people who a message in pem-dev was
authored by.

Some may also say that knowing the Issuing-Authority (from the
"Originator-ID-Asymmetric" Field) is sufficient to nail down the origin,
but that is only true if I can request the the name of the owner just by
having the public component of the key.  That looks like "caller-ID" and
it certainly doesn't look like PEM (ie PRIVACY ENHANCED Mail).  In any
case, I don't know why a CA would give me a name just knowing the value.

All-in-all, I would say that PEM cannot make the claim that "...,
non-repudiation of origin services are applied to all PEM messages" as
RFC1421 does.

Tom Jones - ViaCrypt div.  of Lemcom Sys dockmaster.ncsc.mil