Following a problem report sent to the CPS-specified address, evidence of key compromise for a private key used in a certificate issued by GoDaddy has not been revoked within the 24 hour timeframe required by the Baseline Requirements s4.9.1.1.
Whilst GoDaddy did provide a response within 24 hours, I do not believe it meets the spirit of the requirement to provide a "preliminary report", as per BRs s4.9.5. A detailed timeline of communications, as well as my specific concerns about GoDaddy's response, are given below. 2020-03-08 02:47:54Z Problem report sent: -----8<----- Date: Sun, 8 Mar 2020 13:47:54 +1100 From: Matt Palmer <mpal...@hezmatt.org> To: practi...@starfieldtech.com Subject: Problem Report for certificate(s) with compromised private key One or more certificates issued by your CA are using a private key which has been publicly disclosed. The list of affected certificates can be retrieved from https://crt.sh/?spkisha256=c7701317f3cdab8d47ae581dc9e92ac249e9cea65765a4e4ef1100246d003f16 Included below is a CSR, signed by the compromised private key, demonstrating proof of possession: -----BEGIN CERTIFICATE REQUEST----- MIIC0TCCAbkCAQAwgYsxaTBnBgNVBAMMYFRoZSBrZXkgdGhhdCBzaWduZWQgdGhp cyBDU1IgaGFzIGJlZW4gcHVibGljbHkgZGlzY2xvc2VkLiBJdCBzaG91bGQgbm90 IGJlIHVzZWQgZm9yIGFueSBwdXJwb3NlLjEeMBwGA1UECgwVaHR0cHM6Ly9wd25l ZGtleXMuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAmIykJVXM hnFnYQjuDD3uQw2DU7x4taco5sV0s5yzhVWoEOuBRjikAfXU0umzYv1mx80SzXy8 092U9E0noLVtRbZS1Z53WJonUcvtxyqYt1syCM2OuUEYwXoSMmBIK11YZSaBK91/ HECnJbJ5gAqddUUNcsVcKj9LZOEwiwQnVan42FCqLYJT6w9t2rbcMPJyajRCHaHI do0KkzWY1cg4oc4S21/7sszVz4IFLMNvT5NoJ768D6atkqTVduMsOPEaourni8kl 4ANE3dCkyYh24/Y0tbrB6Vo2lTTVOUpYEfMPDgkaVMtEPtU03SfmfqZrJMp2KwmG G4rgFne6SZ1yMQIDAQABoAAwDQYJKoZIhvcNAQELBQADggEBADTZKcOXd6cf/Zs/ keZv8hoTPalYsIjfBlsDyhkdzIRXlBhow+bJQxgA1X49E1qxht7YAuKuzJqH/1KE 18S7+e4krWSh6Thp9bv8UrRWVCyGGoXe0DQrmVQuA9jb32i0S8SioyQ/rrnQZM5L gb0sFb+keHxOYFK7vaK+Iq0GTVOLq2M0dOzvsvzw1u1BfXLxXI9UryxDkKb6I9uy QWfigG50G7CifguPyxeRnK4Js/8cAzXREJF1D9UUDj6rByEWSxEEnc9NyAqOmjsS 1Q8DxrSK6uMOPy3icngD+Ykq6PIWKeXe0eTme0W7feGjrsmVZChhvrbFjkPaFmrZ 83FAPKc= -----END CERTIFICATE REQUEST----- Please revoke all affected certificates within 24 hours, as per the Baseline Requirements. - Matt ----->8----- 2020-03-08 02:48:01Z E-mail is accepted by remote mail server: -----8<----- Mar 8 02:48:01 minotaur postfix/smtp[2204]: 9D7421859AB: to=<practi...@starfieldtech.com>, relay=smtp.secureserver.net[68.178.213.37]:25, delay=3.2, delays=0.45/0.01/1.4/1.3, dsn=2.0.0, status=sent (250 2.0.0 Alyxjg6mq8nXu - Alyxjg6mq8nXuAlyyjakiR mail accepted for delivery) ----->8----- 2020-03-08 02:48:42Z Auto-ack response from donore...@secureserver.net, whose substantive content, once the HTML gak has been filed off, is as follows: -----8<----- Your inquiry has been received. You should expect a response within 72 hours. This is your Incident ID: 41360505 If you wish to speak with a customer service representative, call +1 (480) 505-8825 and reference the Incident ID above. Thanks, Customer Service ----->8----- 2020-03-08 22:33:51Z Followup e-mail received from donotre...@secureserver.net: -----8<----- We have received a certificate problem report for tell.gao.gov and are required to investigate the facts and circumstances related to this problem report. Contingent on our findings, the affected certificate(s) may require revocation within a strict timeline of 24 hours or up to 5 days, depending upon severity. Consequently, the current certificate(s) will cease to function immediately upon revocation. Our findings regarding this problem report conclude that we are unable to proceed with a revocation as the provided CSR is not conclusive. We are able to duplicate this CSR without having access to the private key. At this time, we are requesting additional information from you in the form of either Option A or Option B below. Please respond within 24 hours to ensure timely resolution. Option A: Send us the private key in PEM format. Option B: Run the command below and send us the output. Please replace PRIVATEKEY-FILE with the path to the compromised private key. Please be sure to use the exact same string so we can verify accordingly. openssl dgst -sha256 -sign PRIVATEKEY-FILE <(echo -n 'compromised') openssl enc -base64 [my original e-mail, with formatting mangled, elided] If you need to follow up, please reference incident ID 41360505 when you contact our support team at +1 (480) 505-8825. Please do not reply to this email. Emails sent to this address will not be answered. ----->8----- At of the time of writing, which is approximately 25-1/2 hours after the initial problem report was sent, https://crt.sh/?id=1166030780&opt=ocsp shows the certificate as having not been revoked. I have three concerns about the nature of the GoDaddy response to this problem report: 1. The CSR I provided in the original report is functionally identical to the signature that is being requested, except it is stronger because a CSR contains a signature over the public key which is compromised, rather than just being a signature over a single very short, generic string. It most certainly can be validated using openssl. 2. Even if I hadn't provided verifiable proof of compromise initially, the command which was provided by GoDaddy support does not actually work. Providing plausible but ineffective methods of providing evidence of key compromise would hypothetically be a fantastic way to drag out the revocation process, were any CA willing to engage in such shenanigans. (In case anyone's wondering, I checked *very* carefully that the command I have pasted from the response above is exactly what is rendered in my browser). 3. Even if I were to fix the command provided, there is no practical way to provide the information requested to GoDaddy. The e-mail was sent from `donotre...@secureserver.net`, and the body of the e-mail specifically states that I should not reply. The only approved method of response is to call a US phone number. Making an international phone call to read out a string of base64 characters does not strike me as an appropriate means of providing evidence of key compromise. I would appreciate a response from GoDaddy regarding this failure to abide by the BRs, if one is considered warranted by the CA Policy module owner and/or peers. - Matt _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
