Dr. Stephen Henson wrote:
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 did misunderstand what the difference is between authenticated attributes and
attribute certificates. Someone in my office has shown me the light; however,
I believe the attack is different, but the end result is the same. The end
user believes he/she has received a message from an authenticated source. See
below.
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.
This still does not prevent a masquerade for authenticated attributes. Let's
say you have the following:
Root: CA A CA B
Sub CA: - CA A
Cert Duke, 822 Duke, 822
Both Dukes have issuers of CA A and serial number 822. Root CA B's Duke can't
change Root CA A's Duke's messages, but he can pull CA A's Duke's message's and
replace them with his. The recipient will see that the message was signed by
Duke, 822 whose issuer is CA A and is therefore linked to the authenticated
attribute. The key to CA B's Duke messages completing their task is the
countersignature. If the process performing this function trusts CA B, it will
perform chain validation as well and therefore accept CA B's Duke. Based on
section 11 of the CMS and the type of attributes being certified this may not
be critical (their not privilege attributes). What is critical is the content
of Duke's message.
[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.
I'm sorry you feel this way. The scenario I described, IMHO, is no less
important than the one you describe. I would think the goal is to account for
all vulnerabilities and try and develop solutions for them.
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.
I agree. Unfortunately, the CA in question probably won't put Name and Path
constraints on itself. I as a user or a peer CA have no say on what
constraints a CA will impose on itself. IMO, one way that a targeted CA can
protect itself is for the CA to employ attributes and techniques of its own to
prevent such attacks. The SHA-1 binding between a base certificate and
attribute certificate in my previous example would prevent CA B's CA A clients
from being able to claim ACs of CA A's clients.
I, as the user, have the right to trust or not trust a CA. You and I understand
the intricacies of trust and CA's, but I seriously doubt that the general
public does. The goal should be to "teach" applications how to detect such
attacks under these conditions. When a user runs an application to e-mail or
browse the Web, they are relying on the application to notify them when
something is going wrong.
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.
I agree, but CA B would probably be removed after an attack took place and only
if the attack was discovered. Thanks for informing me about the other attack.
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.
JAMES M. HAYES, Capt, USAF
NSA