I made the statement:
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.
and Ray says:
-----BEGIN PRIVACY-ENHANCED MESSAGE----- >Proc-Type: 4,MIC-CLEAR
Content-Domain: RFC822 >Originator-ID-Asymmetric: >
ME0xCzAJBgNVBAYTAlVTMSAwHgYDVQQKExdSU0EgRGF0YSBTZWN1cml0eSwgSW5j >
LjEcMBoGA1UECxMTUGVyc29uYSBDZXJ0aWZpY2F0ZQ==,12 >MIC-Info: RSA-MD5,RSA,
O7HHAVx5U3n3/6mwYT9erNdG2nI7NKTCu43ROghKxkUlvGs6SIHaSORuWqe/MCdn >
eaNzAuywk3LdAA6cjE0fgOomn7aGYqf5vKpyBlqQ7b5mt0Q6YIAfrbFsu1eqlfUb
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.
When Originator-ID-Asymmetric is used, it points to a specific
certificate >and presumes that the recipient already has or is able to
obtain that >certificate.
Not true - the Originator-ID-Asymmetric points to a I-A (actually a CA).
If you didn't care to run my previous msg. through PEM and have since
disposed >of it, you can always ask me to send you my certificates. Or,
if the RSA >Persona CA provided retrieval services, which it doesn't,
you may be able >to send it a request for the certificate identified in
this msg.
I don't really understand the database structure that is imagined here,
perhaps the folk at tis.com could help. If I don't know the origin, and
cannot rely on the "From:" field, just how is it that I look up the
public key knowing only the Issuing Agent and a version number for a
certificate which I don't have. And what makes you think that the CA
would give me the certificate I want? How will he find it? - by trying
every single key in his data base to see if it verifies??? (Don't
forget, I don't know what the originator's DN is and cannot rely on the
DNS) Even if he does find it, what contractual arrangement must I have
with your CA to get your certificate? I think PEM had better create a
message for the CA, "Please_Send_a_DN_for_the_Enclosed_DNS" if you want
any of this to do anything at all.
If I am to request the certificate from you, what mechanism do I use?
Is there a structured message "Please_Send_the_Certificate", and just
who do I send this message to since I don't have a reliable message
origin? Or do I just send a non-structured "Please send the
certificate" as a reply to the DNS which the sender must handle
manually. And to think that you guys have some pretension to handle EDI
messages!! --Forget that, EDI has one goal and that is to eliminate
manual handling of messages.
and then Steve Says:
In order to validate a signed message, the recipient must have >the
public key of the originator. In PEM, such keys are made >available in
the context of certificates. If the originator's >certificate is not
present in the PEM message header, (because the
Originator-ID-Asymmetric field has been employed, then the recipient
is assumed to have access to the originator's certificate through some
other means, e.g., caching. To support non-repudiation, the recipient
would present this certificate with the signed message to a third
party.
The only place where non-repudiation is important is in front of a
judge. (that's because authentication is sufficient if there is trust
between the parties) Imagine the scenario
you: The Purchase Order proves that x owes me $100,000.
Judge: How do you know the PO is from x?
you: Well, the PO was signed by someone who the CA says was x.
Judge: But does the PO say it's from x?
you: No, but the unsecured header (or some implication) says x.
Judge: What will the independent party (the CA) testify to?
CA: We will say that the signature on the body of the PO is
verified by the public part of x's signature.
Judge: Will x say that he signed it as his own PO?
X: No because the PO is not from me. (he REPUDIATES the PO)
Judge: So if CA testifies that x signed the document, but x says that
it is not from him, who will testify as to the ORIGIN OF THE PO?
And please remember that hear-say evidence is not acceptable.
you: Well, x did request a certificate from CA which I was able to
obtain by some other means which ties the public part of his
key to the distinguished name, which really should be relied
on as evidence of the origin of the PO.
Boy is that a strong argument. -- Now tell me again why it is that PEM
just doesn't send the certificate (or at least the DN) with the
protected part of the message??
It really makes no difference whether the (originator) >certificate
was included in the header or supplied externally. >Without the
certificate the recipient cannot validate the signature.
Sure would be easier if the originator made no assumptions about the
data base that the recipient has. By the way, where is the database
requirement for PEM specified?
Certainly you are correct in NOT relying on information in the >From
field (not the "To" field), and it is not PEM's intent to suggest >that.
However, you seem to suggest that unless a PEM message contains >all of
the data required to provide non-repudiation that the service >is not
provided by PEM.
It seems that you have said it yourself!
PEM involves a larger context than just the message format, e.g., >the
certification system (including CRLs), and all of that must be >taken
into account when considering non-repudiation.
So, if I do not rely on information in the "From:" field, exactly what
information do I rely on to tell me the origin of the message?
Please go back to the statement that I made. I feel even more strongly
than when I made that statement that the RFC1421 statement on
non-repudiation is either dead wrong, or at the least it requires a leap
of faith in a string of unstated assumptions. And more to the point,
the string of assumptions is unnecessary, PEM could be far more secure
by explicitly including the DN (and the message ID and date as well for
that matter!)