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

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

Stephan

Fine with general direction.  Just suggest reword as the "unless" implies
that this is a real threat, whereas I think you are implying the risk of
this threat is not commonly considered to be significant.

"The introduction of ESSCertIDv2 is aimed at addressing the theoretically
possible threat that the relying party trusts a malicious CA that succeeds
in generating a false TSA certificate where the false and the original TSA
certificate have identical SHA-1 hash values.  This is not considered to be
a significant security risk for known use cases, but the use of ESSCerIDv2
aims to enable implementers to comply with policies that require phasing out
all uses of the SHA-1 algorithm."

Stefan - Could you also clarify what the whole "Security considerations"
section will now look like.  I am not sure how much this update replaces.

Nick

> -----Original Message-----
> From: Stefan Santesson [mailto:[email-masked]]
> Sent: 17 September 2009 14:11
> To: Pope, Nick; 'Peter Gutmann'
> Cc: 'pkix '; [email-masked] '; 'Peter Sylvester '
> Subject: Re: [pkix] WGLC draft-ietf-pkix-rfc3161-update-03.txt
> 
> 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
> 
> On 09-09-17 2:37 PM, "Pope, Nick" <[email-masked]> wrote:
> 
> > 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
> >
> > _______________________________________________
> > pkix mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/pkix

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 17 Sep 2009 18:43:51 +0200

/Nick,

Almost there

I'm just not comfortable with the beginning:

"The introduction of ESSCertIDv2 is aimed at addressing the theoretically
possible threat that the relying party trusts a malicious CA"

Because that is not the reason for doing this, the reason for doing this is
stated in the end: 

"the use of ESSCerIDv2 aims to enable implementers to comply with policies
that require phasing out all uses of the SHA-1 algorithm."

So a final attempt, showing whole security considerations section:

3  Security Considerations

   This draft incorporates the security considerations of RFC 5035
   [ESSV2] with further explanations in this section.

   The introduction of ESSCertIDv2 addresses a theoretical threat if the
   relying party trusts a malicious CA that succeeds in generating a
   false TSA certificate where the hash of the false TSA certificate is
   identical to the hash of the original TSA certificate.

   This is not considered to be a significant security risk for known
   use cases, but the use of ESSCerIDv2 aims to enable implementers to
   comply with policies that require phasing out all uses of the SHA-1
   algorithm.

/Stefan