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

From: "Pope, Nick" <[email-masked]>
Date: Thu, 1 Oct 2009 13:00:43 +0100

Stefan,

Should have looked more closely at the English before saying yes.

   ESSCertID provides a 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 addresses 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. However,
   trusting a malicious CA to issue TSA certificates enables a wide
   range of other threats that are not mitigated by ESSCertIDv2. Threats
   in general, caused by a trusted malicious CA, are therefore out of
   scope of this specification.

See highlighted text.

Nick

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]] 
Sent: 01 October 2009 12:47
To: Pope, Nick
Subject: Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-update-06.txt

OK,

I have updated and submitted a new draft.
http://www.ietf.org/id/draft-ietf-pkix-rfc3161-update-07.txt
<http://www.ietf.org/id/draft-ietf-pkix-rfc3161-update-07.txt> 

Hopefully this resolves the issue:

/Stefan

On 09-10-01 1:34 PM, "Pope, Nick" <[email-masked]> wrote:

Fine by me
 
Nick

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: 01 October 2009 12:30
To: Pope, Nick; [email-masked]'
Cc: pkix
Subject: Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-update-06.txt

I had a conversation with Pasi (Security AD). His reflection was:

"The security considerations text should help implementors and deployers in
deciding whether to stick with ESSCertID or move to ESSCertIDv2 when
implementing/deploying TSP. Personally, I think "some theoretical scenarios
involving a trusted malicious CA" is a bit vague -- perhaps a slightly more
understandable description is needed (but probably couple of sentences would
be enough -- a very long and detailed analysis probably wouldn't be that
helpful to the readers either). "

Following Pasi's recommendation I would suggest the following modification
of my original proposal:

   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. However,
   trusting a malicious CA to issue TSA certificates enables a wide
   range of other threats that are not mitigated by ESSCertIDv2. Threats
   in general, caused by a trusted malicious CA, are therefore out of
   scope of this specification.

Hopefully this gives everyone what they need. 

/Stefan

On 09-10-01 11:45 AM, "Pope, Nick" <[email-masked]> wrote:
Stefan,
 
OK - I was not aware of the practice of scoping threats separate from
scoping the RFC.  Clearly, MECHANISMS addressing the threat of malicious CA
are outside the scope of this RFC (they are more to do with CA trust
management).
 
Do you want to propose the text for security considerations.   May I suggest
this includes text the lines
 "Mechanisms addressing the threat of malicious CAs and ensuring CAs are
trustworthy are outside the scope of this RFC."
 
Nick

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

Nick,

BCP 72 specifies guidelines for writing security considerations sections.

It states:

Authors MUST describe

      1.   which attacks are out of scope (and why!)
      2.   which attacks are in-scope
      2.1  and the protocol is susceptible to
      2.2  and the protocol protects against

The PKI trust model, on which we base time stamping, assumes that we are
able to determine which authorities we trust and that the data they provide
in the form of certificates are trustworthy.
As such, it is generally out of scope for a PKI based protocol to actively
defend against a trusted malicious CA. 
If you as relaying party have a problem in this area, you ought to fix how
you trust Cas, rather than trying to build protocols that is secure despite
trust in malicious CAs.

The reason is simply because the battle is lost anyway. If you trust me as
CA, and I'm a bad guy, I can screw you over in so many ways that you can't
ever fix through protocol design.

If we are to follow BCP 72, we need to consider threats related to
ESSCertIDv2. The only one we know of is one involving a trusted malicious
CA.
Further following BCP 72 we need to decide whether the threat of a trusted
malicious CA is in scope, or out of scope.

Until we do that, and express it in writing, we are in a dead-lock position
and can't proceed with this draft.

Agreeing on a fuzzy writing that gets the document stalled in IESG is not a
responsible path IMO. Thus I prefer a straw-poll.

/Stefan

On 09-09-29 7:18 PM, "Pope, Nick" <[email-masked]> wrote:
Stefan,
 
I don't understand the use of scope in "security considerations."  The scope
of the RFC is ESSCert2.  The discussion of security threats looks at the
wider security environment. How can one say certain threats relating to
ESSCertv2 are out of scope? It is reasonable that the security
considerations does not turn into a detailed analysis.
 
I do think we are so close on this area.  Given other areas of fuzziness in
RFCs I can't see oneone getting uptight about scope relating to the security
considerations.
 
Nick

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

Unfortunately I don't think any of them will get past the IESG review.
The obvious discuss will be "What are the threats, and are they in scope?"

/Stefan

On 09-09-29 6:24 PM, "Pope, Nick" <[email-masked]> wrote:
Either is OK for me too.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: 29 September 2009 17:19
To: Pope, Nick
Cc: [email-masked] <[email-masked]> <[email-masked]>
<[email-masked]> '; pkix
Subject: Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-update-06.txt

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]> <[email-masked]>
' <[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:pkix-bounces
<[email-masked]%5bmailto:pkix-bounces>
<[email-masked]%5bmailto:pkix-bounces>
<[email-masked]%5bmailto:pkix-bounces> @ietf.org] 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.

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

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

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

> Nick
> 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
>> 
>> 
>> 
>> -----Original Message-----
>> *From:* Stefan Santesson [mailto:[email-masked]
<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.
>> 
>> 
>> 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]
<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>
<mailto:[email-masked] <mailto:[email-masked]> > 
>> 
>> 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> 
>> 
>>------------------------------------------------------------------------
>> 
>> _______________________________________________
>> pkix mailing list
>> [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 Waleswith>
>> 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 list
>> [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> 

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

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: Stefan Santesson <[email-masked]>
Date: Fri, 02 Oct 2009 09:08:35 +0200

Thanks,

I received them now.
There are just cosmetic changes but the text for next version will be:

   ESSCertID provides a means based on the SHA-1 hash algorithm for
   identifying the certificate used to verify the signature on a time
   stamp. The use of ESSCertIDv2 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 addresses
   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.
   However, trusting a malicious CA to issue TSA certificates enables a
   wide range of other threats that are not mitigated by ESSCertIDv2.
   Threats in general, caused by a trusted malicious CA, are therefore
   out of scope of this specification.

/Stefan

On 09-10-01 2:00 PM, "Pope, Nick" <[email-masked]> wrote:

> Following Pasi's recommendation I would suggest the following modification of
> my original proposal:
> 
> 
> OK - I was not aware of the practice of scoping threats separate from scoping
> the RFC.  Clearly, MECHANISMS addressing the threat of malicious CA are
> outside the scope of this RFC (they are more to do with CA trust management).
>  
> The PKI trust model, on which we base time stamping, assumes that we are able
> to determine which authorities we trust and that the data they provide in the
> form of certificates are trustworthy.
> If you as relaying party have a problem in this area, you ought to fix how you
> trust Cas, rather than trying to build protocols that is secure despite trust
> in malicious CAs.
> 
> The reason is simply because the battle is lost anyway. If you trust me as CA,
> and I'm a bad guy, I can screw you over in so many ways that you can't ever
> fix through protocol design.
> 
> ESSCertIDv2. The only one we know of is one involving a trusted malicious CA.
> of the RFC is ESSCert2.  The discussion of security threats looks at the wider
> security environment. How can one say certain threats relating to ESSCertv2
> are out of scope? It is reasonable that the security considerations does not
> turn into a detailed analysis.
>  
> <[email-masked]>  <[email-masked]> '
> Cc: pkix
> From: [email-masked] [mailto:[email-masked]]
> <[email-masked]> <[email-masked]> '; pkix
> <[email-masked]> ' <[email-masked]> " <[email-masked]>,
> pkix <[email-masked]>
> In such a case, the original certificate can bereplaced in a log file without
> anybody noticing it.
> 
> 
> 
>>> >> *From:* Stefan Santesson [mailto:[email-masked]]
>>> >> *From:* Stefan Santesson [mailto:[email-masked]]
>>> <mailto:[email-masked]>
>>> >> 
>>> >> ftp://ftp.ietf.org/internet-drafts/
>>> >> 
> 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".
> 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".
> 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".
> 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".
> 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: "Denis Pinkas"<[email-masked]>
Date: Mon, 5 Oct 2009 12:05:13 +0200

Stefan and Nick,

Thanks to your efforts for tryinvgto solve the issue but the new proposed text is still incorrect.

It states: " Upgrading the hash function through ESSCertIDv2 addressess a theoretical scenario 
   involving a trusted malicious CA issuing ...

This theoretical scenario was already valid for ESSCertID, and thus ESSCertIDv2 is not addressing a new threat.

I made a detailed analysis of the threat and this leads me to propose the following text:

   This draft incorporates the security considerations of RFC 5035
   [ESSV2] with further explanations in this section.
 
   The certificates field from the SignedData structure that may 
   contain the TSA certificate is optional. Since this information is 
   unsigned, it may be easily substituted.
 
   The tsa field from TSTInfo is optional.  When this field is 
   not present, the only way to know which CA has been recognized by the 
   TSA as the issuing CA, is to use the certificate pointed by 
   ESSCertID or ESSCertIDv2.
 
   The issuerSerial field from ESSCertID or from ESSCertIDv2 is 
   optional.
 
   When none of these two optional fields is present, the only way to 
   point to the correct certificate is to use the hash of the TSA 
   certificate, as indicated in ESSCertID or in ESSCertIDv2.
 
   Should the hash function used to compute that hash value not be 
   resistant to collisions, then it would be possible to substitute 
   to the original TSA certificate by another one from any other CA.  
   This substitution may only occur if a trusted CA acts maliciously 
   and generates a TSA certificate that would have the same hash value.
 
   When the tsa field from TSTInfo is present and /or when the 
   issuerSerial field from ESSCertID or from ESSCertIDv2 is present, 
   such an attack can only be done by a trusted CA that bears the same 
   DN, as indicated in the tsa field from TSTInfo or /and the 
   issuerSerial field from ESSCertID or ESSCertIDv2.

Denis
----- Message reçu ----- 
De : pkix-bounces 
À : 'Stefan Santesson' 
Date : 2009-10-01, 14:00:43
Sujet : Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-update-06.txt

Stefan,

See highlighted text.

Nick

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]] 
Sent: 01 October 2009 12:47
To: Pope, Nick
Subject: Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-update-06.txt

OK,

/Stefan

Nick

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]] 
Sent: 01 October 2009 12:30
To: Pope, Nick; [email-masked]'
Cc: pkix
Subject: Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-update-06.txt

"The security considerations text should help implementors and deployers in deciding whether to stick with ESSCertID or move to ESSCertIDv2 when implementing/deploying TSP. Personally, I think "some theoretical scenarios involving a trusted malicious CA" is a bit vague -- perhaps a slightly more understandable description is needed (but probably couple of sentences would be enough -- a very long and detailed analysis probably wouldn't be that helpful to the readers either). "

Following Pasi's recommendation I would suggest the following modification of my original proposal:

/Stefan

OK - I was not aware of the practice of scoping threats separate from scoping the RFC.  Clearly, MECHANISMS addressing the threat of malicious CA are outside the scope of this RFC (they are more to do with CA trust management).
 
Do you want to propose the text for security considerations.   May I suggest this includes text the lines
 "Mechanisms addressing the threat of malicious CAs and ensuring CAs are trustworthy are outside the scope of this RFC."
 
Nick

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

Nick,

It states:

Authors MUST describe

The PKI trust model, on which we base time stamping, assumes that we are able to determine which authorities we trust and that the data they provide in the form of certificates are trustworthy.
As such, it is generally out of scope for a PKI based protocol to actively defend against a trusted malicious CA. 
If you as relaying party have a problem in this area, you ought to fix how you trust Cas, rather than trying to build protocols that is secure despite trust in malicious CAs.

The reason is simply because the battle is lost anyway. If you trust me as CA, and I'm a bad guy, I can screw you over in so many ways that you can't ever fix through protocol design.

If we are to follow BCP 72, we need to consider threats related to ESSCertIDv2. The only one we know of is one involving a trusted malicious CA.
Further following BCP 72 we need to decide whether the threat of a trusted malicious CA is in scope, or out of scope.

Until we do that, and express it in writing, we are in a dead-lock position and can't proceed with this draft.

Agreeing on a fuzzy writing that gets the document stalled in IESG is not a responsible path IMO. Thus I prefer a straw-poll.

/Stefan

I don't understand the use of scope in "security considerations."  The scope of the RFC is ESSCert2.  The discussion of security threats looks at the wider security environment. How can one say certain threats relating to ESSCertv2 are out of scope? It is reasonable that the security considerations does not turn into a detailed analysis.
 
I do think we are so close on this area.  Given other areas of fuzziness in RFCs I can't see oneone getting uptight about scope relating to the security considerations.
 
Nick

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

/Stefan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 29 September 2009 17:19
To: Pope, Nick
Cc: [email-masked] <[email-masked]> <[email-masked]> <[email-masked]> '; pkix
Subject: Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-update-06.txt

Nick,

Solution A.

Solution B.

does not go into a detailed analysis of the threats relating to trusted malicious CAs".

Denis

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

To: "[email-masked] <[email-masked]> <[email-masked]> ' <[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:pkix-bounces <[email-masked]%5bmailto:pkix-bounces> <[email-masked]%5bmailto:pkix-bounces> <[email-masked]%5bmailto:pkix-bounces> @ietf.org] 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:

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:

>> http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc3161-update-06.txt <mailto:[email-masked]> 
>> 

"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 <[email-masked]:/www.ietf.org/mailman/listinfo/pkix> <[email-masked]:/www.ietf.org/mailman/listinfo/pkix> <[email-masked]:/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". 
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". 
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: Peter Sylvester <[email-masked]>
Date: Mon, 05 Oct 2009 19:14:07 +0200

Hi Denis

Denis wrote
>    ESSCertID or ESSCertIDv2.
I  am not sure whether I can parse this correctly.
The tsa field says something about the subject of a cert, not about the CA?
So present or not that doesn't change anything about the CA?

regards

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 06 Oct 2009 00:04:54 +0200

Denis,

>    involving a trusted malicious CA issuing ...

No, this statement is correct.

ESSCertID was introduced as a mechanism to bind the signer certificate to
the signature, but it was not designed to protect against replacement of
certificates with colliding hashes.
This is however exactly the motivation for hash algorithm agility introduced
by ESSCertIDv2

I can¹t accept your text of the following main reasons:

1. It introduce requirement text that either is a copy of something that
should be placed in the main document or should not be there at all.
2. It does not inform the reader that the threat of trusted malicious CAs in
general is out of scope.
3. It introduces text that is likely to confuse a reader rather than
bringing clarity (As Peter pointed out).

As such I prefer the original text.

/Stefan

---

From: "Denis Pinkas"<[email-masked]>
Date: Wed, 7 Oct 2009 10:33:21 +0200

Peter,

Extract from RFC 3161:

   The purpose of the tsa field is to give a hint in identifying the
   name of the TSA.  If present, it MUST correspond to one of the
   subject names included in the certificate that is to be used to
   verify the token.  However, the actual identification of the entity
   that signed the response will always occur through the use of the
   certificate identifier (ESSCertID Attribute) inside a
   SigningCertificate attribute which is part of the signerInfo (See
   Section 5 of [ESS]).

Denis

----- Message reçu ----- 
De : Peter Sylvester 
À : denis.pinkas 
Date : 2009-10-05, 19:14:07
Sujet : Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-update-07.txt

Hi Denis

Denis wrote

regards

---

From: "Denis Pinkas"<[email-masked]>
Date: Wed, 7 Oct 2009 10:33:51 +0200

Stefan,

I disagree with your statement:

"ESSCertID was introduced as a mechanism to bind the signer certificate to the signature, 
but it was not designed to protect against replacement of certificates with colliding hashes".

ESSCertID was introduced as a mechanism to bind the signer certificate to the signature, 
and was designed to protect against replacement of certificates with colliding hashes.

ESSCertIDv2 addresses exactly the same threats as ESSCertID but allows to use hash functions different from SHA-1.
Originally, if we were not concerned with colliding hashes, we would have chosen to use CRC 16 or CRC 32, but we didn't.

Denis

----- Message reçu ----- 
De : Stefan Santesson 
À : denis.pinkas,pkix 
Date : 2009-10-06, 00:04:54
Sujet : Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-update-07.txt

Denis,

 

ESSCertID was introduced as a mechanism to bind the signer certificate to the signature, but it was not designed to protect against replacement of certificates with colliding hashes.
This is however exactly the motivation for hash algorithm agility introduced by ESSCertIDv2

I can’t accept your text of the following main reasons:

It introduce requirement text that either is a copy of something that should be placed in the main document or should not be there at all. 
It does not inform the reader that the threat of trusted malicious CAs in general is out of scope. 
It introduces text that is likely to confuse a reader rather than bringing clarity (As Peter pointed out).

/Stefan

---

From: Peter Sylvester <[email-masked]>
Date: Wed, 07 Oct 2009 22:29:21 +0200

Denis Pinkas wrote:
> ESSCertIDv2 addresses exactly the same threats as ESSCertID but allows 
> to use hash functions different from SHA-1.
> Originally, if we were not concerned with colliding hashes, we would 
> have chosen to use CRC 16 or CRC 32, but we didn't.
>  
> Denis
>  
Denis and Stefan,

the three of us are non native English schpeeking.  I think both
of you are right (or wrong).

Using a strong hash function makes collision unlikely (Denis)
but in case of a collision (which is supposed to be unlikely)
there is no additional feature/design (Stefan).

---

From: Peter Sylvester <[email-masked]>
Date: Wed, 07 Oct 2009 22:52:37 +0200

>    SigningCertificate attribute which is part of the signerInfo (See
Hi,

The "identification" refered to in this text is the one of the TSA, not 
the CA.
There is nothing in the RFC that requires identifying the CA, the fact 
that an
identified certificate has an issuer does not mean that the purpose was
to identify the CA. Note also that issuer/serial in esscertid is still 
optional
in the esscertid.

3161 does not make issuer/serial mandatoty, neither it requires to have
a complete chain to some trust anchor.

I was referring to your text below which seems unclear, what has the 
'tsa' field
to do with 'identifying the ca'? If you want to talk about 'identifying 
the tsa',
yes, the TSA field is optional. As soon as you set the field, what is the
delta brought by ESScertid(v2)?

There is no text anywhere that requires that you have to know which CA
has signed a TSA certificate or a tsa telling this in order to have a
'secure' time stamp.

I am producing thousands of timestamps per month,
nobody has ever cared about the CA name in the TSA certificate.

Peter
>  
>
>     ----- Message reçu -----
>     *De :* Peter Sylvester <mailto%20:[email-masked]>
>     *À :* denis.pinkas <mailto%20:[email-masked]>
>     *Date :* 2009-10-05, 19:14:07
>     *Sujet :* Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-update-07.txt
>
>     Hi Denis
>
>     Denis wrote
>     >
>     >
>     >

---

From: "Denis Pinkas"<[email-masked]>
Date: Thu, 8 Oct 2009 12:30:47 +0200

Peter,

You are right, the proposed text was incorrect. See a corrected text below.

You asked the question:
"As soon as you set the the TSA field, what is the delta brought by ESScertid(v2)?"
As you noticed, the benefits are identical for ESSCertId and ESSCertIdv2.
When the TSA field is set, a malicious trusted CA can only generate a TSA certificate that bears that TSA name, 
otherwise it could generate a certificate with any TSA name (if it can succeed to make a hash collision, of course). 
Then you said:

"There is no text anywhere that requires that you have to know which CA
has signed a TSA certificate or a tsa telling this in order to have a 
'secure' time stamp.

I am producing thousands of timestamps per month, 
nobody has ever cared about the CA name in the TSA certificate".

Relying Parties need to verifying the digital signature from the TST. They need to know which is the issuing CA 
to make sure that it is in a trusted certification tree. They also care to know under which Certificate Policy (CP) 
the TSA certificate has been issued. Hence, they care about the right TSA certificate to be used. 

Hereafter is a corrected text:

 
   The tsa field from TSTInfo is optional.  When this field is 
   not present, the only way to know which TSA has issued the TST 
   is to use the certificate pointed by ESSCertID or ESSCertIDv2.

   When none of these two optional fields is present, the only way to 
   verify that the correct certificate is being used is to use the hash 
   of the TSA certificate, as indicated in ESSCertID or in ESSCertIDv2.

   When the tsa field from TSTInfo is present, a malicious trusted CA 
   can only attempt to generate a TSA certificate that bears the same 
   TSA name.  

Denis

----- Message reçu ----- 
De : Peter Sylvester 
À : denis.pinkas 
Date : 2009-10-07, 22:52:37
Sujet : Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-update-07.txt

Denis Pinkas wrote: 
Peter,

Extract from RFC 3161:

Denis
Hi,

The "identification" refered to in this text is the one of the TSA, not the CA.
There is nothing in the RFC that requires identifying the CA, the fact that an 
identified certificate has an issuer does not mean that the purpose was
to identify the CA. Note also that issuer/serial in esscertid is still optional
in the esscertid.

I was referring to your text below which seems unclear, what has the 'tsa' field
to do with 'identifying the ca'? If you want to talk about 'identifying the tsa',
yes, the TSA field is optional. As soon as you set the field, what is the
delta brought by ESScertid(v2)?

Peter

----- Message reçu ----- 
De : Peter Sylvester 
À : denis.pinkas 
Date : 2009-10-05, 19:14:07
Sujet : Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-update-07.txt

Hi Denis

Denis wrote

regards

---

From: Peter Sylvester <[email-masked]>
Date: Thu, 08 Oct 2009 13:42:14 +0200

>    *verify that **the correct certificate is being used *is to use the 
> hash 

Well, a security note to be added could be:

Another way to address a potential vulnerability of
the hash function is the following:
If the TSA would have the need to explicitely identify
the certificate chain and its identity, it should set the tsa
field and issuer/serial fields in the ESSCertId(v2)
extensions up a well known trust anchor.

---

From: "Denis Pinkas"<[email-masked]>
Date: Thu, 8 Oct 2009 16:26:06 +0200

Peter,

You suggest to add the following:

"If the TSA would have the need to explicitely identify
the certificate chain and its identity, it should set the tsa
field and issuer/serial fields in the ESSCertId(v2)
extensions up a well known trust anchor".

I don't agree with your proposal.

ESSCertId(v2) does not specify the full chain, but only the certificate from the TSA.
The tsa field is there simply for a quick verification that does not imply any remote access 
nor any cryptographic algorithm (which are both time consuming).

If the tsa field does not have an expected value, the TST can be immediately discarded. It is a kind of protection 
against denial of service attacks by minimizing the computation time to reject wrong TSTs.

In order to verify the digital signature of the TST, the right public key must be used, 
which means that the right certificate must be used.

Denis

---

From: Peter Sylvester <[email-masked]>
Date: Thu, 08 Oct 2009 17:20:13 +0200

> certificate from the TSA.
Hm what does the following mean (the public key cert part)? A tree?

   If more than one certificate is present in the sequence of
   ESSCertIDs, the certificates after the first one limit the set of
   certificates that are used during validation.  Certificates can be
   either attribute certificates (limiting authorizations) or public key
   certificates (limiting path validation). 

> nor any cryptographic algorithm (which are both time consuming).
... a useful feature of an explicit identifier.
>  
> If the tsa field does not have an expected value, the TST can be 
> immediately discarded.
Yes. If the tsa does not do set the value, you can't make the test. Is 
there a good
reason for a tsa not to set it?
> It is a kind of protection

If I'd have to make a DOS attack, I'd would probably set a good tsa name.
> which means that the right certificate must be used.
You mean in order to have a successful outcome of the verification, you need
to have a certificate with a good public key. That's normal.
In certificates and CRL, one has the AKI extension that is a helper
Is the EssCertid is somewhat like that, or more?

regards
Peter

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 08 Oct 2009 19:40:26 +0200

Peter,

I was just about to post something similar.
What i mean is that ESSCertID was designed with the assumption that SHA-1
would provide adequate collision resistance.

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 13 Oct 2009 12:44:49 +0200

Denis,

The following sentence is incorrect:

>    of the TSA certificate, as indicated in ESSCertID or in ESSCertIDv2.

You are excluding the most common way to ensure that you are using an
appropriate certificate.
That is, you pick a certificate that;
> a) is issued by a trusted CA, and;
> b) successfully validates the signature on the time-stamp.

In some extremely high security environment there might be a policy where
this is not enough, but in most cases it is.

/Stefan

---

From: "Denis Pinkas"<[email-masked]>
Date: Tue, 13 Oct 2009 14:18:38 +0200

Stefan,
Denis,

You are excluding the most common way to ensure that you are using an appropriate certificate.
That is, you pick a certificate that; 
a) is issued by a trusted CA, and; 
b) successfully validates the signature on the time-stamp.
The goal of this update is simply to allow the use of hash functions different from SHA-1.
You disagree with the following statement extracted from RFC 2634:
   The signing certificate attribute is designed to prevent the simple
   substitution and re-issue attacks, and to allow for a restricted set
   of authorization certificates to be used in verifying a signature.
RFC 3161 mandates the use of ESSCertID(v2).
You should have raised this concern when RFC 2634 or when RFC 3161 were discussed. 
If you believe that RFC 2634 is incorrect, then you should address your concern to the S-MIME list.
Once again, the goal of this update is simply to allow the use of hash functions different from SHA-1.
Denis
In some extremely high security environment there might be a policy where this is not enough, but in most cases it is.

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 13 Oct 2009 18:15:57 +0200

Denis,

>    of authorization certificates to be used in verifying a signature.

No, I¹m just saying that your statement is wrong.
Your claim ³the only way to verify that the  correct certificate is being
used² is wrong because what is mentioned in your paragraph is not the ³only²
way.

/Stefan

---

From: "Denis Pinkas"<[email-masked]>
Date: Wed, 14 Oct 2009 11:59:15 +0200

Peter,

Sorry, I forgot to respond to the following e-mail.

You are right, it may specify a chain of certificates. However, the shorter the chain will be, the better it is.

Yes. If the tsa does not do set the value, you can't make the test. Is 
there a good reason for a tsa not to set it?

 
> In order to verify the digital signature of the TST, the right public 
> key must be used, which means that the right certificate must be used.

It is more than an helper. It points to single certificates (as long as the hash function does not have colliisions). 
Denis

regards
Peter

---

From: "Denis Pinkas"<[email-masked]>
Date: Wed, 14 Oct 2009 12:00:28 +0200

Stefan,
RFC 3161 states:
   ... the actual identification of the entity
   that signed the response will always occur through the use of the
   certificate identifier (ESSCertID Attribute) inside a
   SigningCertificate attribute which is part of the signerInfo (See
   Section 5 of [ESS])
There is no other way permitted. 
The proposed statement is technically correct. Here it is again:
   When none of these two optional fields is present, the only way to 
   verify that the correct certificate is being used is to use the hash 
   of the TSA certificate, as indicated in ESSCertID or in ESSCertIDv2.
I don't understand why you say : "what is mentioned in your paragraph is not the “only” way".

Denis
----- Message reçu ----- 
De : pkix-bounces 
À : denis.pinkas,pkix 
Date : 2009-10-13, 18:15:57
Sujet : Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-update-07.txt

Denis,

No, I’m just saying that your statement is wrong. 
Your claim “the only way to verify that the  correct certificate is being used” is wrong because what is mentioned in your paragraph is not the “only” way.

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 14 Oct 2009 16:28:08 +0200

Denis,

I see what you are saying.

There is a difference between identification and verification. You use the
hash to ³identify² the signing entity but you use various means to verify
that identification.
An important aspect of that verification is that the certificate matching
the identification is issued by a trusted CA and that the certificate can be
used to validate the signature on the timestamp.

/Stefan

On 09-10-14 12:00 PM, "Denis Pinkas" <[email-masked]> wrote:

> I don't understand why you say : "what is mentioned in your paragraph is not
> the ³only² way".
> 
> Denis
>>  
>> -----  Message reçu -----
>>  
>> De  : pkix-bounces <mailto :[email-masked]>
>>  
>> À  : denis.pinkas,pkix <mailto :[email-masked],[email-masked]>
>>

---

From: "Denis Pinkas"<[email-masked]>
Date: Wed, 14 Oct 2009 16:41:53 +0200

Stefan,

Denis Pinkas, [email-masked]
14/10/2009 
----- Message reçu ----- 
De : Stefan Santesson 
À : denis.pinkas,pkix 
Date : 2009-10-14, 16:28:08
Sujet : Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-update-07.txt

Denis,

There is a difference between identification and verification. You use the hash to “identify” 
the signing entity but you use various means to verify that identification. 
No. The hash is used to VERIFY that it is the correct certificate (not to IDENTIFY it).
For example, if all TSTs are received from the same TSA, you can request the TSA certificate the first time.
Then you can verify that it is the one that is intended to be used for each TST, by VERIFYING the hash value. 
We now need to convergence to some text. 
I don't agree with the text posted in draft-08.txt. 
Can you agree with some portions of my text proposal ?
Denis
An important aspect of that verification is that the certificate matching the identification is issued 
by a trusted CA and that the certificate can be used to validate the signature on the timestamp.

/Stefan

Stefan,

RFC 3161 states:

Denis

-----  Message reçu ----- 

 

Denis,

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 14 Oct 2009 18:36:25 +0200

Denis,

The text you refer to says ³identify² not ³verify².

This means that the hash in ESSCertID have to match the hash of the
certificate.
This is however not enough to verify that it is the right certificate.

Again, I¹m not arguing against what you state here. I argue that the text
you propose in the security considerations section is misleading.

I think the current text in 08 is accurate and adequate.
I¹ll take a closer look one more time at your text, but it would be helpful
to understand what parts of the current draft text that is unacceptable to
you.

/Stefan

On 09-10-14 4:41 PM, "Denis Pinkas" <[email-masked]> wrote:

> Stefan,
>  
> Denis Pinkas, [email-masked]">[email-masked] <mailto :>
> 14/10/2009 
>>  
>> -----  Message reçu -----
>>  
>> De  : Stefan Santesson <mailto :[email-masked]>
>>  
>> hash to  ³identify²
>> the identification is issued
>>> I  don't understand why you say : "what is mentioned in your paragraph is
>>> not  the ³only² way".
>>> 
>>> Denis
>>>  
>>>> 
>>>> -----  Message reçu -----
>>>> 
>>>> used² is wrong  because what is  mentioned in your paragraph is not the
>>>> ³only²   way.
>>>> 
>>>> /Stefan
>>> 
>>>  
>>>

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 15 Oct 2009 12:51:03 +0200

Denis,

You asked me specifically if any of your text proposals are acceptable.
I will comment on it below.

On 09-10-08 12:30 PM, "Denis Pinkas" <[email-masked]> wrote:

> Comment: This part is not debated
> 
> Comment: This text is correct. This is however by design and not a security
> issue.
> 
> Comment: This field is misleading. The requirement of RFC 3161 is that the
> identifier of ESSCertID must match the selected certificate, but it is
> misleading to say that this is the only way. The fact that a trusted
> certificate can validate the signature on the time-stamp is also a strong
> indication as well as a necessary check.
> 
> Comment: This is correct
> Comment: This text is also misleading as stated above. It can easily be
> misunderstood to say that the certificate is validated purely by matching the
> hash of the certificate with the hash of ESSCertID/v2.
> 
> Comment: This information is correct but incomplete. The matching certificate
> does also have to be capable of validating the signature, else it will be
> rejected 
> 
> Comment: This is correct
> Comment: This is not debated.
> 
> 
In summary I record the following problems with your text:
1. It provides a false sense of threat. The text formulates something which
sounds like a plausible and serious threat. A trained person will realize
that the threat requires a broken PKI (a trusted malicious CA) but this is
may not be obvious to an implementer.
2. It provides a false sense of security by first indicating that a broken
PKI is an in-scope threat and secondly suggesting a solution (ESSCertIDv2).
A reader could then believe that ESSCertIDv2 protects against a broken PKI.
Nothing in the text indicates the fact that a broken PKI also would enable a
large set of other threats, against which ESSCertIDv2 provides no
protection.

The current text in draft 08 does address these issues.

However, the explanation you provide regarding the tsa field and it¹s role
in identifying the signer certificate is currently not present in 08.
I would not object to work in some of that text into the current draft.

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 20 Oct 2009 10:09:33 +0200

Denis,

> Can you agree with some portions of my text proposal ?

I have tried to work in the essence of your proposal.
A hopefully final attempt to accommodate your comments would be the
following text:

3  Security Considerations

   The certificates field from the SignedData structure, which may
   contain the TSA certificate, is optional and unsigned if present.
   This information therefore needs to be validated before use through
   certificate path validation as well as verification that the
   certificate matches the signature on the time stamp. The tsa field
   from TSTInfo is optional.  When this field is absent, the only way to
   identify that a certificate is the one intended by the TSA (among all
   certificates that meets the criteria for being valid), is to match
   the certificate with the information in ESSCertID or ESSCertIDv2.

   Upgrading the hash function through ESSCertIDv2 addresses a

Could you live with this text?

/Sfefan

---

From: "Peter Rybar" <[email-masked]>
Date: Wed, 21 Oct 2009 11:41:11 +0200

Dear all,

The [email-masked] timestamp discussion about allowing to use ESSCertIDv2 (defined in RFC 5035) together with presently used mandatory ESSCertID(SHA1) in timestamp causes a confusion.

For example at one important meeting, an expert from one EU country presented that he was incorrectly informed that the usage of ESSCertID or ESSCertIDv2 is useful only for solving of the hypothetical attack which is not possible in reality and mentioned that it was the opinion of IETF and ETSI experts.

According to such incorrect information from unknown UK IETF or ETSI expert, the one national decision of the usage of ESSCertID or ESSCertIDv2 presented ESSCertID or ESSCertIDv2 as not useful as mandatory to be included in Qualified Electronic Signatures or AdES based on Qualified Certificates. 

For that reason I would like to remind that at least two easy realizable attacks are possible:

Anybody can use any editor tools for substitution attack e.g. http://lipingshare.com/Asn1Editor/ which is really smart.

1. Attacker (timestamp or electronic document signer) asks two trusted CA for issuing of two certificates with the same key.

2. Attacker asks one CA for revocation of one certificate.

3. If ESSCertID or ESSCertIDv2 is not used, the attacker is able to substitute the signer certificate in timestamp (or signature).

4. The electronic signature is therefore not useable as trusted evidence in some actions.

1. Attacker (timestamp or electronic document signer) asks two trusted CA for issuing of two certificates with the same key but the second certificate is asked and issued after the expiration of the first certificate issued for the same key.

2. If ESSCertID or ESSCertIDv2 is not used, the attacker is able to substitute the signer certificate in timestamp (or signature).

3. The electronic signature is therefore not useable as trusted evidence in some actions.

If a certificate is used only as a carrier of public key and the certificate validity is not important, then also ESSCertID or ESSCertIDv2 is not important but in any other situation when the validity has a significant impact on some actions, ESSCertID or ESSCertIDv2 must be used. 

Another possibility for solving such attacks is to have mandatory rules for CA and registration authorities:

The CA must issue a certificate only for the key which was newly generated by CA or registration operators before the certificate creation. 

Regards, 

Peter Rybar

tel.: +421 2 6869 2163

mob.: +421 902 891 155

fax:  +421 2 6869 1701

e-mail: [email-masked]

e-mail: [email-masked]

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of Stefan Santesson
Sent: Tuesday, October 20, 2009 10:10 AM
To: [email-masked]; pkix
Subject: Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-update-07.txt

---

From: "Denis Pinkas"<[email-masked]>
Date: Wed, 21 Oct 2009 14:56:13 +0200

Stefan,

We converge slowly, but we converge ...

I have taken your text as an input and I worked on it. 

I tried to make the difference between "how to verify the certificate" and 
"how to find the "certificate". This lead me to re-organize the text.

I can certainly live with your proposed sentence:

   However, trusting a malicious CA to issue TSA certificates enables 
   a wide range of other threats that are not mitigated by ESSCertIDv2. 

However, I insist to delete the following sentence:
 
   Threats in general, caused by a trusted malicious CA, are therefore out of
   scope of this specification.

   ... simply because the text placed before addresses a threat caused by a malicious CA.

My proposal is the following:

   The way to verify that a certificate is the one intended by the TSA 
   (among all certificates that meets the criteria for being valid),
   is to match the certificate with the information in ESSCertID or 
   ESSCertIDv2.

   There are several ways to find that certificate, e.g.:
   
     a) to use the certificates field from the SignedData structure, 
        which may contain the TSA certificate. However, this field is 
        optional and since it is unsigned, it may be replaced on the wire.
     b) to use the tsa field from TSTInfo. However, this field is 
        optional.
     c) to know the TSA name or the TSA certificate using out-of-bands means.
   ESSCertID(v2) addresses 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. Upgrading the hash function makes the creation of 
   a fake certificate even more difficult. However, trusting a malicious CA 
   to issue TSA certificates enables a wide range of other threats that 
   are not mitigated by ESSCertIDv2.
Denis

----- Message reçu ----- 
De : Stefan Santesson 
À : denis.pinkas,pkix 
Date : 2009-10-20, 10:09:33
Sujet : Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-update-07.txt

Denis,

Denis

I have tried to work in the essence of your proposal.
A hopefully final attempt to accommodate your comments would be the following text:

/Sfefan

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 21 Oct 2009 15:00:13 +0200

Peter,

I don¹t understand your two attacks. In both attacks there is only one valid
certificate (as the other is either revoked or expired).
Are you sketching a DoS attack here where I replace a valid certificate with
an invalid one?

Secondly, the issue is not whether to use ESSCertID or not. The Issue
discussed in PKIX is the security considerations for using a hash stronger
than SHA-1.

The only threat scenarios mentioned involves a malicious trusted CA. One
point in this discussion is that a Malicious trusted CA poses a whole range
of threats that ESSCertID does not address. ESSCertID is therefore not a
solution to that problem more than from a very narrow perspective. In
general, trust in a malicious trusted CA is out of scope for PKI dependent
protocols. Such threats have to be mitigated through better supervision and
accreditation of CAs.

/Stefan

On 09-10-21 11:41 AM, "Peter Rybar" <[email-masked]> wrote:

> Dear all,
> The [email-masked] timestamp discussion about allowing to use
> ESSCertIDv2 (defined in RFC 5035) together with presently used mandatory
> ESSCertID(SHA1) in timestamp causes a confusion.
>  
> For example at one important meeting, an expert from one EU country presented
> that he was incorrectly informed that the usage of ESSCertID or ESSCertIDv2 is
> useful only for solving of the hypothetical attack which is not possible in
> reality and mentioned that it was the opinion of IETF and ETSI experts.
>  
> According to such incorrect information from unknown UK IETF or ETSI expert,
> the one national decision of the usage of ESSCertID or ESSCertIDv2 presented
> ESSCertID or ESSCertIDv2 as not useful as mandatory to be included in
> Qualified Electronic Signatures or AdES based on Qualified Certificates.
>  
> Anybody can use any editor tools for substitution attack e.g.
> http://lipingshare.com/Asn1Editor/ which is really smart.
>  
> 1. Attacker (timestamp or electronic document signer) asks two trusted CA for
> issuing of two certificates with the same key.
> 3. If ESSCertID or ESSCertIDv2 is not used, the attacker is able to substitute
> the signer certificate in timestamp (or signature).
> 1. Attacker (timestamp or electronic document signer) asks two trusted CA for
> issuing of two certificates with the same key but the second certificate is
> asked and issued after the expiration of the first certificate issued for the
> same key.
> 2. If ESSCertID or ESSCertIDv2 is not used, the attacker is able to substitute
> the signer certificate in timestamp (or signature).
> If a certificate is used only as a carrier of public key and the certificate
> validity is not important, then also ESSCertID or ESSCertIDv2 is not important
> but in any other situation when the validity has a significant impact on some
> actions, ESSCertID or ESSCertIDv2 must be used.
> The CA must issue a certificate only for the key which was newly generated by
> CA or registration operators before the certificate creation.
>  
> Regards, 
> Peter Rybar
>  
> tel.: +421 2 6869 2163
> mob.: +421 902 891 155
> fax: +421 2 6869 1701

---

From: "Peter Rybar" <[email-masked]>
Date: Thu, 22 Oct 2009 12:15:35 +0200

Stefan,

>Secondly, the issue is not whether to use ESSCertID or not. 
>The Issue discussed in PKIX is the security considerations for using a hash stronger than SHA-1.

Yes, exactly I agree that discussion is about the impact of upgrade from ESSCertID to ESSCertIDv2. And for that reason this specific issue must be described carefully not to confuse people that the whole usage of ESSCertID/v2 is unimportant.

CMS signature (RFC 5652) when the ESSCertID/v2 is not used is open for many substitution attacks which are realizable with and also without a Malicious trusted CA.

Generally speaking if ESSCertID/v2 is not used in CMS, then the right public key for verification of signature must be selected according to test if the digital signature is correctly verified.

Without ESSCertID/v2 the connection of signer’s attributes with the public key is not protected and for that reason any kind of public key carries can be used e.g. certificates X509 v1...v5, PGP... Such unprotected connection of the signer’s attributes with the signer’s public key by CMS signer signature could cause many attacks. Two attacks which I have described are realized by trusted CA which is not Malicious. The number of possible attacks if the connection is not protected is endless. I have not mentioned e.g. the attack on identity in certificates where the certificates may be issued for different purposes with different identity values for the same public key. Another attack could be if the relying system accepts more than one CA and the attribute certificate connected with certificate issued in one CA can be accepted also if issued in the second CA, then by substitution attack you can achieve a granted access to some systems.

When the qualified certificates are used, then you can simply break the nonrepudiation of QES. If you have sent the same signature with the different certificate issued for the same public key to different organization, the legal action can be realized in a different way. If those organizations are not able to compare the QES signature, then nobody can detect such attack.
 
I agree that the registration process could be a big hole if the registration person under some pressure/whish of external powerful group issues a qualified certificate with the identity of someone else for people from the powerful group, then the effect of QES acceptance in legal actions like selling the house could be catastrophic, but it must be solved pursuant to rules of the registration authority.

	Regards, 
	Peter Rybar
	 
	tel.: +421 2 6869 2163
	fax: +421 2 6869 1701
	http://elpi2.szm.com/

---

From: Peter Lipp <[email-masked]>
Date: Thu, 22 Oct 2009 15:01:04 +0200

> then the right public key for verification of signature must be 
>selected according to test if the digital signature is correctly 
> verified.
I assume you mean the right certificate. The right key is always
necessary. And of course the right certificate is a good thing to have.
And to keep, if this may be of any importance later.

> Another attack could be if the relying system accepts more than one CA
> and the attribute certificate connected with certificate issued in one
> CA can be accepted also if issued in the second CA, then by
> substitution attack you can achieve a granted access to some systems.
I am not sure I understand. Do you mean I provide an ID-Cert from CA1
and an Attr,Cert from CA2 and the relying system accepts that? If this
results in a problem, then the system has not been configured properly
IMHO. Or, if the ID-Cert from CA2 was revoked, the Attribute Cert should
have been revoked as well.

> When the qualified certificates are used, then you can simply break
> the nonrepudiation of QES. If you have sent the same signature with
> the different certificate issued for the same public key to different
> organization, the legal action can be realized in a different way. 
Now (assuming the SSCD would allow this to happen), if you have two
qualified certificates for one key, any signature together with any of
them would be valid throughout Europe. So where is the practical attack?
To claim "I have not signed this" because it comes with Certificate A
and I show Certificate B, go to court and look stupid facing the judge
and an independent expert? Like having an Austrian and an Slovak number
plate for my car and claim it wasn't me who was speeding? 

Generally, we should provide a handrail, but we can't prevent people
from jumping from the bridge if they want to.

Peter
-- 
---
IAIK, Graz University of Technology
Inffeldgasse 16a
A-8010 Graz
Tel: +43 316 873 5513
Fax: +43 316 873 10 5513
www.iaik.tugraz.at

-- 
---
IAIK, Graz University of Technology
Inffeldgasse 16a
A-8010 Graz
Tel: +43 316 873 5513
Fax: +43 316 873 10 5513
www.iaik.tugraz.at