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

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

After almost 10 years debate on this issue in ETSI I am not sure that there
is an easy answer.  Like you I have not yet heard a description of a
practical use case where this is a risk, but it is difficult to prove that
isn't one.  The idea of being able to substitute certificates raises
instinctive concerns in some people.  This is more the subject of a paper by
itself than something that can fit in a few lines.

Nick

> -----Original Message-----
> From: Stefan Santesson [mailto:[email-masked]]
> Sent: 17 September 2009 10:50
> To: Pope, Nick; [email-masked] '; 'Peter Sylvester '
> Cc: 'pkix '; [email-masked] '
> Subject: Re: [pkix] WGLC draft-ietf-pkix-rfc3161-update-03.txt
> 
> Nick,
> 
> 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.
> 
> If it proves to be too controversial to say that this change is not
> motivated by reasons of security, then I will not fight it to the bitter
> end, but I think we make a disservice to the community by not saying so.
> 
> /Stefan
> 
> 
> On 09-09-17 11:26 AM, "Pope, Nick" <[email-masked]> wrote:
> 
> > Stefan, Peter,
> >
> > I agree that it is very difficult to identify a threat scenario where a
> > "Trusted" CA would want to provide a certificate which the false name
> > against a TSA's name.
> >
> > However, the point of the change because the slight doubt of whether
> > certificate substitution is a problem has made some EU governments
> madate
> > its presence, and also they have a rule regarding phasing out SHA-1.
> >
> > Making valued statement as to the reason only opens up the debate.
> >
> > Given that there is agreement to make the change is there a need to do
> more
> > than reference the RFC 5035 security considerations.
> >
> > Nick
> >
> >
> >
> >
> > -----Original Message-----
> > From: [email-masked]
> > To: Peter Sylvester
> > Cc: pkix; [email-masked]
> > Sent: 16/09/2009 23:25
> > Subject: Re: [pkix] WGLC draft-ietf-pkix-rfc3161-update-03.txt
> >
> > Peter,
> >
> > I'm asking myself the same question.
> > Nobody so far has provided me with a plausible attack scenario, and I
> > have
> > hade quite a few discussions with smart people on this subject.
> >
> > The only ones I have seen involves a bad CA, but trusting a bad CA can't
> > be
> > fixed by a strong hash in ESSCertIDv2 anyway. At most it may limit the
> > attack surface slightly.
> >
> > /Stefan
> >
> >
> > On 09-09-17 12:10 AM, "Peter Sylvester" <[email-masked]>
> > wrote:
> >
> >> Hello,
> >>
> >> What is the security threat here?
> >>
> >> A TSA has a public key and id and a certificate from on named CA.
> >> In each time stamp, it indicates it id and the id of the CA, and
> >> the hash of a cert.
> >>
> >> With some probability another trustworthy CA has the same NAME
> >> and may be able to create another certificate with the same esscertid,
> >> assuming that you get to this situation:
> >>
> >> This certificate would be substituted to the original one in order
> >> to do what?
> >>
> >> - To have a relying party refuse a time stamp or accept it?
> >> - what use case of a timestamp could be a problem?
> >>
> >> regards
> >> Peter
> >>
> >>
> >
> >
> > _______________________________________________
> > pkix mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/pkix
> > 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