Subject: Re: [pkix] WGLC draft-ietf-pkix-rfc3161-update-03.txt

From: "Pope, Nick" <[email-masked]>
Date: Thu, 17 Sep 2009 13:37:13 +0100

Yes - that's my feeling too.

I prefer Jean Marc text adding after "identified" "by the working group at
time of publication".

> -----Original Message-----
> From: Stefan Santesson [mailto:[email-masked]]
> Sent: 17 September 2009 13:27
> To: Pope, Nick; 'Peter Gutmann'
> Cc: 'pkix '; [email-masked] '; 'Peter Sylvester '
> Subject: Re: [pkix] WGLC draft-ietf-pkix-rfc3161-update-03.txt
> 
> Nick,
> 
> I had a long discussion with Julien (co author of the referenced document)
> and neither he could identify a realistic threat unless we introduce a
> trusted "bad" CA that can issue trusted certificates with malicious
> content
> (in line with Denis argument)
> 
> In our discussion however, conceded also that it is hard to prove that
> there
> will never be a threat, and that we should do the update of ESSCertIDv2.
> 
> /Stefan
> 
> 
> 
> On 09-09-17 2:05 PM, "Pope, Nick" <[email-masked]> wrote:
> 
> > Peter,
> >
> > This makes a judgement to say that there are definitely no risks and we
> are
> > only doing this because some (implied "stupid") government agencies
> consider
> > there is.
> >
> > Um... that will go down well.
> >
> > I would not agree that we could state categorically that this has no
> > purpose.  The paper presented at ACNS 2005:
> >  http://www.springerlink.com/content/y6ck2w9b857kew6c/
> > (unfortunately only the first page is available for free download)
> > has lead to suggestions that there is a need to protect the public key
> > certificate as cannot guarantee the public key given a private key.
> >
> > Nick
> >
> >
> >> -----Original Message-----
> >> From: Peter Gutmann [mailto:[email-masked]]
> >> Sent: 17 September 2009 11:11
> >> To: Stefan Santesson
> >> Cc: Pope, Nick; [email-masked] '; 'Peter Sylvester '; 'pkix ';
> >> [email-masked] '
> >> Subject: Re: [pkix] WGLC draft-ietf-pkix-rfc3161-update-03.txt
> >>
> >> Stefan Santesson <[email-masked]> writes:
> >>
> >>> I think one reason why some governments make requirements like this is
> >>> because documents like the one we just write is not clear on the
> reason
> >> why
> >>> we add such a feature.
> >>>
> >>> There is an increased risk that other governments or organizations
> >> otherwise
> >>> will read this new draft and believe that they have to use ESSCertIDv2
> >> with a
> >>> strong hash because it is required to mitigate known threats.
> >>
> >> I agree that this is a serious problem, users won't understand the
> feature
> >> but
> >> will mandate it just because it's in the spec.  So if it's really felt
> >> necessary to add it, why not just add some text that summarises the
> >> discussion
> >> on the list, something like "This facility serves no identifiable
> purpose
> >> but
> >> was added because some regulatory agencies may mandate it".  This
> should
> >> satisfy both camps, it points out that it doesn't address any
> identifiable
> >> threat or issue, but also defines the format for people who want to use
> it
> >> anyway.
> >>
> >> Peter.
> > Consider the environment before printing this mail.
> > "Thales e-Security Limited is incorporated in England and Wales with
> company
> > registration number 2518805. Its registered office is located at 2
> Dashwood
> > Lang Road, The Bourne Business Park, Addlestone, Nr. Weybridge, Surrey
> KT15
> > 2NX.
> > The information contained in this e-mail is confidential. It may also be
> > privileged. It is only intended for the stated addressee(s) and access
> to it
> > by any other person is unauthorised. If you are not an addressee or the
> > intended addressee, you must not disclose, copy, circulate or in any
> other
> > way use or rely on the information contained in this e-mail. Such
> > unauthorised use may be unlawful. If you have received this e-mail in
> error
> > please delete it (and all copies) from your system, please also inform
> us
> > immediately on +44 (0)1844 201800 or email postmaster@thales-
> esecurity.com.
> > Commercial matters detailed or referred to in this e-mail are subject to
> a
> > written contract signed for and on behalf of Thales e-Security Limited".
> > _______________________________________________
> > pkix mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/pkix

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 17 Sep 2009 15:11:24 +0200

I would propose the following text:

"At present, no specific security threat associated with the use of
ESSCerID has been identified unless the relying party trust a malicious CA
that succeeds in generating a false TSA certificate where the false and the
original TSA certificate have identical hash values. The introduction of
ESSCerIDv2 does not aim to avoid a specific security concern, but aims to
enable implementers to comply with policies that require phasing out all
uses of the SHA-1 algorithm."

/Stefan

---

From: "Andrea Caccia" <[email-masked]>
Date: Thu, 17 Sep 2009 15:16:28 +0200

Dear Nick,
firstly, as it is the first time I post a message to the list I'd like to
greet all PKIX subscribers and other ETSI/ESI participants.

I agree with your position, I'd like to add some thoughts on the discussion
to support it.

The substitution attack is in fact a possible threat in general, but in the
specific case of an RFC 3161 compliant Time Stamp Token it is very unlikely
to happen because:
- in the TST the TSA name is present, if I remember correctly, so the
substitution with a different certificate with a different name can be
detected. The hypothetically substituted certificate can only have some
difference in other attributes and extensions, but it's very difficult to me
to find a reasonable motivation for doing it, taking into account the huge
effort it require (if even feasible).
- even if SHA-1 is less strong than other hashing algorithms, in this
context it is far more difficult to find an useful collision to have two
different certificates having the same SHA-1 digest.

The reasons for this difficulty:
- the certificate is signed, so an attack requires I wave to add an
extension with an string of bytes I use to find the collision and then loop
on 1) set a value on this string, 2) sign the certificate, 3) calculate the
hash, 4) compare it with the value I want to obtain. This is far more time
consuming that simply calculating an hash and requires the CA private key:
so it is very unlikey this attack can benefit of any parallel computation.
In fact, if I can suppose the CA key can be distributed on thousands of
systems I think there are a lot of more interesting attacks that can be
performed and the only result is the need to revoke the CA certificate....

I am in favor to add ESSCertIDv2 for other reasons, it's not good in general
to force a specific algorithm to be used. 
As an example, if some domain standardize to a stronger hashing algorithm
like SHA-256 and phase out SHA-1 (we are going to proceed this way in Italy
for qualified signatures), having to implement a single algorithm on the
client can produce some savings (in complexity and testing reduction,
smaller executable size and so on).

Andrea

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Pope, Nick
Sent: Thursday, September 17, 2009 2:37 PM
To: 'Stefan Santesson'; Pope, Nick; 'Peter Gutmann'
Cc: 'pkix '; [email-masked] '; 'Peter Sylvester '
Subject: Re: [pkix] WGLC draft-ietf-pkix-rfc3161-update-03.txt

---

From: Peter Sylvester <[email-masked]>
Date: Thu, 17 Sep 2009 16:25:37 +0200

As far as I see, RFC 3161 does not require that
the esscertid be complete up a trust anchor,
i.e. it does not impose a path length maximum.

I can always just create a cross cert to the CA
that issued the TSA certificate.

Peter