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

From: Stephen Kent <[email-masked]>
Date: Tue, 8 Sep 2009 10:17:14 -0400

Folks,

Based on the discussions on list and Stefan's revisions, I think this 
is ready for WGLC.  The last call starts today, and will end on Sept. 
18.

Steve

---

From: "Denis Pinkas"<[email-masked]>
Date: Wed, 16 Sep 2009 11:12:50 +0200

I have problems of understanding with the Security Considerations section
 
The text first says:
 
   "This draft incorporates the security considerations of RFC 5035
   [ESSv2]".
 
In RFC 5035, we have the following sentence:
   "A poorly selected hash algorithm may provide inadequate protection    against certificate substitution or result in denial of service for    this protection". 
This sentence contradicts the text which follows:
 
   “Provided that the PKI used to validate the TSA certificate is not
   broken or compromised, the identifier used to identify the signer
   certificate is only used to distinguish between valid non revoked TSA
   certificates. The chance of colliding identifiers is negligible even
   if a poor hash algorithm is used.
 
   The update provided by this draft is thus motivated by reasons of
   interoperability and migration to other hash algorithms rather than
   security”.
 
First of all, a “PKI” does not validate a TSA certificate. A “verifier” 
may validate a TSA certificate. Then the terms “broken or compromised” 
are used. What would mean a broken or compromised verifier ? What would 
mean a broken or compromised PKI ? An AC may be compromised.
 
Then the text says that “the identifier used to identify the signer certificate
is only used to distinguish between valid non revoked TSA certificates”.
 
This is not correct. The identifier used to identify the signer certificate 
is used to identify the CA which delivered the certificate to the TSA according 
to the rules (i.e. Certification Policy) used by that CA. The point is not 
to distinguish between valid non revoked TSA certificates, but to distinguish 
between TSA certificates. A CA unknown to the TSA could issue a certificate 
to a TSA. If the identifier was not present certificate substitutions would be possible. 
 
I guess that the core of the security issue is :
how strong / weak should the hash algorithm used in ESSCertID should be ?
 
ESSCertIDv2 is defined as :
        ESSCertIDv2 ::=  SEQUENCE {           hashAlgorithm           AlgorithmIdentifier                   DEFAULT {algorithm id-sha256},            certHash                 Hash,            issuerSerial             IssuerSerial OPTIONAL        }
The TST includes:
   tsa                          [0] GeneralName          OPTIONAL,
 
Suppose that there exists two CAs with the same name.
 
If the hash function is weak, then it is possible to a CA that bears the same name 
to create a TSA certificate that bears the same serial number for the same TSA 
which would have the same hash. Some non critical extension can be used to hold 
the octet string that would make the two hashes equal. Then substitution is no more visible. 
 
Typos:
 
At the top of each page, it would be better to change ESSCertIDV2 into ESSCertIDv2.
 
On page 5 on the last line from the second note, it would be better to change ESSCertIDV2 into ESSCertIDv2.
 
Denis
 
----- Message reçu ----- 
De : pkix-bounces 
À : pkix 
Date : 2009-09-08, 16:17:14
Sujet : [pkix] WGLC draft-ietf-pkix-rfc3161-update-03.txt

Folks,

Steve
_______________________________________________
pkix mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pkix

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 16 Sep 2009 14:01:03 +0200

Denis,

Comments in-line;

On 09-09-16 11:12 AM, "Denis Pinkas" <[email-masked]> wrote:

>    "A poorly selected hash algorithm may provide inadequate protection
>    against certificate substitution or result in denial of service for
>    this protection".
>    ³Provided that the PKI used to validate the TSA certificate is not
>    security².

This text is meant to clarify 5035. 5035 states "may". In this draft we
clarify the context and explains that for the context of the TSA protocol,
there are no security issues.

How about the following further clarification?

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

> First of all, a ³PKI² does not validate a TSA certificate. A ³verifier²
> may validate a TSA certificate.

The draft does not claim that the PKI validates the TSA certificate. "A PKI
is used to validate" means that the verifier uses the Public Key
Infrastructure as means to validate.

> Then the terms ³broken or compromised²

It means the "PKI used to validate". That includes all keys, certificates
and algorithms used or being relied upon in the validation process.

Broken means that algorithms and/or chosen key sizes can't provide the
security properties they are designed for.

Compromised means that vital security components such as keys have been
exposed and that exclusive control over these secrets are lost.

This is assumed to be common knowledge, which does not require explicit
further explanation in this draft.

> Then the text says that ³the identifier used to identify the signer
> certificate
> is only used to distinguish between valid non revoked TSA certificates².
>  
> This is not correct.

It is correct. Even in the examples you give below.

> The identifier used to identify the signer certificate
> between TSA certificates.

Since non-valid and/or revoked certificates can be excluded (as they simply
are invalid and will not be accepted anyway) TSA certificates equals non
revoked and valid TSA certificates.

> A CA unknown to the TSA could issue a certificate
>         ESSCertIDv2 ::=  SEQUENCE {
>            hashAlgorithm           AlgorithmIdentifier
>                    DEFAULT {algorithm id-sha256},
>             certHash                 Hash,
>             issuerSerial             IssuerSerial OPTIONAL
>         }
> The TST includes:

This is of no relevance. First of all it is extremely easy to make your name
unique if all valid TSA certificates have valid names (and not just random
pseudonyms). Secondly, even if there was a name collision, the number of
valid certificates with colliding CA names would be so small, that hash
collision between these certificates is still extremely unlikely.

Finally, your scenario only covers when BOTH the CA name AND the CA public
key (with parameters) are identical. If the CA certificate holds another
key, it can't be used to validate the time-stamp token, and will be rejected
of that reason.

> ESSCertIDV2 into ESSCertIDv2.

Thanks, both noted and will be fixed in the next version.

/Stefan

---

From: "Denis Pinkas"<[email-masked]>
Date: Wed, 16 Sep 2009 14:33:36 +0200

Stefan,
Thanks for the quick answer.
Responses are embedded in the text.
----- Message reçu ----- 
De : pkix-bounces 
À : denis.pinkas,pkix 
Date : 2009-09-16, 14:01:03
Sujet : Re: [pkix] WGLC draft-ietf-pkix-rfc3161-update-03.txt

Denis,

Comments in-line;

   This draft incorporates the security considerations of RFC 5035
   [ESSV2] with the clarifications stated in this section.
How about:
   This draft incorporates the security considerations of RFC 5035
   [ESSV2] with further explanations in this section.

> mean a broken or compromised PKI ? An AC may be compromised.

OK. I missread.

It is correct. Even in the examples you give below.
I still disagree. See below.

Substitution of a TSA certificate may happen at diffrent time. It may be done when the TST is in placed in a file included ina directory. 
At this time, they is no real-time checking of the revocation state.  
> the octet string that would make the two hashes equal. Then substitution is no

This is of no relevance. 
One reason for using ESSCertID is to distinguish between TSAs that might have the same DN.
Another reason is to distinguish between CAs that might have the same DN.
I agree that the case of both DNs being identical is extremely unlikely, if the DNs are correctly chosen, 
i.e. use a sufficient number of distinctive attributes. This should be the main message to be given 
in this security considerations section.
Now, if such name collisions exist, then the hash algorithm MUST be strong.
Said another way, if there is no such collision, the hash is not needed at all.
There is no case where it can be weak.
First of all it is extremely easy to make your name
unique if all valid TSA certificates have valid names (and not just random
pseudonyms). Secondly, even if there was a name collision, the number of
valid certificates with colliding CA names would be so small, that hash
collision between these certificates is still extremely unlikely.

Finally, your scenario only covers when BOTH the CA name AND the CA public
key (with parameters) are identical. If the CA certificate holds another
key, it can't be used to validate the time-stamp token, and will be rejected
of that reason.
No. The CA public keys may be different.
Denis

/Stefan

---

From: "Denis Pinkas"<[email-masked]>
Date: Wed, 16 Sep 2009 15:29:03 +0200

Stefan,

The TSA public key can't change.
The CA public key can change.

Denis

----- Message reçu ----- 
De : Stefan Santesson 
À : denis.pinkas,pkix-bounces,pkix 
Date : 2009-09-16, 15:25:46
Sujet : Re: [pkix] WGLC draft-ietf-pkix-rfc3161-update-03.txt

Denis,

> No. The CA public keys may be different.

How can you successfully replace a TSA certificate with one that has another
public key (that can't be used to validate the time-stamp token)?

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 16 Sep 2009 15:25:46 +0200

Denis,

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 16 Sep 2009 15:49:59 +0200

Denis,

Yes sorry. I missed the distinction.

But the identified TSA certificate must also be identical.
So the scenario is that we have two identical TSA certificates (with same
TSA name and same TSA public key) certified by different CAs using the same
CA name but different CA keys, and you are concerned that these certificate
paths are both valid but may have colliding hashes unless we use a strong
hash. Is that how I should understand this?

/Stefan 

On 09-09-16 3:29 PM, "Denis Pinkas" <[email-masked]> wrote:

>> De  : Stefan Santesson <mailto :[email-masked]>
>>  
>> À  : denis.pinkas,pkix-bounces,pkix <mailto
>> :[email-masked],[email-masked],[email-masked]>
>>  
>> On 09-09-16 2:33 PM, "Denis Pinkas" <[email-masked] <mailto:
>> [email-masked]> >  wrote:
>>

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 16 Sep 2009 15:56:27 +0200

Denis,

This change is fine by me.

---

From: "Denis Pinkas"<[email-masked]>
Date: Wed, 16 Sep 2009 16:03:20 +0200

Stefan,
----- Message reçu ----- 
De : pkix-bounces 
À : denis.pinkas,pkix 
Date : 2009-09-16, 15:49:59
Sujet : Re: [pkix] WGLC draft-ietf-pkix-rfc3161-update-03.txt

Denis,

But the identified TSA certificate must also be identical.
I would reformulate your sentence by saying: the ESSCerIDs must also be identical (not the TSA certificates).
So the scenario is that we have two identical TSA certificates (with same TSA name and same TSA public key) 
certified by different CAs using the same CA name but different CA keys, and you are concerned that 
these certificate paths are both valid but may have colliding hashes unless we use a strong hash. 
Is that how I should understand this?
Yes. 
Denis
/Stefan 

Stefan,

Denis

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

À  : denis.pinkas,pkix-bounces,pkix <mailto :[email-masked],[email-masked],[email-masked]>   

 

Denis,

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 16 Sep 2009 16:34:46 +0200

Denis,

I have submitted a new draft covering the aspects that we agree on:
http://www.ietf.org/id/draft-ietf-pkix-rfc3161-update-04.txt

Further comments in line:

> identical (not the TSA certificates).

But this is my point. If the TSA certificates are valid (issued by real
trusted CAs) then the chance that they would produce the same hash even if I
use MD2, is infinitely small.

Further, the chance that they would contain the same public key just by
chance is even less likely. Less than the 80 bits of security NIST calim is
OK for now.

All of course based on the assumption that the CA is trusted (not trying to
fool us).

If you are trying to protect us against a "bad" CA with malicious intent
(that has not set its evil bit to alert the world (RFC 3514)), then I would
suggest that the game is totally lost in any case as there are a magnitude
of bad things a trusted bad CA can do, no matter how strong your hash is.

>> TSA name and same TSA public key)

Good, then the security considerations section is correct.
If the CAs involved are trusted, and not in a mission to fool us, then this
collision is so unlikely, even with a "poor" hash, that it can safely be
neglected.

If you disagree, then please provide an example where a successful attack
can be launched (not involving a bad dishonest CA).

/Stefan

---

From: "Denis Pinkas"<[email-masked]>
Date: Wed, 16 Sep 2009 16:56:48 +0200

Stefan,

I disagree with your argumentation.

If the hash function is strong, then a "bad CA" that would have the same DN 
as the CA that is trusted by the TSA cannot do anything.

Your sentence: "there are a magnitude of bad things a trusted bad CA can do, 
no matter how strong your hash is" is not appropriate.

The first part is correct, but not the second one, since in the case a strong hash function 
does provide the protection.

The ESSCertID is there to counter bad CAs. By placing an ESSCerTID the TSA advertises 
that he got his certificate from a given CA according to the rules (i.e. CP) of that CA.
If a CA with the same DN issues a certificate for that TSA, that certificate will not be accepted.
That CA may issue keys to TSAs according to a different Certification Policy. This CP would be ignored.

As you already know, I will have a surgery tomorrow, keeping me away from my office for some time.
Please do not take advantage of this situation to say that no further response from me means an approval.

So, unless you see a message saying "I agree", I disagree with version 04.
If you really want the text to go out quickly, I could agree if the security considerations section only states:

"This draft incorporates the security considerations of RFC 5035 [ESSV2]".

This may be insufficient, but would be technically correct.

Denis

----- Message reçu ----- 
De : pkix-bounces 
À : denis.pinkas,pkix 
Date : 2009-09-16, 16:34:46
Sujet : Re: [pkix] WGLC draft-ietf-pkix-rfc3161-update-03.txt

Denis,

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 16 Sep 2009 17:07:47 +0200

Denis;

On 09-09-16 4:56 PM, "Denis Pinkas" <[email-masked]> wrote:

> The ESSCertID is there to counter bad CAs.

Great. Good to have that established. It makes the argumentation easier.

> as the CA that is trusted by the TSA cannot do anything.

How about this. The bad but trusted CA can issue a certificate for a bad
TSA. That bad TSA can provide bad timestamps with a perfectly valid
ESSCertIDv2 using a SHA-2 hash to convince you that the bad TSA really
intended to use its own certificate.

> This may be insufficient, but would be technically correct.

I think it would be worse, but I could live with it.
Let's see what the rest of the list has to say.

/Stefan

---

From: "Denis Pinkas"<[email-masked]>
Date: Wed, 16 Sep 2009 17:57:02 +0200

Stefan,

This message will be my last message to this list before some time. 

Your text proposal was made too quickly and is all wrong.

The TSA is not bad. Only the CA is bad.

Then you said:

"That bad TSA can provide bad timestamps with a perfectly valid
ESSCertIDv2 using a SHA-2 hash to convince you that the bad TSA really
intended to use its own certificate".

I don't think it is currently possible to break a SHA-2 hash, even by a bad CA, so your sentence is wrong.

Denis

----- Message reçu ----- 
De : Stefan Santesson 
À : denis.pinkas,pkix 
Date : 2009-09-16, 17:07:47
Sujet : Re: [pkix] WGLC draft-ietf-pkix-rfc3161-update-03.txt

Denis;

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 16 Sep 2009 19:02:46 +0200

Denis,

> The TSA is not bad. Only the CA is bad.

I didn't make any text proposal

> CA, so your sentence is wrong.

I don't think you really read my example. In my example there is a fake TSA.
This fake TSA does not have to break any hash to include a valid
ESSCertIDv2.

That is a problem caused by a bad CA that is not solved by ESSCertIDv2.

I hope to hear from you soon. Good luck again.

/Stefan 

>> À  : denis.pinkas,pkix <mailto :[email-masked],[email-masked]>
>>  
>> On 09-09-16 4:56 PM, "Denis Pinkas" <[email-masked] <mailto:

---

From: Peter Sylvester <[email-masked]>
Date: Thu, 17 Sep 2009 00:10:28 +0200

Hello,

What is the security threat here?

A TSA has a public key and id and a certificate from on named CA.
In each time stamp, it indicates it id and the id of the CA, and
the hash of a cert.

With some probability another trustworthy CA has the same NAME
and may be able to create another certificate with the same esscertid,
assuming that you get to this situation:

This certificate would be substituted to the original one in order
to do what?

- To have a relying party refuse a time stamp or accept it?
- what use case of a timestamp could be a problem?

regards
Peter

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 17 Sep 2009 00:25:05 +0200

Peter,

I'm asking myself the same question.
Nobody so far has provided me with a plausible attack scenario, and I have
hade quite a few discussions with smart people on this subject.

The only ones I have seen involves a bad CA, but trusting a bad CA can't be
fixed by a strong hash in ESSCertIDv2 anyway. At most it may limit the
attack surface slightly.

/Stefan

---

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

Stefan, Peter,

I agree that it is very difficult to identify a threat scenario where a
"Trusted" CA would want to provide a certificate which the false name
against a TSA's name.

However, the point of the change because the slight doubt of whether
certificate substitution is a problem has made some EU governments madate
its presence, and also they have a rule regarding phasing out SHA-1.

Making valued statement as to the reason only opens up the debate.

Given that there is agreement to make the change is there a need to do more
than reference the RFC 5035 security considerations.

Nick

-----Original Message-----
From: [email-masked]
To: Peter Sylvester
Cc: pkix; [email-masked]
Sent: 16/09/2009 23:25
Subject: Re: [pkix] WGLC draft-ietf-pkix-rfc3161-update-03.txt

Peter,

I'm asking myself the same question.
Nobody so far has provided me with a plausible attack scenario, and I
have
hade quite a few discussions with smart people on this subject.

The only ones I have seen involves a bad CA, but trusting a bad CA can't
be
fixed by a strong hash in ESSCertIDv2 anyway. At most it may limit the
attack surface slightly.

/Stefan

_______________________________________________
pkix mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pkix
Consider the environment before printing this mail.
"Thales e-Security Limited is incorporated in England and Wales with company
registration number 2518805. Its registered office is located at 2 Dashwood
Lang Road, The Bourne Business Park, Addlestone, Nr. Weybridge, Surrey KT15
2NX.
The information contained in this e-mail is confidential. It may also be
privileged. It is only intended for the stated addressee(s) and access to it
by any other person is unauthorised. If you are not an addressee or the
intended addressee, you must not disclose, copy, circulate or in any other
way use or rely on the information contained in this e-mail. Such
unauthorised use may be unlawful. If you have received this e-mail in error
please delete it (and all copies) from your system, please also inform us
immediately on +44 (0)1844 201800 or email [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: Thu, 17 Sep 2009 11:50:16 +0200

Nick,

I think one reason why some governments make requirements like this is
because documents like the one we just write is not clear on the reason why
we add such a feature.

There is an increased risk that other governments or organizations otherwise
will read this new draft and believe that they have to use ESSCertIDv2 with
a strong hash because it is required to mitigate known threats.

If it proves to be too controversial to say that this change is not
motivated by reasons of security, then I will not fight it to the bitter
end, but I think we make a disservice to the community by not saying so.

/Stefan

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 17 Sep 2009 22:11:16 +1200

Stefan Santesson <[email-masked]> writes:

> will read this new draft and believe that they have to use ESSCertIDv2 with a
> strong hash because it is required to mitigate known threats.

I agree that this is a serious problem, users won't understand the feature but
will mandate it just because it's in the spec.  So if it's really felt
necessary to add it, why not just add some text that summarises the discussion
on the list, something like "This facility serves no identifiable purpose but
was added because some regulatory agencies may mandate it".  This should
satisfy both camps, it points out that it doesn't address any identifiable
threat or issue, but also defines the format for people who want to use it
anyway.

Peter.

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Thu, 17 Sep 2009 12:47:29 +0200

Peter Gutmann wrote:
> why not just add some text that summarises the discussion
> on the list, something like "This facility serves no identifiable
> purpose but was added because some regulatory agencies may mandate it".

"At this moment, no specific security threat associated with the use of 
ESSCerID has been identified. The introduction of ESSCerIDv2 does not 
aim to avoid a specific security concern, but aims to enable 
implementers to comply with policies that require phasing out all uses 
of the SHA-1 algorithm."

The wording can probably be improved, but I think that's the idea.

You know, Peter, I think most of what you say would be a lot more useful 
if it were just a little bit less inflammatory.

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 17 Sep 2009 23:09:28 +1200

> if it were just a little bit less inflammatory.

It's not inflammatory, it's intended to let people know exactly what they're
getting.  The problem with the suggested replacement text is that it's now all
weasel-words, you could use most of it to justify including mpeg-of-cat, or
pretty much anything else, in the timestamp.  So the intent of providing
truth-in-advertising to let people make an informed decision seems to have
mostly been defeated.

Peter.

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 17 Sep 2009 13:49:12 +0200

Jean-Marc,

2 things.

Your text is perfectly acceptable to me, and;
I didn't find Peter Gutman's arguments even a tiny bit inflammatory.

/Stefan