ietf-smime
[Top] [All Lists]

Re: Inclusion of the issuer and serial number in authenticated information

1998-03-25 01:13:58
John,

Thank you for your detailed scenario. Since I am coming to the LA
meeting, I think it would be useful to have a meeting between all the
people interested on this topic to explain the story around this since I
think it will be hard to provide all the explanations by E-mail.

Some time slot in the smime working group agenda would also be
appropriate.

I would nevertheless attempt to tell what the problem is in your
scenario.

I agree with Russ and Eric that we should stick with Jim Schaad's original
proposal to define the signing-certificate attribute type as the CMP
IssuerAndSerialNumber syntax.  Here is the scenario as I see it:

1) The originator populates the signedData signerInfo signing-certificate
authenticatedAttribute with the IssuerAndSerialNumber of the signer's cert
containing the public key required to validate the signer's signature of the
signedData signerInfo.

2) The originator calculates the signature value of the CMS signedData
signerInfo as described in CMS; therefore, the  signing-certificate
authenticatedAttribute containing the IssuerAndSerialNumber of the signer's
cert are bound with the content.

3) The originator sends the signedData to the recipient.

4) The recipient decodes the signedData to determine the signerInfo
IssuerAndSerialNumber identifying the signer's cert.


Stop. Here is where the problem is. The IssuerAndSerialNumber may or may
not allow to fully identify the right CA, in particular when FDNs are
not used for CA names. In case of homonyms between CA names, a CA could
provide a certificate to some people with the same CA name (because of
homonymity) and the same serial number (purposely). Of course, this
"indelicate" CA would not have performed POP (Proof of Posession of the
private key) but when this would be invisible to the checking process.
The end result is to believe that the signed document has been signed by
some one else, which is pretty bad or to allow ambiguity of signature. 


5) The recipient obtains the signer's certificate issued by the identified
CA which includes the designated serial number.

6) The recipient builds a cert path connecting the retrieved signer's
certificate with the verifier's trusted key and validates that cert path as
per PKIX and X.509.  Among other things, this reliably binds the public key
with the subject name, issuer name and serialNumber in the signer's cert.

7) The recipient uses the validated signer's public key to verify the
signature of the received signedData signerInfo.  This verifies (among other
things) the binding between the signing-certificate authenticatedAttribute
and signedData content.

8) The recipient compares the verified signing-certificate
authenticatedAttribute with the verified issuer name and serialNumber of the
signer's cert.

This entire process verifies:

a) that the correct public key was used to verify the signature of the
SignedData signerInfo;

b) the binding of the public key used to verify the signature with the
subject name, issuer name and serialNumber (among other things) in the
signer's cert;

c) the binding of the signedData content with the signing-certificate
authenticatedAttribute (i.e. IssuerAndSerialNumber of signer's cert)
included in the verified signerInfo; and

d) that the correct public key used to verify the SignedData signerInfo
signature was extracted from the correct, verified signer's cert as
identified by the verified signing-certificate authenticatedAttribute.

I don't see any holes in the aforementioned strategy.  There is always the
"renegade CA" argument, but the renegade CA's cert must be a part of a valid
cert path than can be verified to the verifier's trusted key.  It will be
extremely rare for a renegade CA's cert to be a part of a valid cert path
than can be verified to the verifier's trusted key.  The use of the
nameConstraints extensions in each cert in the cert path can be used to
limit the damage that can be done by a validated renegade CA.  The main
defense is that the users will notice that something is wrong and report the
renegade CA.  In that case, the renegade CA will be shut down or the cross
cert to its domain revoked.

I don't see any purpose to add a hash of the certificate to this process

The purpose of the hash is to allow to make the difference between the
two certificates mentioned above. Thus, at the verification time, the
problem mentioned above is detected or suppressed.

because the signer's cert path is verified to the verifier's trusted key.  I
don't believe that there will ever be a case in which there are multiple
CA's using the same Issuer DNs that are issuing certs that include the same
serial numbers and the same public keys that can all be validated via a
valid cert path to the verifier's trusted key.

I also don't see any purpose to use the X.509 IssuerSerial syntax because
all subject and issuer names MUST be populated (i.e. not an empty SEQUENCE)
in S/MIME-compliant v3 X.509 Certificates, except that the subject DN in a
user's (i.e. end-entity) certificate MAY be an empty SEQUENCE in which case
the subjectAltName extension will include the subject's identifier and MUST
be marked as critical.

CMS is to be used by S/MIME and non S/MIME compliant applications.

Denis

================================
John Pawling, jsp(_at_)jgvandyke(_dot_)com
J.G. Van Dyke & Associates, Inc.
www.jgvandyke.com
================================

-- 
      Denis Pinkas     Bull S.A.          
mailto:Denis(_dot_)Pinkas(_at_)bull(_dot_)net
      Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
      78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

<Prev in Thread] Current Thread [Next in Thread>