Rich Ankney wrote:
I've been having a side conversation with Ambarish Malpani of Valicert.
He raised the following question (in a different context): can we really
ensure that the issuer DN is unique? Clearly it will (or should) be in
the context of a single root CA (assuming each CA ensures there are
no duplicates in the names it certifies). But this may not be true where
we have cross-certification. Should we include something else to make
the construct unique (e.g. hash of the CA public key)? (This affects
things besides CMS, of course...)
I feel what that in the wake of the ceaseless
expansion of the Net, and the ever increasing
commerce through it, and our accepting the
need and urgency of the security aspects - in
a never before fashion, it becomes important
that we try to come up with some
international consensus on a central
certificate issuing and managing authority.
Something like what IANA is for IP addresses.
The central assigned authority can be
responsible for passing the busk for issuing
certificates to different authorities, and
also see to the uniqueness of the serial
numbers, by supplying a different set of
number to each of them.
Also it would be advisable to have a
foresight to the magnitude of the serial
numbers and other associated numbers required
for the cause, to prevent some number crunch
in the near future, since this thing is
really going to catch on. Learning from past
for a better future is the IT industry's
From: John Pawling <jsp(_at_)jgvandyke(_dot_)com>
To: 'Ietf-Smime (E-mail)' <ietf-smime(_at_)imc(_dot_)org>
Subject: RE: Inclusion of the issuer and serial number in authenticated
Date: Wednesday, February 25, 1998 5:02 PM
I agree with Jim Schaad's issuer/serialNumber authenticated attribute
1) I agree that it meets a valid requirement because it is certainly
possible to have multiple certs containing the same public key material.
2) It provides the flexibility to bind the signer's cert (via the
issuer/serialNumber) with the signed data without forcing the signer to
always include the signer's cert in the signedData object. In other
if the signer knows that the recipient already has the signer's cert,
the signer should not be forced to send the signer's cert in the
3) It is backwards compatible with S/MIME v2 legacy software because the
legacy software will ignore the new attribute, but it can still verify
J.G. Van Dyke & Associates, Inc.