ietf-smime
[Top] [All Lists]

RE: FW: Charter Change Request

1998-05-07 07:45:25
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


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