-----BEGIN PRIVACY-ENHANCED MESSAGE-----
Proc-Type: 4,MIC-CLEAR
Content-Domain: RFC822
Originator-Certificate: MIIBjjCCATgCAQMwDQYJKoZIhvcNAQECBQAwRjELM
AkGA1UEBhMCVVMxJDAiBgNVBAoTG1RydXN0ZWQgSW5mb3JtYXRpb24gU3lzdGVtc
zERMA8GA1UECxMIR2xlbndvb2QwHhcNOTIwNzE3MTQxMDM3WhcNOTQwNzE3MTQxM
DM3WjBgMQswCQYDVQQGEwJVUzEkMCIGA1UEChMbVHJ1c3RlZCBJbmZvcm1hdGlvb
iBTeXN0ZW1zMREwDwYDVQQLEwhHbGVud29vZDEYMBYGA1UEAxMPTWFyayBTLiBGZ
WxkbWFuMFowDQYJKoZIhvcNAQEBBQADSQAwRgJBALKoTt1yDKAHTjryR6hnLQfrK
zLdpCGYOz9PPvylTbBT3lfbL3uoyzJcnhAHBuLjT7GrFraHh1Ne3XQSpaKgofsCA
QMwDQYJKoZIhvcNAQECBQADQQCQHCqc+NvzVq24Wbf1xQCPOB9OPNYMZFVz71bRC
cHaqFF1+zzKGUIXM0mxnovxAm6wN1YxhdASqUXJxjwj0nX6
Issuer-Certificate: MIIBZTCCAQ8CAQIwDQYJKoZIhvcNAQECBQAwNzELMAkGA
1UEBhMCVVMxKDAmBgNVBAoTH1RydXN0ZWQgSW5mb3JtYXRpb24gU3lzdGVtcyBQQ
0EwHhcNOTIwNzE3MTMyMzI4WhcNOTQwNzE3MTMyMzI4WjBGMQswCQYDVQQGEwJVU
zEkMCIGA1UEChMbVHJ1c3RlZCBJbmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLE
whHbGVud29vZDBaMA0GCSqGSIb3DQEBAQUAA0kAMEYCQQDE+Wmy9YJM1p+NNPBwa
GAJWx1FvRNSTNaCa+ZgItM5x3Yl5+BFBIf/QfApcyiaOpFteindkKbryeu4WXd1v
C6HAgEDMA0GCSqGSIb3DQEBAgUAA0EAJQZuSuHg+LJy3wCv1YRd1l0eB66UOVDfZ
nbdG/u86flC8J/4Y+QaD7DM579sPbAF0Hv7Wv2yaMzlarafMGaibA==
Issuer-Certificate: MIIBVjCCAQACAQEwDQYJKoZIhvcNAQECBQAwNzELMAkGA
1UEBhMCVVMxKDAmBgNVBAoTH1RydXN0ZWQgSW5mb3JtYXRpb24gU3lzdGVtcyBQQ
0EwHhcNOTIwNzE3MTMyMjEzWhcNOTQwNzE3MTMyMjEzWjA3MQswCQYDVQQGEwJVU
zEoMCYGA1UEChMfVHJ1c3RlZCBJbmZvcm1hdGlvbiBTeXN0ZW1zIFBDQTBaMA0GC
SqGSIb3DQEBAQUAA0kAMEYCQQDCPJmfOJ/4QzZ1m6HAkliiC/Dio4xbfRj9b65O4
1bF3UdqND6Nq3rv78Hp5b7y1TL5oP3HJxgZ1Wghdkf/099FAgEDMA0GCSqGSIb3D
QEBAgUAA0EAgx2x12AK2z9+g05Qou5GyJEG0xN6rplsfvjsSC4NEQbuCIkDvJYp6
hzLZYFPNEdXQHNawHS5jhynu74JABtWrQ==
MIC-Info: RSA-MD5,RSA,S5zpCZwvrNNxJBgFPLSPBLHiOqd8XWtLJdZeDsSjCJ0
Ni7sM+5gWHaNc9zoV4m5zxRqbriOeRzGUEDhGF5evaA==
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.
...
In order to verify the signature on a message -- which includes
non-repudiation with the current suite of algorithms -- you need the
originator's public key. You also need to know that the public key
that you have is, indeed, the originator's. Certificates are used to
bind originators' public keys and their identities.
Certificates are part of a hierarchy which eventually leads to a
"root" certificate that you trust. In the Internet model, this would
be the Internet PCA Registration Authority (IPRA) certificate. So,
you must have the originator's certificate as well as the chain of
certificates up to the "root" (IPRA) for you to verify the
originator's signature. It turns out you also need the current
Certificate Revocation List (CRL) from each issuer in the chain to
insure that none of the otherwise valid certificates have been
revoked, but let's side-step that for now.
The important thing is that you have the certificates, not how you get
them. In the future, certificates will be available from X.500
servers and the like. Until that infrastructure is in place, ad hoc
means of exchanging certificates must do.
Certificates can be included in PEM messages, but that can greatly
incease the size of messages and their inclusion is not necessary if
the recipent already has them. In the case where the recipient has or
is assumed to have the necessary certificates, the
Originator-ID-Asymmetric header, which indicates the originator's
certificate using the issuer's distinguished name and the unique
serial number the issuer has assigned to the originator's certificate,
can be used.
The fact that the Originator-ID-Asymetric header is not protected
doesn't matter. It is only a pointer to the originator's certificate,
which is protected by the being part of a verifiable hierarchy of
certificates.
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?
The necessary certificates must be made avialable, otherwise signature
verification is impossible. If the originator won't make the
necessary certificates available to you, then it's just as if they had
never signed the message.
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.
Assuming that the message is authentic, the issuer's distinguished
name and serial number of the originator's certificate, which uniquely
identify the originators certificate, will tell you what you need. In
the future, automatic retrieval of such information will be possible.
As stands right now, if you cannot de-enhance a message for lack of
certificate(s), you must request them of the originator. If they
won't provide them, the digital signature is worthless. Once you have
them, you have them for all time. Think of the certificates as
"signature cards" that you must keep on file.
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.
Unfortuneately, this is the state of things. If the originator is
conscientous and includes his or her certificate and the chain up to
the trusted root in at least one message, you don't have to do
anything. Otherwise, without knowledge of any other means that the
originator or the originator's issuer uses to distribute certificates,
you'll have to ask. In addition to including certificates in mail
messages and waiting for X.500 servers, certificates could be made
avaialable by making PEM messages containing certificates available
via anonymous ftp, by mail responder, as text in a finger response, in
postings to a certificate news group, and so on.
...
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??
The cryptographic binding of public keys and distinguished names in a
verificable certificate chain is what is needed to verify the message.
The message signature is merely the last link in the chain. How you
come upon this independently verifiable chain is unimportant.
If you honor the PO before you have the certificate chain and are able
to verify the signature, you lose. If you can verify the signature
once, you can verify it again in front of the judge.
...
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?
...
There are certificates and issuer name/serial numbers. How you choose
to store them is your business. TIS/PEM uses a simple hashed
database. If you want to use SQL, flat ASCII, or anything else,
that's up to you. As for sending all the necessary certificates with
each message, as I said, it can really cause a message to grow.
Assuming I don't forget, I'll include my certificate and the chain up
to the TIS PCA certificate in this message. Once the IPRA is on-line
and TIS's PCA is under the IPRA, there will be at least one more
certificate. Given that large organizations might add another CA or
two to the hierarchy, there might be another certificate or two in the
message. Given that distinguished names, keys, and serial numbers may
be substantially larger than those in the certificates I'm including,
the certificates would take up even more space in the mail message.
As the originator, it's up to you whether or not you include the
certificate chain on any given message. If for no other reason than
aesthetics, I tend not to include certificates unless I know they're
needed.
...
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!)
There is no leap of faith, unless you consider trust in the RSA
algorith a leap of faith:-) The fact that message and certificate
chain may come to you via separate channels does not weaken their
relationship or the level of trust that PEM provides.
Mark
-----END PRIVACY-ENHANCED MESSAGE-----