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

From: "Pope, Nick" <[email-masked]>
Date: Fri, 25 Sep 2009 16:52:26 +0100

Denis,

I half agree with what you said.  The first part of the sentence relates to
ESSCertV2 but the second half relates use of weaker hashing algorithms where
this is more likely.

I fail to see how TSA Certificate Policies have anything to do with this.  I
read policies used in the old 2nd paragraph to relate to policies (e.g. as
government policy / corporate policy on algorithms) in general not
certificate policies.  So I do not think the second sentence in the first
paragraph is relevant.

I agree that these paragraphs do somewhat mix the risks relating to
certificate substitution and use of weaker algorithms increasing the chance
(although with still minimal risk) of a clash.

Nick

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Denis Pinkas
Sent: 25 September 2009 15:58
To: pkix
Subject: Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-update-06.txt

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

  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/

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> 

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 [email-masked].
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".

---

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

I would prefer at least some hint as to the threat as in generally
identifying the type of threat but for the sake of progress would accept to
compromise with Stefan's first choice.

Nick

> From: Dino Esposito [mailto:[email-masked]]
> Sent: 29 September 2009 12:10
> To: Pope, Nick
> Cc: 'Stefan Santesson'; [email-masked]; pkix
> I prefer the first option, so reduced
>  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.
> 
> If something is out of scope, why should you address it?
> In fact, the reason to upgrade the RFC is just to enable people to
> comply with some external policies, where the threat are supposed to be
> dealt
> 
> Dino Esposito
> 
> Pope, Nick wrote:
> >
> > Stefan,
> >
> >
> >
> > I prefer the alternative as this makes it clearer to me what is the
> > threat.
> >
> >
> >
> > Nick
> >
> >
> >
> > *From:* Stefan Santesson [mailto:[email-masked]]
> > *Sent:* 29 September 2009 10:28
> > *To:* Pope, Nick; [email-masked]; pkix
> > *Subject:* Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-update-06.txt
> >
> >
> >
> > 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:
> >
> > 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.
> >
> >
> >    generate another TSA certificate.  The ESSCertIDV2 addressed the
> >    additional theoretical threat that hash of the other TSA
> >    certificate.
> > *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,
> >
> > The threat already existed with ESSCertID which means that the
> > sentence is incorrect.
> >
> > I propose the following:
> >
> > *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 :
> > _*
> > [email-masked] <mailto: [email-masked]>
> > ------------------------------------------------------------------------
> >
> >
> > [email-masked]
> > ------------------------------------------------------------------------
> >
> > [email-masked]
> > *_/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 [email-masked]. 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"./*
> >
> > ------------------------------------------------------------------------
> >
> > [email-masked]

---

From: "Pope, Nick" <[email-masked]>
Date: Tue, 29 Sep 2009 16:47:14 +0100

Denis,

I think the point is that this Security Consideration is not the place to go
into the detailed analysis of the threats around malicious CAs.

Perhaps a statement to this effect that "This section does not go into a
detailed analysis of the threats relating to malicious CAs." could  be used
instead.

Nick

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: 29 September 2009 16:42
To: pkix
Subject: Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-update-06.txt

Stefan,

You said:

" I have no problem with the disposition change. The problem is that .."

If you have really no problem, that let us pick my proposed wording.

However, it seems that you do have a problem, so if it is really the case 
please do not write "I have no problem with the disposition change".

Nothing is out of scope in a security considerations section. In particular,

a trusted malicious CA is within the scope. The CA is trusted because it
belongs 
to a trusted certification path, but happens to maliciously issue a TSA
certificate.

In such a case, the original certificate can be replaced in a log file
without anybody noticing it.

So I can't agree to have the following sentence:

"Threats caused by a trusted malicious CA is however out of scope of this
specification".

Denis

[email-masked] wrote: -----

To: Dino Esposito <[email-masked]>, "Pope, Nick"
<[email-masked]>
From: Stefan Santesson <[email-masked]>
Sent by: [email-masked]
Date: 09/29/2009 02:39PM
cc: pkix <[email-masked]>, [email-masked]
Subject: Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-update-06.txt

Dino,

I agree to a certain point, but it is actually relevant in a security
considerations section to mention that a threat is out of scope.

I would also prefer the first option, but could live with both.

/Stefan

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

---

From: [email-masked]
Date: Tue, 29 Sep 2009 18:18:36 +0200

Nick,

I see two ways to solve and close this issue.

Solution A.

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

Solution B.

"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. This section
does not go into a detailed analysis of the threats relating to trusted malicious CAs".

I can live with any of them.

Denis

[email-masked] wrote: -----

To: "[email-masked]'" <[email-masked]>, pkix <[email-masked]>
From: "Pope, Nick" <[email-masked]>
Sent by: [email-masked]
Date: 09/29/2009 05:47PM
Subject: Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-update-06.txt

Denis,

I think the point is that this SecurityConsideration is not the place to go into the detailed analysis of the threatsaround malicious CAs.

Perhaps a statement to this effect that "Thissection does not go into a detailed analysis of the threats relating tomalicious CAs." could  be used instead.

Nick

-----Original Message-----
From: [email-masked][mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 29 September 2009 16:42
To: pkix
Subject: Re: [pkix] I-DAction:draft-ietf-pkix-rfc3161-update-06.txt

Stefan,

You said:

" I have no problem with the dispositionchange. The problem is that .."

If you have really no problem, that let us pick myproposed wording.

However, it seems that you do have a problem, so if it isreally the case
please do not write "I have no problem with the disposition change".

Nothing is out of scope in a security considerationssection. In particular,
a trusted malicious CA is within the scope. The CA is trusted because itbelongs
to a trusted certification path, but happens to maliciously issue a TSAcertificate.

In such a case, the original certificate can bereplaced in a log file without anybody noticing it.

"Threats caused by a trusted malicious CA ishowever out of scope of this specification".

Denis

[email-masked]: -----

To: Dino Esposito <[email-masked]>,"Pope, Nick" <[email-masked]>

Dino,

/Stefan

On 09-09-29 1:10 PM, "Dino Esposito"<[email-masked]> wrote:

>> On 09-09-29 10:20 AM, "Pope, Nick"<[email-masked]> wrote:
>>
>> Stefan, Denis,
>>
>> On 09-09-25 4:57 PM, "Denis Pinkas"<[email-masked]> wrote:
>> Stefan and Nick,
>>
>> */"Thales e-Security Limited is incorporated in England and Waleswith

"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 [email-masked]. 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 [email-masked]://www.ietf.org/mailman/listinfo/pkix