Date: Sunday, 23 May 1993 12:30 edt >From: Richard.Ankney at
EMC2-TAO.FISC.COM >Subject: Non-repudiation >To: TCJones at
DOCKMASTER.NCSC.MIL >In-Reply-To: The letter of Sunday, 23 May 1993
4:33am ET > >The Originator-ID-Asymmetric field identifies the CA
(issuer) and the serial >number (misnamed as version number) of the
certificate containing the public >key needed to verify the certificate.
The serial number is unique within all >of the certs issued by the CA,
so it is at least as reliable as the signer's >DN. (The signer may have
multiple certs, of course.) So using issuer/serial
is at least as useful as using the DN if the cert is not sent along
with the >message. I'm not sure there's really an issue here. What am
I missing??
Ahhhh - Thank you, you are missing nothing, it is I that was missing
that connection. I made the mistake once of reading
Originator-ID-Asymmetric and thinking that it was an originator ID and
then I compounded the mistake by reading version subfield and thinking
that it was a version no.
Given that fact I can now make a better question about my understanding
of the local data base.
- - from RFC1421
7. Example User Interface and Implementation
The IK/certificate cache is, effectively, a simple database indexed
by mailbox names. IK components are selected for transmitted
messages based on the originator's identity and on recipient names,
and corresponding Originator-ID, "Originator-Certificate:", and
Recipient-ID fields are placed into the message's encapsulated
header. When a message is received, these fields are used as a basis
for a lookup in the database, yielding the appropriate IK component
entries. DEKs and cryptographic parameters (e.g., IVs) are generated
dynamically within the program.
The above lead me to think of the data base as being indexed by the
originator (or recipient). That lead me to frame questions that were
entirely inappropriate. The reason to index by mailbox name, as the
RFC1421 suggests, is apparently related to the originator creating a
DEK.
If the receiver of a message is to retrieve the certificate, then the
certificate cache must be indexed by the Originator-ID-Asymmetric which
I now understand to be the CA, certificate serial no.
The sender will hopefully know who he is and append the correct field.
A prudent receiver who wishes non-repudiation will archive the message
with the certificate.
- -
If the above analysis is not correct I would appreciate hearing where I
have gone wrong.
I am still mystified by a standard that espouses origin non-repudiation,
and yet fails to identify the origin in the secured message.
Tom Jones - ViaCrypt div. of Lemcom Sys
dockmaster.ncsc.mil