>> I think Matt provided a pretty clear moral hazard here - of customers >> suggesting their CAs didn't do enough (e.g. should have tried harder to >> intentionally violated by not revoking). One significant way to mitigating >> that risk is to take meaningful steps to ensure that "We couldn't revoke" is >> not really a viable or defensible option.
Oh – thanks. I missed that. A lack of knowledge is already not a defensible position. Revocation requirements and an agreement to revoke within 24 hours is in all our of existing DigiCert contracts. The same language is going into all Symantec customer contracts now as customers transition to DigiCert systems. All of our documentation, including the CPS, say we can revoke with less than 1 day notice. >From section 4.9.1 of our CPS: DigiCert will revoke a Certificate within 24 hours if one or more of the following occurs: 1. The Subscriber requests in writing that DigiCert revoke the Certificate; 2. The Subscriber notifies DigiCert that the original Certificate request was not authorized and does not retroactively grant authorization; 3.DigiCert obtains evidence that the Subscriber’s Private Key corresponding to the Public Key in the Certificate suffered aKey Compromise; or 4. DigiCert obtains evidence that the validation of domain authorization or control for any FDQN or IP address in the Certificate should not be relied upon. DigiCert may revoke a certificate within 24 hours and will revoke a Certificate within 5 days if one or more of the following occurs: 1. The Certificate no longer complies with the requirements of Sections 6.1.5 and 6.1.6 of the CA/B forum baseline requirements; 2. DigiCert obtains evidence that the Certificate was misused; 3.The Subscriber or the cross‐certified CA breached a material obligation under the CP, this CPS, or the relevant agreement; 4. DigiCert confirms any circumstance indicating that use of a FQDN or IP address in the Certificate is no longer legally permitted (e.g. a court or arbitrator has revoked a Domain Name registrant’s right to use the Domain Name, a relevant licensing or services agreement between the Domain Name registrant and the Applicant has terminated, or the Domain Name registrant has failed to renew the Domain Name); 5. DigiCert confirms that a Wildcard Certificate has been used to authenticate a fraudulently misleading subordinate FQDN; 6. DigiCert confirms a material change in the information contained in the Certificate; 7. DigiCert confirms that the Certificate was not issued in accordance with the CA/B forum requirements or the DigiCert CP or this CPS; 8. DigiCert determines or confirms that any of the information appearing in the Certificate is inaccurate; 9. DigiCert’s right to issue Certificates under the CA/B forum requirements expires or is revoked or terminated, unless DigiCert has made arrangements to continue maintaining the CRL/OCSP Repository; …. This is why I couch it as we can revoke technically and legally, but I don’t think we should. >> This doesn't really inspire confidence. If the answer for how to deal with >> this is block efforts to remediate issues, then it runs all the risk that >> Matt was speaking to. "We knew people couldn't replace in January" is a >> problem, for sure, but because fundamentally the risk is always there that >> someone would need to revoke in January - or December, or November, or >> whenever the sensitive holiday freeze or critical sales or lunar alignment >> or personal vacation is - it's not really a mitigation at all for the issue. >> I tried to give suggestions earlier for meaningful steps - such as making >> sure all customers know that certificates may need to be revoked as soon as >> 24 hours. This has been a pattern of challenge in the past for DigiCert if I >> recall correctly - I believe both Blizzard and GitHub had issues where the >> keys were compromised, but these organizations didn't want to revoke the >> certs until they could ship new private keys in their software (... ignoring >> all the issues in that one). I know you've said you've got the contracts in >> place to defensibly revoke these, but how are you helping your users >> understand these risks? Do you have documentation on this? Do you recommend >> users use automation? I know some of this speaks to business practice, but I >> think that's somewhat core to the issue - since revocation may be required, >> how is the CA, the party best placed to communicate to the customer, >> communicating that necessity? Sorry – I thought you meant in addition to those things. All customers know we can revoke within 24 hours. Note that in both those cases the GitHub case we did revoke the cert within 24 hours of notification. We have documentation on revocation (eg https://www.digicert.com/certificate-revocation.htm) and talk about it a lot. We also recommend automation. We had our own automation tools before ACME came along. We were implementing ACME until we got distracted with the migration. It’s back on track and should be supported in DigiCert systems soon. We won’t be integrating it with legacy Symantec systems as those are being EoL’ed. >> As Matt spoke to it somewhat, there's understandably competitive advantage >> to being the CA that will try their hardest not to revoke. And while I don't >> think this has risen to that level based on the information provided so far, >> understanding how that perception is being mitigated is key. There are other >> solutions, to be sure. Helping users move from publicly trusted CAs to >> managed CAs, for example, can still meet the business needs of these users >> w/o the attendant revocation risk. There probably is. As you pointed out, a lot of the issues are mixing of PKIs. We’re going to better separate out web PKI vs. OS PKI going forward. I’m working on some internal proposals on that. We do provided managed PKI already. This managed PKI uses the same tools and similar automation tools as our publicly trusted certificates at a fraction of the cost. They are available alongside each other in enterprise accounts to encourage people to use non-public certs where appropriate. >> Things like Heartbleed have shown that rapid revocation can be necessary. >> Misissuance or misvalidation by the CA that results in revocation surely can >> as well. Understandably, an answer of "Don't ever misissue" is great, but if >> it's really pinning all the hopes on one thing. Other CAs have taken steps >> like ensuring automation and short-lived certs as a way of ensuring that the >> upper-bound of any issue is limited (for example, to 90 days, or six >> months), and that automation is the default way of getting certs. We support both of those things. Unfortunately the automation isn’t using ACME quite yet. >> So, concrete suggestions then, since it sounds like you're asking for that. Yes thanks! >> 1) Communication to all your customers about the industry-standard >> revocation requirements Easier said than done, but I’ll brain storm something. I mean, we have communicated this to all customers previously but whether that communication is received is a different question. >> 2) Clear promotion, documentation, and tools for automation This will be easier shortly >> 3) Clear and published policies about the critical nature of certificates >> and how they should be regarded Okay – we’ll work on this. I think we have some documentation already, but it’s probably a good idea to link it in our agreements. We do reference the BRs and Mozilla policy in each agreement so I know those are distributed to every customer. >> None of these are necessarily unique to DigiCert - #2 gets close, but there >> are options. When your customer comes to you and says "We have a holiday >> freeze", doesn't it seem better placed to say "Look, beyond just signing a >> subscriber agreement, we sent messages on dates X, Y, and Z around the >> industry standard practices around revocation. We also provided solutions A, >> B, and C, which were all declined by your team." No one ever says this until you revoke their certs. Before this, we had a vague awareness of holiday freezes from past discussions here (particularly with Symantec issues). However, I didn’t know first-hand until this event what they really entailed. >> I know that sounds like "shifting blame", but since you're absolutely >> correct that you can't prevent your customers from engaging in risky >> behaviours, the best you can do is to make sure that it's clear to them that >> it is risky, it is unsupported, and it's not DigiCert being mean, but >> industry standard. There's an opportunity to take this incident and make >> sure no DigiCert customer ever experiences this issue again - or those of >> any other CA. Sounds good. Thanks a ton for the suggestions. >> That's I think one way to mitigate the moral hazard Matt speaks to. When the >> next customer of the next CA comes and says "Look, you need to try to get us >> an exception" - the CA knows that if they didn't do all of those steps, they >> really didn't take any of (these) lessons to heart, and it's not really >> defensible. And, if they did take those steps, then hasn't the expectation >> been shifted to the customer - and the risk - thus making it easier for the >> CA to defensibly say "You did this to yourself?" Yeah. This is exactly what I was looking for. I like this because it gives clear guidance on what’s expected beforehand. What do you need to do before taking a potential issue to the Mozilla community? >> I can't speak for Mozilla here, but I tried to lay out some clear >> expectations: Definitely helpful. Thank you!
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
