James M Hayes wrote:
Hello All,
This email was sent to me concerning item 2 of the Charter Change. I am new
to the list so I'm not familiar with all of the on going issues. I have been
looking at attribute certificates and how to bind them to base certificates
(signing certificates?).
From: Jim Schaad
(Exchange)[SMTP:jimsch(_at_)EXCHANGE(_dot_)MICROSOFT(_dot_)com]
Sent: Friday, May 01, 1998 7:48 PM
To: Ietf-Smime (E-mail)
Subject: Charter Change Request
2. A draft proposing a new authenticated attribute which carries the issuer
and serial number fields to more tightly bind the signing certificate into
the signature itself.
The binding between an attribute certificate and a X.509 v3 certificate in a
multiroot environment may not be unique. The current X.509 standard calls
for a binding based on either the subjectName or issuer name and serial
number. The proposed Charter Change Request would use the latter. A
proposed binding of issuer name and serial number may not be unique in the
context of a certificate masquerade. Let me use an example before I get into
defining a proposed "relatively" unique binding.
Item 2 refers to the autenticated attributes (see S/MIME CMS) not
attribute certificates as such. I believe its purpose is to prevent an
attack mentioned previously.
I'll briefly describe it: suppose a user has two certificates signed by
different CAs (A and B) but with the same public key. Under the current
CMS the issuer and serial number field is not authenticated. Thus an
attacker can take a message signed by a certificate of CA A and
transform it into an equally valid message signed by the same user but
for CA B.
Adding an authenticated attribute with issuer and serial number prevents
this attack because the issuer and serial number is now signed by the
message originator.
[interesting rogue CA discussion deleted]
I think this is a bit off topic for this list but I think the line has
to be drawn somewhere: if one assumes rogue CAs can exist then all
manner of undesirable consequences can result. It doesn't even need a
rogue CA: CA private key compromise or just issuing certificates with
improper extensions can have the same result.
If a CA is not a root CA then some problems of this nature can be
avoided by use of the basicConstraints pathLenConstraint by preventing
CAs from producing subordinate CAs. In the case of root CAs this is not
possible: but that's likely to be the least of your worries if such a
rogue CA decides to e.g. issue object signing certificates for e.g.
ActiveX controls and a subjectName of whoever they wish to blame.
In the example given if CA B decided to forge its own subordinate pseudo
CA A then the only real option of the server would be to no longer trust
CA B. This is the only sensible option for the server IMHO.
Steve.
--
Dr Stephen N. Henson.
UK based freelance Cryptographic Consultant. For info see homepage.
Homepage: http://www.drh-consultancy.demon.co.uk/
Email: shenson(_at_)bigfoot(_dot_)com
PGP key: via homepage.