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

From: "Peter Rybar" <[email-masked]>
Date: Wed, 21 Oct 2009 12:10:21 +0200

From: Peter Rybar [mailto:[email-masked]] 
Sent: Wednesday, October 21, 2009 11:41 AM
To: [email-masked]'
Cc: [email-masked]'; [email-masked]'; [email-masked]'
Subject: RE: [pkix] I-D Action:draft-ietf-pkix-rfc3161-update-07.txt

Dear all,

The [email-masked] timestamp discussion about allowing to use ESSCertIDv2 (defined in RFC 5035) together with presently used mandatory ESSCertID(SHA1) in timestamp causes a confusion.

For example at one important meeting, an expert from one EU country presented that he was incorrectly informed that the usage of ESSCertID or ESSCertIDv2 is useful only for solving of the hypothetical attack which is not possible in reality and mentioned that it was the opinion of IETF and ETSI experts.

According to such incorrect information from unknown UK IETF or ETSI expert, the one national decision of the usage of ESSCertID or ESSCertIDv2 presented ESSCertID or ESSCertIDv2 as not useful as mandatory to be included in Qualified Electronic Signatures or AdES based on Qualified Certificates. 

For that reason I would like to remind that at least two easy realizable attacks are possible:

Anybody can use any editor tools for substitution attack e.g. http://lipingshare.com/Asn1Editor/ which is really smart.

1. Attacker (timestamp or electronic document signer) asks two trusted CA for issuing of two certificates with the same key.

2. Attacker asks one CA for revocation of one certificate.

3. If ESSCertID or ESSCertIDv2 is not used, the attacker is able to substitute the signer certificate in timestamp (or signature).

4. The electronic signature is therefore not useable as trusted evidence in some actions.

1. Attacker (timestamp or electronic document signer) asks two trusted CA for issuing of two certificates with the same key but the second certificate is asked and issued after the expiration of the first certificate issued for the same key.

2. If ESSCertID or ESSCertIDv2 is not used, the attacker is able to substitute the signer certificate in timestamp (or signature).

3. The electronic signature is therefore not useable as trusted evidence in some actions.

If a certificate is used only as a carrier of public key and the certificate validity is not important, then also ESSCertID or ESSCertIDv2 is not important but in any other situation when the validity has a significant impact on some actions, ESSCertID or ESSCertIDv2 must be used. 

Another possibility for solving such attacks is to have mandatory rules for CA and registration authorities:

The CA must issue a certificate only for the key which was newly generated by CA or registration operators before the certificate creation. 

Regards, 

Peter Rybar

tel.: +421 2 6869 2163

mob.: +421 902 891 155

fax:  +421 2 6869 1701

e-mail: [email-masked]

e-mail: [email-masked]

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of Stefan Santesson
Sent: Tuesday, October 20, 2009 10:10 AM
To: [email-masked]; pkix
Subject: Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-update-07.txt

---

From: "Peter Rybar" <[email-masked]>
Date: Thu, 22 Oct 2009 12:15:35 +0200

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
	http://elpi2.szm.com/