Would this capability be used to intentionally transit a well-defined domain
of authority?
Would, say, a SET certificate issuer have any problems with an application
that enables S/MIME usage of a SET-certified public key and corresponding
private key?
Or is this capability being established to facilitate, for example, the
sharing of a key pair among a group of related users, all of whom are
operating within the same domain of authority?
If the intent is to address the former, either singly or in combination with
the likes of the latter example, then attention should be given to technical
enforcement of policy.
In any case, use of a hash of the CA's public key in the message should be
aligned with the use of keyIdentifier form of AuthorityKeyIdentifier in
end-entity certificates.
Mike
-----Original Message-----
From: Rich Ankney <rankney(_at_)erols(_dot_)com>
To: 'Ietf-Smime (E-mail)' <ietf-smime(_at_)imc(_dot_)org>; John Pawling
<jsp(_at_)jgvandyke(_dot_)com>
Date: Wednesday, February 25, 1998 6:44 PM
Subject: Re: Inclusion of the issuer and serial number in authenticated
information
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...)
Regards,
Rich
----------
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
information
Date: Wednesday, February 25, 1998 5:02 PM
All,
I agree with Jim Schaad's issuer/serialNumber authenticated attribute
proposal because:
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
words,
if the signer knows that the recipient already has the signer's cert,
then
the signer should not be forced to send the signer's cert in the
signedData.
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
the
signedData signature.
================================
John Pawling
jsp(_at_)jgvandyke(_dot_)com
J.G. Van Dyke & Associates, Inc.
================================