ietf-smime
[Top] [All Lists]

Re: [smime] [pkix] I-D Action:draft-ietf-pkix-rfc3161-update-07.txt

2009-10-22 06:15:22
Stefan,

Secondly, the issue is not whether to use ESSCertID or not. 
The Issue discussed in PKIX is the security considerations for using a hash 
stronger than SHA-1.

Yes, exactly I agree that discussion is about the impact of upgrade from 
ESSCertID to ESSCertIDv2. And for that reason this specific issue must be 
described carefully not to confuse people that the whole usage of ESSCertID/v2 
is unimportant.

CMS signature (RFC 5652) when the ESSCertID/v2 is not used is open for many 
substitution attacks which are realizable with and also without a Malicious 
trusted CA.

Generally speaking if ESSCertID/v2 is not used in CMS, then the right public 
key for verification of signature must be selected according to test if the 
digital signature is correctly verified.

Without ESSCertID/v2 the connection of signer’s attributes with the public key 
is not protected and for that reason any kind of public key carries can be used 
e.g. certificates X509 v1...v5, PGP... Such unprotected connection of the 
signer’s attributes with the signer’s public key by CMS signer signature could 
cause many attacks. Two attacks which I have described are realized by trusted 
CA which is not Malicious. The number of possible attacks if the connection is 
not protected is endless. I have not mentioned e.g. the attack on identity in 
certificates where the certificates may be issued for different purposes with 
different identity values for the same public key. Another attack could be if 
the relying system accepts more than one CA and the attribute certificate 
connected with certificate issued in one CA can be accepted also if issued in 
the second CA, then by substitution attack you can achieve a granted access to 
some systems.

When the qualified certificates are used, then you can simply break the 
nonrepudiation of QES. If you have sent the same signature with the different 
certificate issued for the same public key to different organization, the legal 
action can be realized in a different way. If those organizations are not able 
to compare the QES signature, then nobody can detect such attack.
 
I agree that the registration process could be a big hole if the registration 
person under some pressure/whish of external powerful group issues a qualified 
certificate with the identity of someone else for people from the powerful 
group, then the effect of QES acceptance in legal actions like selling the 
house could be catastrophic, but it must be solved pursuant to rules of the 
registration authority.

        Regards, 
        Peter Rybar
         
        tel.: +421 2 6869 2163
        fax: +421 2 6869 1701
        e-mail: peter(_dot_)rybar(_at_)nbusr(_dot_)sk 
        e-mail: peterryb(_at_)gmail(_dot_)com
        http://elpi2.szm.com/


_______________________________________________
smime mailing list
smime(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/smime
<Prev in Thread] Current Thread [Next in Thread>
  • Re: [smime] [pkix] I-D Action:draft-ietf-pkix-rfc3161-update-07.txt, Peter Rybar <=