Subject: Re: [pkix] rfc3161 TimeStamps and sha1-based sigs/imprints in pkcs7/cms

From: Peter Gutmann <[email-masked]>
Date: Fri, 01 Jul 2011 20:44:27 +1200

Martin Rex <[email-masked]> writes:

>The original plan was to _have_completed_ phasing out the use of SHA-1 for 
>digital signatures by the end of 2010, but that target seems to have been 
>missed entirely.  There is a significant availability of RSA 2048-bit 
>certificates, but the use of sha256WithRsaEncryption is still at homeopathic 
>levels.

I think one reason for this may be the vanishingly small use of TSP.  There's 
a pile of closed environments for which the goal is to meet requirements set 
ten years ago by lawyers that haven't been updated since then (and where they 
could just as well use CRC32 because the target is to meet some particular 
compliance requirement rather than to follow the state of the art in 
security), and that's about it (AuthentiCode uses timestamping but AFAIK 
that's a standard PKCS #7 countersignature and not what TSP does).

So the apparent apathy over hash algorithms could just be a reflection of the 
actual apathy over TSP.

Peter.

---

From: Rob Stradling <[email-masked]>
Date: Fri, 1 Jul 2011 10:21:42 +0100

On Friday 01 Jul 2011 09:44:27 Peter Gutmann wrote:
<snip>
> state of the art in security), and that's about it (AuthentiCode uses
> timestamping but AFAIK that's a standard PKCS #7 countersignature and not
> what TSP does).

The Windows 7 implementation of Authenticode still supports Microsoft's legacy 
PKCS#7 countersignature timestamping [1], but it also introduces support for 
RFC3161 timestamping [2].

Microsoft require all Code Signing CAs in the Microsoft Root Certificate 
Program to "operate a timestamp server authority (TSA) in conjunction with 
their code signing service, and as a best practice request that Subscribers 
timestamp the digital signature after signing their code.  Effective no later 
than October 31, 2011, the TSA must comply with RFC 3161" [3].

[1] http://msdn.microsoft.com/en-us/library/bb931395%28v=vs.85%29.aspx

[2] http://msdn.microsoft.com/en-us/library/aa387764%28v=vs.85%29.aspx
(signtool's "/tr" and "/td" flags)

[3] Sorry, I can't find this requirement stated on any public webpages.

> So the apparent apathy over hash algorithms could just be a reflection of
> the actual apathy over TSP.
> 
> Peter.
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix

Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

---

From: [email-masked]
Date: Fri, 1 Jul 2011 13:59:36 +0200

Martin,

You seriously question the security of timestamps with sha1-based 
signatures.

Formats have been described on how to address this issue in general, i.e. 
when the hash function becomes weak.

Such formats exist in the context of Advanced Electronic Signatures with 
the AdES-A format as defined 
by ETSI for CAdES and XAdES.

Late 2009, ETSI has defined new ways to sign PDF documents which can 
contain several time-stamps.
See ETSI TS 102 778-4. In this document, it is explained that TSTs can be 
used in two cases: 
when the document is signed and when the document is unsigned.

Note: In order to capture the content of this document, it may be useful 
to read parts 1 to 3 as well.

While formats exist, in many cases the way to use these formats is not 
crystal clear.

Basically, the problem to "renew a time-stamp" does not happen first 
because the hash function 
becomes weak, but because the validity period of the TSU certificate is 
over.

A new TST must then be used to protect the previous one.

It must then be demonstrated that, at the time the new TST was applied, 
the certificate of the previous 
time-stamp was not revoked with the revocation reason "key compromise".

So the certification path and the revocation information MUST be captured 
and a new TST 
(with a stronger hash function) must be applied.

Do you think it might be useful to draft an Informational RFC to explain 
such things ?

Denis 

De :    Martin Rex <[email-masked]>
A :     [email-masked] (Peter Sylvester)
Cc :    [email-masked]
Date :  30/06/2011 19:46
Objet : [pkix] rfc3161 TimeStamps and sha1-based sigs/imprints in 
pkcs7/cms
Envoyé par :    [email-masked]

Peter Sylvester wrote:
> 
> We are sorry for them. This URL has been deprecated
> since years,  a good one can be found reading
> 
>      http://timestamping.edelweb.fr
> 
> Thanks for your attention and sorry for the inconvenience
> of this message for those who are not interested in timestamping

Speaking of rfc3161 timestamping, most public services seem to
be limited to sha1WithRsaEncryption { 1, 2, 840, 113549, 1, 1, 5 }
which looks like an anachronism and a security problem to me.

Are the proposals or is there a standard how to migrate to
a more resonable signature algorithm such as
sha256WithRsaEncryption { 1, 2, 840, 113549, 1, 1, 11 }

e.g. when the MessageImprint uses SHA256?

While requesting this feature explicitly through a specific
TSA policy OID would theoretically be possible, this very
same approach would be quite non-portable.

The original plan was to _have_completed_ phasing out the use of SHA-1
for digital signatures by the end of 2010, but that target seems to
have been missed entirely.  There is a significant availability of
RSA 2048-bit certificates, but the use of sha256WithRsaEncryption
is still at homeopathic levels.

The purpose of rfc3161 timestamps is to prove that something existed
before or at a certain time, and the two most common uses I can
think of are:

    - determine whether a digital signature was created within
      the validity period of the signer certificate

    - determine whether a digital signature was created before
      the point in time when the signer certificate was revoked

Both these cases, a purposes looking into the future, sometimes
far into the future (think e.g. about signed&timestamped code),
and I seriously question the security of timestamps with
sha1-based signatures (or sha1-based message imprints or the
original, often indirect signatures on the underlying pkcs7/CMS)
for purposes with a useful lifetime of many years into the future.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Sat, 2 Jul 2011 02:19:18 +0200 (MEST)

> You seriously question the security of timestamps with sha1-based

Yes.  ;-)

I believe one of the things I'm looking for is sometimes referred
to as "Hash Agility"-- here for rfc3161 TimeStamps, and as a result
interop of such agility between independent implementations
(rfc3161 TSA/Servers and rfc3161 TS-requesting clients).

The information from Rob about the rfc3161 support in Win7
was quite useful -- I didn't know about that  -- thanks, Rob.

I would have assumed that rfc3161 usage scenarios created/shipped
in recent years or that are being planned would require the use of
SHA-2 or better hashes algorithms for message digest purposes
(i.e. the MessageDigest of the timestamped PKCS7/CMS SignedData, the
 MessageDigest of the TimeStampToken SignedData and the HashAlgorithm
 of the MessageImprint within TSTInfo.) or that they would have a
migration plan for switching to SHA-2 or better.

(Timestamped) digital signatures on code should IMHO anticipate useful
validation lifetimes of >10 years.  If there is reason to worry about
the security of SHA-1 for digital signatures, it applies much more to
digital signatures on code, which is expected to still validate OK
in 10 years, than to X.509 certs for online authentication
with a validity of one year.

Also, if you're upping the keylength of your assymetric crypto
(like RSA-1024 -> RSA-2048) it seems awkward to continue using SHA-1
because of the resulting crypto-imbalance.  You take an 8x performance hit
for RSA-2048 over RSA-1024 on RSA crypto operations, but your effective
security level remains unchanged at 80-bit comparable symmetric crypto
strength if you continue to use SHA-1.  That make a move from RSA-1024
to RSA-2048 but no SHA-2 a marketing stunt / security theater that
wastes significant computing resources (on the RSA crypto operations)
for no real security benefit.

Admittedly, it is not clear that SHA-1 is the weakest spot in the
security of the entire system, e.g. http://xkcd.com/538/
but the performance hit when moving from RSA-1024 to RSA-2048 might
be significant enough to deserve considerations of the real benefits/ROI
of an imbalanced crypto algorithm move.

>
> Formats have been described on how to address this issue in general,
> i.e. when the hash function becomes weak.
> 
> the AdES-A format as defined by ETSI for CAdES and XAdES.
> 
> because the hash function becomes weak, but because the validity period
> of the TSU certificate is over.

There is a difference between signed+timestamped stuff that I archive
myself and intend to keep as proof (against others) that I can eventually
show as evidence, and signed+timestamped stuff that I want to use to
reassure myself that it is still what I originally recived (or what
the signer originally signed), like signed code / software distributions.

These might be hardware device drivers on installation media accompanying
the hardware or distributed as software updates over the internet, but
also application software (not all software is as "exposed" and as
bugridden as some active content browser-plugin that needs to be
newly redistributed in its entirety once per week).

> the certificate of the previous time-stamp was not revoked with the
> revocation reason "key compromise".

Different to Qualified/Advanded Electronic Signatures where a lot
of constraints are non-technical and subject to legislative regulation,
Software distributors usually have the option to use longer validity
for their TSA cert and they can redistribute newly signed&timestamped
code as an alternative to recursively timestamp old software packages.

For software distribution, the motivation for timestamping is more
likely finer grained damage control, when having to revoke a signing
cert that got compromised.  

-Martin