Subject: [pkix] I-D Action:draft-ietf-pkix-rfc3161-update-06.txt

From: [email-masked]
Date: Sat, 19 Sep 2009 01:45:01 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title           : ESSCertIDv2 update for RFC 3161
	Author(s)       : S. Santesson, N. Pope
	Filename        : draft-ietf-pkix-rfc3161-update-06.txt
	Pages           : 8
	Date            : 2009-09-19

This document updates RFC 3161 [RFC3161]. It allows the use of
ESSCertIDv2 defined in RFC 5035 [ESSV2] to specify the hash of a
signer certificate when the hash is calculated with a function other
than SHA-1 [SHA1].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc3161-update-06.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Denis Pinkas"<[email-masked]>
Date: Fri, 25 Sep 2009 16:57:39 +0200

Stefan and Nick,

I have problems with the second and third paragraphs from section 6.

The text starts with :

   The introduction of ESSCertIDv2 addresses the theoretical threat ..

The threat already existed with ESSCertID which means that the sentence is incorrect.

I propose the following:

   The introduction of ESSCertID addressed the theoretical threat that
   a relying party trusts a CA which might possibly malicious
   generate another TSA certificate where the hash of the other TSA
   certificate is identical to the hash of the original TSA 
   certificate.  Since the TSA certificate indicates the 
   Certification Policy under which the TSA key pair has been
   handled, it is important that the TSA can reliably indicate under 
   which Certification Policy the certificate has been obtained.

   The use of ESSCerIDv2 aims to enable implementers to comply with 
   policies that require phasing out all uses of the SHA-1 algorithm.
   In case SHA-1 might in the future exhibit hash collisions, the 
   introduction of ESSCertIDv2 allows the use of stronger hash 
   functions making the generation of such other certificates close 
   to impossible.

Denis

---------- 
De : pkix-bounces 
À : i-d-announce 
Date : 2009-09-19, 10:45:01
Sujet : [pkix] I-D Action:draft-ietf-pkix-rfc3161-update-06.txt

Pièce(s) Jointe(s) au message original :
  (1). draft-ietf-pkix-rfc3161-update-06.txt

_____________________ next part ______________________

_______________________________________________
pkix mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pkix

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 29 Sep 2009 10:05:42 +0200

Denis,

I have no problem with the disposition change.

The problem is that you insist on painting this in words making it look like
as a serious security issue.
The rest of us seems to agree that it isn¹t a realistic threat.

To me, the picture you paint sounds very much like reinforcing the door of a
vault that has lost it¹s roof.
It does help if the thief tries to enter through the door, but does not
prevent anyone from climbing over the wall.

Likewise, for the unlikely event that you will trust a malicious CA,
ESSCertIDv2 will probably not save you either.
That CA can simply fool you in so many other ways where ESSCertIDv2 will not
help.

I think we have to choices. Either we define trusted but malicious CA as a
threat that is either:

1) in scope; or
2) out of scope,

of threats that need to be addressed.

If the trusted malicious CA is in scope, then we need to address all things
that a trusted malicious CA can do and come up with recommendations for each
one.
If the trusted malicious CA is out of scope, then we should say so and not
pretend that we fixed the bad CA scenario by mending one of the holes in the
broken barrel.

I hope we can all agree that it would be infeasible to define the trusted
malicious CA scenario as an ³in scope² threat.

/Stefan

On 09-09-25 4:57 PM, "Denis Pinkas" <[email-masked]> wrote:

>    The introduction of ESSCertIDv2 addresses the theoretical threat .
> 
>> De  : pkix-bounces <mailto :[email-masked]>
>>  
>> À  : i-d-announce <mailto :[email-masked]>
>>  
>> [email-masked] <mailto: [email-masked]>