<keygen> & "md5WithRSAEncryption" about html HOT 10 CLOSED

MD5 is not the sole reason it's considered for removal. It's considered for removal because Edge doesn't implement it, and Chrome and Mozilla are planning to unship it as well. I don't see a reason to spawn yet another thread discussing <keygen> so I'm closing this. Please stop spawning threads.

from html.

But you have to look at the reasons given by certain people in the browser space for removing it were security reasons. You can see the pretty vague argument given by Ryan Sleevi on the blink mailing list on the 31 July 2014. Then during the discussion on the whatwg mailing list Ian Hickson wrote on 3 Sept

The post foolip pointed to points out that is actually rather
insecure (e.g. using MD5). One could argue that keeping is
actually more harmful to asymetric-key cryptography than removing it...

This type of misunderstanding is spreading like smallpox, meaning that for a number of bad reasons an important security piece is being removed.

The wording in the current spec is leading to this misunderstanding. It would do no harm to improve it.

from html.

I created a subthread on this issue on the blink mailing list, entitled MD5 -- Re: (Pre-)Intent to Deprecate: <keygen> element and application/x-x509-*-cert MIME handling. Note: it starts with "MD5". I'll post other threads on the topic in diverse forums here.

from html.

As a proof here is a certificate I created with keygen and the server code above.

$ openssl pkcs12 -clcerts -nokeys -in ~/Certificates.p12  | openssl x509 -text
Enter Import Password:
MAC verified OK
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            01:4c:19:67:ea:05
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: CN=WebID, O={}
        Validity
            Not Before: Mar 14 17:39:42 2015 GMT
            Not After : Mar 13 17:49:42 2019 GMT
        Subject: [email protected]
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (2048 bit)
                Modulus (2048 bit):
                    00:da:b9:d1:e9:41:f6:f8:5a:08:63:16:9d:0d:b6:
                    32:8d:1d:4a:15:a7:1d:ff:e3:d4:f4:d0:87:52:a5:
                    2f:b1:45:4d:73:58:e4:a5:ec:f3:50:1e:39:24:bc:
                    02:52:f3:00:4b:0b:b2:1a:0d:6b:64:ca:05:3f:0f:
                    bc:b5:a5:4e:c9:3e:be:2d:c9:b9:1e:4c:43:2b:82:
                    78:84:c4:cc:2a:d8:a1:02:b4:6d:2a:20:17:bf:45:
                    d9:d4:c8:8a:56:4d:42:02:34:48:4a:1b:2e:44:6d:
                    bb:4c:d4:38:e7:9c:24:66:ce:31:0f:32:77:73:a7:
                    79:d2:4e:d7:b6:0a:05:a6:18:b9:84:75:7b:94:6d:
                    67:ba:79:f2:e0:64:e6:ae:d3:8b:d6:55:9c:e7:fc:
                    95:02:72:08:23:d5:6d:b1:c0:34:09:93:67:d7:db:
                    27:b6:bd:af:da:8c:c4:83:47:13:3f:4a:14:67:5f:
                    67:5f:b4:84:ce:32:df:66:c1:1a:36:38:fa:84:d5:
                    be:69:b1:a6:f2:38:11:5d:ef:9b:0f:79:bb:25:c0:
                    cb:7e:4a:39:45:9a:08:29:b1:fd:35:c0:d1:db:dd:
                    60:f9:c6:79:d8:94:15:ed:7e:a4:1e:b0:2f:bc:01:
                    6f:c0:e7:92:cb:96:98:c9:f4:db:84:2c:da:d5:b5:
                    f5:c9
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Alternative Name: critical
                URI:http://bblfish.net/people/henry/card#me
            X509v3 Key Usage: critical
                Digital Signature, Non Repudiation, Key Encipherment, Key Agreement, Certificate Sign
            X509v3 Basic Constraints: critical
                CA:FALSE
            Netscape Cert Type: 
                SSL Client, S/MIME
    Signature Algorithm: sha1WithRSAEncryption
        03:25:38:47:76:34:ba:da:0b:40:ea:75:63:98:6b:b0:0b:b6:
        11:85:c7:b1:c4:91:cc:5c:99:a5:b5:01:24:6f:1f:8c:03:39:
        80:03:e7:50:59:9f:b0:48:6e:e7:16:b8:b7:92:6f:31:cd:cc:
        ba:60:40:08:9e:3c:38:5d:19:94:fd:2c:be:6d:84:57:d4:ea:
        7f:54:a7:69:73:aa:37:a4:b8:81:21:0c:65:dc:f1:f6:a3:40:
        d1:18:cf:04:a4:d6:8b:9a:1f:43:c2:67:4a:0e:8d:00:b7:e8:
        49:e3:b7:d5:f9:00:0f:98:32:b2:09:5e:ca:c0:44:37:dc:df:
        3b:57:e0:c2:5a:8a:79:0d:55:7a:4a:73:4a:24:64:27:e5:16:
        78:d4:c9:35:5e:f8:67:9c:e9:41:bd:c6:25:6b:1b:d7:03:c1:
        af:64:d0:e3:0a:ea:58:a4:bc:3a:a4:8f:51:8d:33:58:ed:ba:
        af:3d:b7:75:28:32:33:76:65:80:56:ae:ec:43:db:9e:7e:4b:
        74:f5:88:07:9f:2d:e8:74:f1:89:d1:af:52:34:07:52:f3:54:
        2f:60:fd:de:96:f6:00:67:2e:8f:10:23:e6:af:95:bf:a6:3c:
        61:0d:8c:24:47:cf:52:45:0f:96:ee:ca:3a:69:82:69:3b:20:
        87:06:5c:58
-----BEGIN CERTIFICATE-----
MIIDITCCAgmgAwIBAgIGAUwZZ+oFMA0GCSqGSIb3DQEBBQUAMB0xDjAMBgNVBAMM
BVdlYklEMQswCQYDVQQKDAJ7fTAeFw0xNTAzMTQxNzM5NDJaFw0xOTAzMTMxNzQ5
NDJaMBwxGjAYBgNVBC4TEWhlbnJ5QGJibGZpc2gubmV0MIIBIDALBgkqhkiG9w0B
AQEDggEPADCCAQoCggEBANq50elB9vhaCGMWnQ22Mo0dShWnHf/j1PTQh1KlL7FF
TXNY5KXs81AeOSS8AlLzAEsLshoNa2TKBT8PvLWlTsk+vi3JuR5MQyuCeITEzCrY
oQK0bSogF79F2dTIilZNQgI0SEobLkRtu0zUOOecJGbOMQ8yd3OnedJO17YKBaYY
uYR1e5RtZ7p58uBk5q7Ti9ZVnOf8lQJyCCPVbbHANAmTZ9fbJ7a9r9qMxINHEz9K
FGdfZ1+0hM4y32bBGjY4+oTVvmmxpvI4EV3vmw95uyXAy35KOUWaCCmx/TXA0dvd
YPnGediUFe1+pB6wL7wBb8DnksuWmMn024Qs2tW19ckCAwEAAaNqMGgwNQYDVR0R
AQH/BCswKYYnaHR0cDovL2JibGZpc2gubmV0L3Blb3BsZS9oZW5yeS9jYXJkI21l
MA4GA1UdDwEB/wQEAwIC7DAMBgNVHRMBAf8EAjAAMBEGCWCGSAGG+EIBAQQEAwIF
oDANBgkqhkiG9w0BAQUFAAOCAQEAAyU4R3Y0utoLQOp1Y5hrsAu2EYXHscSRzFyZ
pbUBJG8fjAM5gAPnUFmfsEhu5xa4t5JvMc3MumBACJ48OF0ZlP0svm2EV9Tqf1Sn
aXOqN6S4gSEMZdzx9qNA0RjPBKTWi5ofQ8JnSg6NALfoSeO31fkAD5gysgleysBE
N9zfO1fgwlqKeQ1VekpzSiRkJ+UWeNTJNV74Z5zpQb3GJWsb1wPBr2TQ4wrqWKS8
OqSPUY0zWO26rz23dSgyM3ZlgFau7EPbnn5LdPWIB58t6HTxidGvUjQHUvNUL2D9
3pb2AGcujxAj5q+Vv6Y8YQ2MJEfPUkUPlu7KOmmCaTsghwZcWA==
-----END CERTIFICATE-----

There is no MD5 in the certificate, as you can see it is signed with sha1WithRSAEncryption as expected. Note that if you look at this in User Friendly UIs such as OSX keychain they may show you the MD5 hash for convenience. That hash is not in the certificate, it is just calcuated by the viewer after the fact.

Btw. I am told that the server code can be improved by using sha2 instead of sha1 for signature.

from html.

@annevk Where is the correct thread to discuss this?

from html.

#67, if you have new information.

from html.

#67 was closed without providing a reason.

from html.

That is inaccurate.

from html.

@annevk The reason provided was

Closing this issue, since now there is an issue, namely this issue.

That does not look like a reason.

from html.

(The above explanation is not precise enough, and the code can be improved.)

The spkac clearly signs the generated public key + challenge with the private key using the MD5 signature ( as one can see from the BouncyCastle API). The server is then meant to verify the signature and that it matches the challenge, as a way of verifying that the agent that sent the public key is actually the agent connected in the session. I suppose this is to avoid the server signing certificates for clients presenting random public keys. Of course the client would not be able to do anything with the generated certificate, given we assume that it does not have the private key (otherwise it would just proceed as normal). So this signature and challenge can be seen as an extra security feature.

This assumes that between the creation of the form and the challenge ( which should of course contain a very random string as possible, include a date and be tied to the user session - perhaps even the TLS session) , and the receipt of the form and the public key someone would be able to find a public key for which they did not have the private key, find an MD5 hash collision for that given challenge, and send that to the certificate service. Let's stop here for a second.

(So I admit that I have not been using this verification in my code - which has not been required for anything at this high level of security, but it will be nice to be able to add it. )

Let us note the complexity of the attack:

1. for the MD5 breakage ago demonstrated 7 years ago by Jacob Appelbaum et al., they had to spend 3 days to create the challenge (ok computers are faster now of course )
2. there is a lot more information in a X509 cert than in an spkac so that MD5 clashes are presumably much more difficult to generate in spkac
3. plus they were dealing with a certificate authority that would create server certificates with identity numbers that were sequential, so completely predictable ( hence the answer that by randomising the string this would be difficult to duplicate )

All the above is very very hard.

Let us now think of the result of this attack:

The attackers would end up receiving an X509 certificate signed with SHA2, which is recommended now I am told. But they would not have a private key for the given public key ( for if they did have the private key, none of the above attack would of course be necessary ).

This is the opposite of the attack demonstrated by Applebaum, where the whole game was to start off with a public key for which they had the private key, in order then to get the CA to generate a certificate signed with MD5, and then be able to generate another certificate with the same signature that put them in control of a root certificate!

Here the attacker ends up with a secure certificate which he cannot break as it uses SHA2 and for which he does not have the private key!

Still the CA may want to make sure the agent does have the private key and is not sending some random public key along. But

• The above reasoning shows that the MD5 and a good challenge ought to be amply sufficient at this moment still
• It is really quite unbelievable that it is hard to improve the keygen tag to add an option to make it SHA2 enabled and that this would break backward compatibility. A <keygen keytype="rsa" signature="sha1 sha2"> would be one simple suggestion for an evolutionary path forward. The server that produced this html would of course be able to process sha1 and sha2 signatures.

from html.