1 Jul 2011 06:22
Re: rfc3161 TimeStamps and sha1-based sigs/imprints in pkcs7/cms
Peter Sylvester <peter.sylvester <at> edelweb.fr>
2011-07-01 04:22:29 GMT
2011-07-01 04:22:29 GMT
signing/finishing a contract on paper and leaving it near/in a cloud ? you don't do that in the paperworld. On 06/30/2011 07:46 PM, Martin Rex wrote: > 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(Continue reading)
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. 
RSS Feed