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

"Peter Rybar" <rybar@nbusr.sk> Thu, 22 October 2009 10:15 UTC

Return-Path: <rybar@nbusr.sk>
X-Original-To: smime@core3.amsl.com
Delivered-To: smime@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3A293A68C5; Thu, 22 Oct 2009 03:15:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.629
X-Spam-Level: *
X-Spam-Status: No, score=1.629 tagged_above=-999 required=5 tests=[AWL=-0.277, BAYES_50=0.001, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tPqYnh9UIgNd; Thu, 22 Oct 2009 03:15:03 -0700 (PDT)
Received: from mail.nbusr.sk (mail.nbusr.sk [84.245.65.227]) by core3.amsl.com (Postfix) with ESMTP id 5FC5B3A67A1; Thu, 22 Oct 2009 03:15:01 -0700 (PDT)
From: Peter Rybar <rybar@nbusr.sk>
To: pkix@ietf.org
Date: Thu, 22 Oct 2009 12:15:35 +0200
Message-ID: <200910221015.n9MAF1D0025323@mail.nbusr.sk>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
Thread-Index: AcpRXKfyyU3/hl/9dkWptEJRifJH1QAvtWXgAAy7+AwALCJMYA==
In-Reply-To: <C704D27D.5733%stefan@aaa-sec.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512
X-NAI-Spam-Score: 0
X-NAI-Spam-Report: 1 Rules triggered * 0 -- RV3387 -- BODY: Version number
Cc: peterryb@gmail.com, ESI@list.etsi.org, smime@ietf.org
Subject: Re: [smime] [pkix] I-D Action:draft-ietf-pkix-rfc3161-update-07.txt
X-BeenThere: smime@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SMIME Working Group <smime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/smime>, <mailto:smime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/smime>
List-Post: <mailto:smime@ietf.org>
List-Help: <mailto:smime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/smime>, <mailto:smime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Oct 2009 10:15:03 -0000

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.rybar@nbusr.sk 
	e-mail: peterryb@gmail.com
	http://elpi2.szm.com/