Re: CA Communication: Underscores in dNSNames
On Fri, Dec 07, 2018 at 08:13:24AM -0800, pilgrim2223--- via dev-security-policy wrote: > As a retail organization we are in a moratorium till 1/2/2019 this happens > every year. So nothing is being done that may jeopardize selling of > widgets! Choosing to not do something is, itself, doing something. > The project owners claim that timeline is impossible, and deploying 30 day > validity certs is a similar level of effort without the code changes, and > even that may not be possible. By a strict reading of the BRs, these missued certificates should have been revoked within, at most, five days. If future problems are identified, that may happen. So I suggest you talk to your project owners, apprise them of the situation, and take steps to allow your systems to be able to react in line with this potential timeline. > To be perfectly clear here. We are 100% on board with a depreciation of > the underscore (once we learned there was and issue with them from our CA > we started restricting their issuance) This is not a change in the rules (the BRs have always forbidden this type of issuance), nor is it even a change in external circumstance (new research results showing something that was thought to be safe wasn't). Your CA sold you something they shouldn't have, and which they should have known they shouldn't have. If you're unhappy with what your CA sold you, I would recommend discussing the problem with them, perhaps with the assistance of your legal team. > now, and does not pose a security vulnerability. I assume you've got something to back up that statement, beyond "I can't think of any way this could be a security vulnerability". There are more implementations in heaven and earth than are dreamt of in your philosophy, and all that. - Matt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: [FORGED] Re: [FORGED] Re: Incident report - Misissuance of CISCO VPN server certificates by Microsec
Paul Wouters via dev-security-policy writes: >I'm not sure how that is helpful for those crypto libraries who mistakenly >believe a certificate is a TLS certificate and thus if the EKU is not empty >it should have serverAuth or clientAuth. Sure, it wouldn't help with current libraries that neither acknowledge non-TLS use nor know about the tlsCompabitility EKU, but it would act as a signalling mechanism going forward to inform RP's about what's going on. So if you get notified about an apparently-wrong cert you can see the tlsCompabitility EKU and realise what's going on. Peter. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: CA Communication: Underscores in dNSNames
Fair enough Impact is this: As a retail organization we are in a moratorium till 1/2/2019 this happens every year. So nothing is being done that may jeopardize selling of widgets! A process was put in place for 2wayssl where we'd name the cert based on what it does (so 2wayssl_to_from.domain.com) which we would then use for our own and partner vendor applications. the scope of the main project if ~120 certs across a similar number of vendors. One of the home grown applications also hardcode the name of the certificate into the application and will require not only certificate update in coordination with the vendors but code changes on 120 certs in 12 days. The project owners claim that timeline is impossible, and deploying 30 day validity certs is a similar level of effort without the code changes, and even that may not be possible. This particular application is how we link with our partners for activation and generates ~2b per year in revenue. To be perfectly clear here. We are 100% on board with a depreciation of the underscore (once we learned there was and issue with them from our CA we started restricting their issuance) The issue is I tell application owners this needs to be done, they want to know why they aren't even getting the 90 days they'd get if these were depreciated less aggressively (same they had for SHA1) for something that has not been a problem till now, and does not pose a security vulnerability. As it sits from CA alerting us to the final outcome we got 44 days, 31 of which are over a holiday moratorium. So for full scope: 260 certs out of compliance in my enterprise (out of ~17,000 current valid certs) Of those 120 are problematic to replace in time, but could easily be done by the end of Q1 If I could get browser blessing to give us at least Q1 to finish this it would make the entire world a much better place for me :) On Friday, December 7, 2018 at 8:39:15 AM UTC-7, Jeremy Rowley wrote: > Personally, i think you should continue the discussion here. Although you can > bring it up to whichever ca you use, the reality is that without the browsers > knowing why the certs cant be replaced and the number, theres no way to gauge > their reaction to a non compliance. The penalties may include root removal > (see symantec) so I doubt many cas would be willing to risk a qualification > without clear guidance from the browsers on the risk associated with the non > compliance. > > From: dev-security-policy on > behalf of pilgrim2223--- via dev-security-policy > > Sent: Friday, December 7, 2018 8:26:42 AM > To: mozilla-dev-security-pol...@lists.mozilla.org > Subject: Re: CA Communication: Underscores in dNSNames > > Thank you very much for your response! > > So at the end of the day I will not get any relief from the browsers, and > will need to get an exception from my CA? > > When I asked the CA they told me to take it here. Feels like the CA is where > I'm going to have to focus! > > Thanks again for your time! > > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://clicktime.symantec.com/a/1/nN3YNjTD37Z9bk8efCYXsWHpyw8ViK61Q8Dz1AzUtno=?d=cQ4KQMo02NQvJ7GQxkZHfn9YbOkOTiGLFwgAhzovU-ksifF97AFzeTEl3fKU1c4flMJM5MQa4SYfNOuCB5-Y29jyEtL2_9KBxlVmHB_-8X_yPT3Gd1KBASJgcwXjKaIjjc7h8rFYLmo4FmmjdQDJfQcxl_q00tAfBZTdTqkwLD4b__i1PLIwekimsAKnCEc7M1LQPr1uSNB-FjHnEcF14WbG_18ILSXzHM34tK_cdKnINlfFOEvMSGXK7LVBeRjiRGTuodckiUppT5eIbtRZNKo6R8hoXcUzy-yTZ21EbW651pPGEqEwRb1Qpu9J0tLL6DExVNq6euprfMtWQTwjpQGvzkg5KO26pXSnafFpMBxblo_G0EcAZEMPzGWZrQxxtD8_wSHTTO7-9MbzrQGF8qAWuuFbGW-M220s2HRhgU8qz_qZtto%3D=https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: [FORGED] Re: Incident report - Misissuance of CISCO VPN server certificates by Microsec
2018. december 6., csütörtök 23:31:42 UTC+1 időpontban Peter Gutmann a
következőt írta:
>
> So just to make sure I've got this right, implementations are needing to add
> dummy TLS EKUs to non-TLS certs in order for them to "work"? In that case why
> not add a signalling EKU or policy value, a bit like Microsoft's
> systemHealthLoophole EKU (I don't know what its official name is, 1 3 6 1 4 1
> 311 47 1 3) where the normal systemHealth key usage is meant to indicate
> compliance with a system or corporate security policy and the
> systemHealthLoophole key usage is for systems that don't comply with the
> policy but that need a systemHealth certificate anyway.
>
> In theory there's the anyExtendedKeyUsage that seems to do something like
> this:
>
>If a CA includes extended key usages to satisfy such applications,
>but does not wish to restrict usages of the key, the CA can include
>the special KeyPurposeId anyExtendedKeyUsage in addition to the
>particular key purposes required by the applications.
>
> but thats vague enough, and little-supported enough, that expecting existing
> implementations to handle it correctly out of the box seems pretty risky.
> Better to define a new EKU, "tlsCompabitility", telling the relying party that
> the TLS EKUs are present for compatibility purposes and can be ignored if it's
> a non-TLS use.
>
> Peter.
Absolutely agree.
The main reason to use EKU values is to define the targeted usage of the
certificate and the belonging keys. The EKU should be clear enough for the
software vendors to be able to select the proper certificate for their
application. The good separation and detailed requirement specification would
help the CAs to issue proper certificates.
If the present EKUs are not enough to fulfil this requirement a possible
solution can be to define further EKU values as you have proposed.
The alternative solution can be the way which was introduced by the European
regulation in the ETSI EN 319 412-5 which defines QCStatements for the
certificate profiles.
They are mandatory in the EU qualified certificates but can be used optionally
in other certificates too.
The existing proper QCStatement for the website authentication (TLS)
certificates is:
0.4.0.1862.1.6.3
id-etsi-qct-web OBJECT IDENTIFIER ::= { id-etsi-qcs-QcType 3 }
-- Certificate for website authentication as defined in Regulation (EU) No
910/2014
I have just asked the registration of this OID in the OID Repository at
oid-info.com
Sándor
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
Re: CA Communication: Underscores in dNSNames
On Fri, Dec 7, 2018 at 4:35 PM Jeremy Rowley wrote: > I only ask because telling people to go back to the CA and work something > out isn’t a great answer when the retort is that the CA will be distrusted > if they don’t. Either the customer doesn’t replace all their certs and they > are made non-functional by revocation or the certs are distrusted because > the CA isn’t operational anymore. Telling people to go have the CA cover > the risk when those are the two options seems like we’re avoiding the > public discussion. > Why not? It's fundamentally the CA taking the risk on when deciding whether or not to meet the requirements of the programs that they participate in - whether technical, policy, or contractual. If a customer wanted to ask a CA to break a contractual requirement, isn't it ultimately the CA they should be asking? I think we're in agreement that, regardless, the CA MUST receive a qualified audit. There's seemingly no defense that if they fail to revoke, it should be a qualification, and there's even an argument that the issuance itself should have been a qualification (and result in their auditor re-evaluating these material facts, such as under AT-C 205.A54-A57 regarding revisions to opinions in light of subsequent events and application guidance). It's unclear what you expect to result from a public discussion, so perhaps it would be helpful if you could clarify. It sounds like you're looking for a blanket rubric for which to ignore the requirements of the Baseline Requirements, so that the rubric can then be applied customer requests, and determine whether or not these individual customers justify violating the BRs. A good CA would acknowledge the rubric is, in fact, zero - zero violations is the "justified" case, and everything else is the risk case. Alternatively, it may be a desire that a rubric should exist, a priori to any violations, so as to help determine whether a violation is justified, even when the stated goal is zero violations. If you look at public discussions, think about what the goals are of the Incident Response template, which is about understanding how the CA's processes failed. If you were to imagine intentionally violating the BRs, knowingly, it seems like an incident response template would be far more damning for that CA's operational competencies. That's not to suggest to CAs its better to ask forgiveness than permission - a CA that ignored changes in the BRs, clearly communicated (as Wayne mentioned in the original post), also seems likely to have an incident report template that is quite damning. Using the experiences from the SHA-1 exception process, the only formalized exception process, you can see that even in those limited cases, there was significant skepticism towards the reasons. I would think that any proposal for exceptions minimally achieve that degree of transparency, but would be equally damning if those justifications were the same as those used for SHA-1 - as the SHA-1 exception process "should" have revealed that those are not, in fact, seen as legitimate. If it helps to imagine this as a "How would this incident be received if it became part of a Wiki page that listed a series of ongoing violations", I think any CA contemplating not meeting the required transition date should be asking "How many issues have I (or my sub-CAs) had under https://wiki.mozilla.org/CA/Incident_Dashboard and https://wiki.mozilla.org/CA/Closed_Incidents ). And there are definitely some CAs that do not look to great in that light. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: CA Communication: Underscores in dNSNames
I only ask because telling people to go back to the CA and work something out isn’t a great answer when the retort is that the CA will be distrusted if they don’t. Either the customer doesn’t replace all their certs and they are made non-functional by revocation or the certs are distrusted because the CA isn’t operational anymore. Telling people to go have the CA cover the risk when those are the two options seems like we’re avoiding the public discussion. From: Ryan Sleevi Sent: Friday, December 7, 2018 2:26 PM To: Jeremy Rowley Cc: mozilla-dev-security-policy Subject: Re: CA Communication: Underscores in dNSNames On Fri, Dec 7, 2018 at 2:00 PM Jeremy Rowley via dev-security-policy mailto:dev-security-policy@lists.mozilla.org> > wrote: This isn't a CA-issue because the risk associated with non-compliance isn't defined yet. https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ ""Mozilla MAY, at its sole discretion, decide to disable (partially or fully) or remove a certificate at any time and for any reason. This may happen immediately or on a planned future date. Mozilla will disable or remove a certificate if the CA demonstrates ongoing or egregious practices that do not maintain the expected level of service or that do not comply with the requirements of this policy."" Sounds like the risk is well-defined and documented. >From what I've heard here, the risk is distrust or loss of EV indicators, which is distrust-like. That's a pretty big thing to push back on the CA for a non-security issue. Thus, I think the risk of missing the underscore revocation date needs to be discussed here so everyone, including website operators and the relying parties, know first-hand what the risks of the CA missing the deadline are. Any and every qualification or failure to abide by the program requirements comes with it the risk of sanction, up to, and including, distrust. It sounds like you're looking for a way for CAs to make a cost/benefit analysis as to whether it's more beneficial to them to violate requirements, by having a clearer guarantee what it will cost them if they intentionally do so, versus what they may gain from their Subscribers. That doesn't really seem aligned with the incentives of the ecosystem or the relying parties, since CAs (and their Subscribers) are not able to, on purely technical level, evaluate the cost or impact to Relying Parties, since Relying Parties include every possible entity that trusts that root. If the risk is that there is a note on the audit, that is an acceptable risk. If the risk is a loss of the root...probably less so. Pushing the question back to the CA without better discussion by the browsers makes finding a solution or understanding the risks impossible. While I think it's positive and encouraging to see CAs acknowledge that their audits exist to disclose non-conformities/qualifications, I don't think it should be seen as legitimizing or accepting that intentional non-conformities/qualifications are desirable. A well-run CA should strive to have zero qualifications, findings, or non-conformities - not because they were able to convince their auditor that they weren't issues / were minor, but because they operated above and beyond reproach, and there were literally no issues. Anything short of that is an indicator that a CA is failing in its role as a trusted steward, and repeated failures seem reasonable to discuss sanction or distrust. CAs (and their sub-CAs) with a pattern of incidents on the incident dashboard ( https://wiki.mozilla.org/CA/Incident_Dashboard and https://wiki.mozilla.org/CA/Closed_Incidents ) probably have the greatest risk of sanction, given the pre-existing patterns of non-compliance. 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
RE: CA Communication: Underscores in dNSNames
That’s not well defined as there are various grades below that. Is the plan to remove any CA that doesn’t comply with this requirement? From: Ryan Sleevi Sent: Friday, December 7, 2018 2:26 PM To: Jeremy Rowley Cc: mozilla-dev-security-policy Subject: Re: CA Communication: Underscores in dNSNames On Fri, Dec 7, 2018 at 2:00 PM Jeremy Rowley via dev-security-policy mailto:dev-security-policy@lists.mozilla.org> > wrote: This isn't a CA-issue because the risk associated with non-compliance isn't defined yet. https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ ""Mozilla MAY, at its sole discretion, decide to disable (partially or fully) or remove a certificate at any time and for any reason. This may happen immediately or on a planned future date. Mozilla will disable or remove a certificate if the CA demonstrates ongoing or egregious practices that do not maintain the expected level of service or that do not comply with the requirements of this policy."" Sounds like the risk is well-defined and documented. >From what I've heard here, the risk is distrust or loss of EV indicators, which is distrust-like. That's a pretty big thing to push back on the CA for a non-security issue. Thus, I think the risk of missing the underscore revocation date needs to be discussed here so everyone, including website operators and the relying parties, know first-hand what the risks of the CA missing the deadline are. Any and every qualification or failure to abide by the program requirements comes with it the risk of sanction, up to, and including, distrust. It sounds like you're looking for a way for CAs to make a cost/benefit analysis as to whether it's more beneficial to them to violate requirements, by having a clearer guarantee what it will cost them if they intentionally do so, versus what they may gain from their Subscribers. That doesn't really seem aligned with the incentives of the ecosystem or the relying parties, since CAs (and their Subscribers) are not able to, on purely technical level, evaluate the cost or impact to Relying Parties, since Relying Parties include every possible entity that trusts that root. If the risk is that there is a note on the audit, that is an acceptable risk. If the risk is a loss of the root...probably less so. Pushing the question back to the CA without better discussion by the browsers makes finding a solution or understanding the risks impossible. While I think it's positive and encouraging to see CAs acknowledge that their audits exist to disclose non-conformities/qualifications, I don't think it should be seen as legitimizing or accepting that intentional non-conformities/qualifications are desirable. A well-run CA should strive to have zero qualifications, findings, or non-conformities - not because they were able to convince their auditor that they weren't issues / were minor, but because they operated above and beyond reproach, and there were literally no issues. Anything short of that is an indicator that a CA is failing in its role as a trusted steward, and repeated failures seem reasonable to discuss sanction or distrust. CAs (and their sub-CAs) with a pattern of incidents on the incident dashboard ( https://wiki.mozilla.org/CA/Incident_Dashboard and https://wiki.mozilla.org/CA/Closed_Incidents ) probably have the greatest risk of sanction, given the pre-existing patterns of non-compliance. 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
Re: CA Communication: Underscores in dNSNames
On Fri, Dec 7, 2018 at 2:00 PM Jeremy Rowley via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > This isn't a CA-issue because the risk associated with non-compliance isn't > defined yet. https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ ""Mozilla MAY, at its sole discretion, decide to disable (partially or fully) or remove a certificate at any time and for any reason. This may happen immediately or on a planned future date. Mozilla will disable or remove a certificate if the CA demonstrates ongoing or egregious practices that do not maintain the expected level of service or that do not comply with the requirements of this policy."" Sounds like the risk is well-defined and documented. > From what I've heard here, the risk is distrust or loss of EV > indicators, which is distrust-like. That's a pretty big thing to push back > on the CA for a non-security issue. Thus, I think the risk of missing the > underscore revocation date needs to be discussed here so everyone, > including > website operators and the relying parties, know first-hand what the risks > of > the CA missing the deadline are. Any and every qualification or failure to abide by the program requirements comes with it the risk of sanction, up to, and including, distrust. It sounds like you're looking for a way for CAs to make a cost/benefit analysis as to whether it's more beneficial to them to violate requirements, by having a clearer guarantee what it will cost them if they intentionally do so, versus what they may gain from their Subscribers. That doesn't really seem aligned with the incentives of the ecosystem or the relying parties, since CAs (and their Subscribers) are not able to, on purely technical level, evaluate the cost or impact to Relying Parties, since Relying Parties include every possible entity that trusts that root. > If the risk is that there is a note on the > audit, that is an acceptable risk. If the risk is a loss of the > root...probably less so. Pushing the question back to the CA without > better > discussion by the browsers makes finding a solution or understanding the > risks impossible. While I think it's positive and encouraging to see CAs acknowledge that their audits exist to disclose non-conformities/qualifications, I don't think it should be seen as legitimizing or accepting that intentional non-conformities/qualifications are desirable. A well-run CA should strive to have zero qualifications, findings, or non-conformities - not because they were able to convince their auditor that they weren't issues / were minor, but because they operated above and beyond reproach, and there were literally no issues. Anything short of that is an indicator that a CA is failing in its role as a trusted steward, and repeated failures seem reasonable to discuss sanction or distrust. CAs (and their sub-CAs) with a pattern of incidents on the incident dashboard ( https://wiki.mozilla.org/CA/Incident_Dashboard and https://wiki.mozilla.org/CA/Closed_Incidents ) probably have the greatest risk of sanction, given the pre-existing patterns of non-compliance. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: [FORGED] Re: Incident report - Misissuance of CISCO VPN server certificates by Microsec
On Thu, 6 Dec 2018, Peter Gutmann via dev-security-policy wrote: Paul Wouters via dev-security-policy writes: Usually X509 is validated using standard libraries that only think of the TLS usage. So most certificates for VPN usage still add EKUs like serverAuth or clientAuth, or there will be interop problems. So just to make sure I've got this right, implementations are needing to add dummy TLS EKUs to non-TLS certs in order for them to "work"? You understanding is correct. In that case why not add a signalling EKU or policy value, a bit like Microsoft's systemHealthLoophole EKU (I don't know what its official name is, 1 3 6 1 4 1 311 47 1 3) where the normal systemHealth key usage is meant to indicate compliance with a system or corporate security policy and the systemHealthLoophole key usage is for systems that don't comply with the policy but that need a systemHealth certificate anyway. I'm not sure how that is helpful for those crypto libraries who mistakenly believe a certificate is a TLS certificate and thus if the EKU is not empty it should have serverAuth or clientAuth. Better to define a new EKU, "tlsCompabitility", telling the relying party that the TLS EKUs are present for compatibility purposes and can be ignored if it's a non-TLS use. As I stated earier, since often these certificates are re-used for the VPN server's TLS (openvpn, openconnect, etc) protocols or for their webgui's provisioning API, they will most likely want serverAuth anyway. btw for nss this got fixed recently: https://bugzilla.mozilla.org/show_bug.cgi?id=1252891 Paul ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: CA Communication: Underscores in dNSNames
Personally, i think you should continue the discussion here. Although you can bring it up to whichever ca you use, the reality is that without the browsers knowing why the certs cant be replaced and the number, theres no way to gauge their reaction to a non compliance. The penalties may include root removal (see symantec) so I doubt many cas would be willing to risk a qualification without clear guidance from the browsers on the risk associated with the non compliance. From: dev-security-policy on behalf of pilgrim2223--- via dev-security-policy Sent: Friday, December 7, 2018 8:26:42 AM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: CA Communication: Underscores in dNSNames Thank you very much for your response! So at the end of the day I will not get any relief from the browsers, and will need to get an exception from my CA? When I asked the CA they told me to take it here. Feels like the CA is where I'm going to have to focus! Thanks again for your time! ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://clicktime.symantec.com/a/1/nN3YNjTD37Z9bk8efCYXsWHpyw8ViK61Q8Dz1AzUtno=?d=cQ4KQMo02NQvJ7GQxkZHfn9YbOkOTiGLFwgAhzovU-ksifF97AFzeTEl3fKU1c4flMJM5MQa4SYfNOuCB5-Y29jyEtL2_9KBxlVmHB_-8X_yPT3Gd1KBASJgcwXjKaIjjc7h8rFYLmo4FmmjdQDJfQcxl_q00tAfBZTdTqkwLD4b__i1PLIwekimsAKnCEc7M1LQPr1uSNB-FjHnEcF14WbG_18ILSXzHM34tK_cdKnINlfFOEvMSGXK7LVBeRjiRGTuodckiUppT5eIbtRZNKo6R8hoXcUzy-yTZ21EbW651pPGEqEwRb1Qpu9J0tLL6DExVNq6euprfMtWQTwjpQGvzkg5KO26pXSnafFpMBxblo_G0EcAZEMPzGWZrQxxtD8_wSHTTO7-9MbzrQGF8qAWuuFbGW-M220s2HRhgU8qz_qZtto%3D=https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: CA Communication: Underscores in dNSNames
Thank you very much for your response! So at the end of the day I will not get any relief from the browsers, and will need to get an exception from my CA? When I asked the CA they told me to take it here. Feels like the CA is where I'm going to have to focus! Thanks again for your time! ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
