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

From: "Pope, Nick" <[email-masked]>
Date: Tue, 29 Sep 2009 09:20:12 +0100

Stefan, Denis,

I would prefer the following, as 

a) I don't think bringing certificate policy helps clarify things here

b) The ESSCertV2 covers the collision threat.

   The introduction of ESSCertID addressed the theoretical threat that
   a relying party trusts a CA which might possibly malicious
   generate another TSA certificate.  The ESSCertIDV2 addressed the

   additional theoretical threat that hash of the other TSA
   certificate is identical to the hash of the original TSA 
   certificate.

   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.

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]] 
Sent: 29 September 2009 09:06
To: [email-masked]; pkix; Pope, Nick
Subject: Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-update-06.txt

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:

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 <mailto :[email-masked]>  

À  : i-d-announce <mailto :[email-masked]>  

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

  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
<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/ <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.

_____________________ next part  ______________________

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

  _____  

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

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 29 Sep 2009 11:28:06 +0200

I¹m sorry to say that I don¹t think we are doing progress.
Rather the text seems to be getting more and more confusing to an outside
reader.

I think the following would be much more helpful to a reader.

   ESSCertID provide means based on the SHA-1 hash algorithm for
   identifying the certificate used to verify the signature on a time
   stamp. The use of ESSCerIDv2 aims to enable implementers to comply
   with policies that require phasing out all uses of the SHA-1
   algorithm. Upgrading the hash function through ESSCertIDv2 address
   some theoretical scenarios involving a trusted malicious CA. Threats
   caused by a trusted malicious CA is however out of scope of this
   specification.

Alternatively this (more elaborate):

   ESSCertID provide means based on the SHA-1 hash algorithm for
   identifying the certificate used to verify the signature on a time
   stamp. The use of ESSCerIDv2 aims to enable implementers to comply
   with policies that require phasing out all uses of the SHA-1
   algorithm. Upgrading the hash function through ESSCertIDv2 address a
   theoretical scenario involving a trusted malicious CA issuing a false
   but trusted TSA certificate where the hash of the false certificate
   is identical to the hash of the original TSA certificate. Threats
   caused by a trusted malicious CA is however out of scope of this
   specification.

Note that the trusted malicious CA have another signing key (unless it has
compromised the good CA), thus will produce a totally different signature on
the false TSA certificate.
We are thus talking about a CA succeeding in creating a SHA-1 collision
despite a totally different signature value in the end of the certificate.
And all this effort just to convince me that the TSA certificate was issued
under the wrong policy.....

Seems like a really serious issue...

/Stefan

On 09-09-29 10:20 AM, "Pope, Nick" <[email-masked]> wrote:

> ftp://ftp.ietf.org/internet-drafts/
>

---

From: Thomas Pornin <[email-masked]>
Date: Tue, 29 Sep 2009 12:50:28 +0200

On Tue, Sep 29, 2009 at 11:28:06AM +0200, Stefan Santesson wrote:
> Note that the trusted malicious CA have another signing key (unless it
> has compromised the good CA), thus will produce a totally different
> signature on the false TSA certificate.

Not necessarily. The malicious CA may (depending on the scenario)
generate its key pair in order to match the signature value on its
target certificate. This can be done on an existing signature value
(regardless of the data and key used to generate that existing
signature) and is easy with DSA (and ECDSA); it is also possible with
RSA (although it tends to imply the use of a large public exponent,
which conforms to the PKCS#1 specification but will be rejected by many
implementations).

I am not sure about what power collisions on ESSCertID unlock, from the
attacker point of view, though. This is a tricky area.

Apart from the "phasing out of SHA-1", another good argument is "reduce
code footprint". Some embedded systems are very limited in code size and
wish to reduce the number of implemented functions, while still
producing standard-compliant objects. Algorithm agility enables usage of
a single hash function implementation throughout the whole code.

	--Thomas Pornin

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 29 Sep 2009 13:16:17 +0200

Thanks Thomas for that clarification.

I was in my example considering a CA that is in operation with an
established key.

You are absolutely right about this if the CA generates its key specifically
just for the purpose of forging this one TSA certificate.

However, it will also have to get this key trusted by the victim which is
the root of the problem. It is also yet another example why you are smoked
anyway if you choose to trust a bad guy as a trusted CA.

I agree with your observation but still think the text I proposed is OK.

/Stefan