CAcert System Admins discussion list

[Guillaume ROMAGNY <guillaume AT cacert.org>]

Hello,


I would follow Wytze and Dirk point of view.


Best regards,


Guillaume


Le 14/02/2011 13:00, dirk astrath a écrit :

> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 hiya,
>
> since every change has something to do with software, i asked ulrich
> to put this on the agenda for our weekly software-telephone-meeting
> (tuesday 21:00 UTC).
>
> our plan is NOT to work out a solution but to find out, which changes,
> tests etc. have to be done ...
>
> to be done, if we want to install completely new roots, resign class
> 1, recreate class 3, stop issuing class 3, ... ....
>
> this should make the decision for the next board easier, because the
> effort, circumstances etc. will then be available ...
>
> have a nice day
>
>
>
>
> Ian G 
> <iang AT cacert.org>
>  schrieb:
>
>     On 14/02/11 10:19 PM, Wytze van der Raay wrote:
>     > On 13.02.2011 00:51, Nick Bebout wrote:
>     >> Mozilla has announced that they will disable the use of MD5 as
>     a hash
>     >> algorithm in all of their products on June 30, 2011. Our class 3
>     >> intermediate root uses MD5, thus I believe we should stop issuing
>     >> certificates off of that root as soon as possible. I have filed the
>     >> following motion.
>     >>
>     >> Nick
>     >>
>     >> m20110212.1
>     >> Discontinue issuing certificates from Class 3 root
>     >>
>     >> RESOLVED, that effective as of the date of the close of this
>     vote (or as
>     >> soon as this change may be implemented), CAcert shall no longer
>     issue
>     >> certificates from the Class 3 root.
>     >>
>     >> Background information:
>     >>
>     >> Our Class 3 root uses MD5 as a hash algorithm.
>     >>
>     >> June 30, 2011 – Mozilla will stop accepting MD5 as a hash
>     algorithm for
>     >> intermediate and end-entity certificates. After this date software
>     >> published by Mozilla will return an error when a certificate
>     with an
>     >> MD5-based signature is used.
>     >>
>     >>
>     >> Due: 2011-02-19 23:59:59 UTC
>     >
>     >
>     > This seems a rather over-drastic step to me. With similar
>     arguments you
>     > might as well decide to stop issuing all CAcert certificates :-(
>
>     Yes.
>
>     > Someone please correct me if I'm wrong, but isn't it possible to
>     simply
>     > recreate the published Class 3 root certificate with a SHA1
>     digest rather
>     > than an MD5 digest? The public and private keys don't change
>     under that
>     > transformation, so all issued certs (and new issued certs) can
>     still be
>     > validated properly. We only need to urge people to replace the old
>     > MD5-signed root cert by the new SHA1-signed one in their
>     browsers, e-mail
>     > clients, or web servers. That would seem a much more positive
>     strategy
>     > to me than simply discontinuing issuing certs.
>
>
>     My understanding is that re-signing is not possible under PKI.
>     It's not the crypto, but complicated things inside the x.509 rules
>     that are invoked by browsers (etc) to reject stuff that looks odd.
>
>     In practice, the better measure would be to make a new class 3
>     subroot entirely.
>
>     I suppose the occam's razor on this is that if this were done such
>     that we were all agreed that the result was a short term issue,
>     and therefore the roots remained "fail" then ... go ahead.
>
>     Another possibility would be to re-self-sign the current top root
>     using
>     SHA1. Or SHA256? It matters not if that one changes because one
>     either uses the old root or the "new-old" root? And then roll a
>     new subroot signed by the "new-old" root?
>
>     Either way .. it would be good to test this with multiple
>     browsers, etc to make sure that they didn't reject it in strange ways?
>
>     (I'm just whiteboarding here, not really thinking it through...)
>
>     iang
>
> -----BEGIN PGP SIGNATURE----- Version: APG v1.0.8
> iQFJBAEBCAAzBQJNWRk9LBxkaXJrIGFzdHJhdGggKG1vYmlsZSBrZXkpIDxkYXN0
> cmF0aEBnbXguZGU+AAoJEGfncvCDUeCvI1EH/1ctAS7rd2OdM/i27cg6FmabKcKn
> Ylg2WFX4Yr2katk74yKn2GbiJAPA71jDPhWUzl4IBJyniakjXby1wTSYb5yrKXqW
> kggnG6AvDQq88y6r1XNOFbAZVb89v+Bhxka/cUls/cf3Z0k6oL8e0g5eZZvs+DcR
> H5DukLS39W+TGMUAKqc0qBkC1oyCTBMWw7O42Zw52NEJEfL7Vsq3IwmUMFZjNh3f
> HkRCRYwD8nbGU6uvWX+d9+c5svQTUhdp25M8aHISH32xS6FFTozMaFo0AYyuZ/8o
> UuG+Vcp3xxa4hNPMP3y2MmXdy1Wi+zvHPTBAtYUUaaMHgR8330TKwyw6i9o= =4/j4
> -----END PGP SIGNATURE-----

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature