Proposal: Advocate to get Section 9.3.1 (Reserved Certificate Policy Identifiers) made mandatory.
It would be great to see Mozilla propose and advocate to have section 9.3.1 of
the BRs, Reserved Certificate Policy Identifiers, to be made mandatory with the
CA/Browser forum. Presently this section of the BRs is only optional.
The text as of revision 1.1.8 reads:
9.3.1 Reserved Certificate Policy Identifiers
The following Certificate Policy identifiers are reserved for use by CAs as an
optional means of asserting compliance with these Requirements as follows:
{joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140)
certificate-policies(1) baseline- requirements(2) domain-validated(1)}
(2.23.140.1.2.1), if the Certificate complies with these Requirements but lacks
Subject Identity Information that is verified in accordance with Section 11.2.
If the Certificate asserts the policy identifier of 2.23.140.1.2.1, then it
MUST NOT include organizationName, streetAddress, localityName,
stateOrProvinceName, or postalCode in the Subject field.
{joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140)
certificate-policies(1) baseline- requirements(2)
subject-identity-validated(2)} (2.23.140.1.2.2), if the Certificate complies
with these Requirements and includes Subject Identity Information that is
verified in accordance with Section 11.2.
If the Certificate asserts the policy identifier of 2.23.140.1.2.2, then it
MUST also include organizationName, localityName, stateOrProvinceName (if
applicable), and countryName in the Subject field.
The status quo today means that it is not possible to discriminate
programatically between a DV and OV certificate in a standardized, reliable way.
This is unreasonable as the validation and assurance on such certificates are
very different. This should, therefore, be reflected in the certificates that
are issued by CAs but this is typically not the case today.
Changing the BRs to make this mandatory going forward would address this over
time as existing certificates expire and are renewed.
Thanks,
Nick
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
Re: Problem (Error Code: sec_error_bad_der)
Le mardi 22 juillet 2014 20:29:40 UTC+2, Kathleen Wilson a écrit : [...] If your intranet site is still working with Firefox 30 and not with Nightly, it might be a side effect of our switch to mozilla::pkix as described on this wiki page: https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Behavior_Changes But I don't know why the change would cause you to get the sec_error_bad_der error. Maybe a certificate with included DEFAULT elements (this is not DER conformant), such as the cA BOOLEAN of BasicConstraints extension when its value is FALSE. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Proposal: Advocate to get Section 9.3.1 (Reserved Certificate Policy Identifiers) made mandatory.
On 23/07/14 10:06, nick.l...@lugatech.com wrote: The status quo today means that it is not possible to discriminate programatically between a DV and OV certificate in a standardized, reliable way. This is because Mozilla's position is that, in security terms, there is no relevant difference. This is unreasonable as the validation and assurance on such certificates are very different. They are different, but not in a way that is reasonably measurable and auditable. The very reason EV (which does have identifying OIDs, and can be distinguished programmatically) exists is because when it did not, there were a wide variety of practices concerning what was an appropriate level of validation for the O field in certificates. (And, I would say, _all_ of them were inadequate, some more so than others.) EV sets the minimum levels of validation, in a way which is agreed, auditable and audited. That meant that we were confident in displaying the O field to the user as a trusted piece of data - which we do in the URL bar. If a cert does not meet the EV standards for information validation, we feel you cannot sufficiently trust the O field, and therefore from a security perspective there is no difference between that certificate and one where the O field is absent. Hence we make no UI distinction between OV and DV. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Proposal: Advocate to get Section 9.3.1 (Reserved Certificate Policy Identifiers) made mandatory.
On Wednesday, July 23, 2014 8:50:38 PM UTC+8, Gervase Markham wrote: On 23/07/14 10:06, nick.l...@lugatech.com wrote: The status quo today means that it is not possible to discriminate programatically between a DV and OV certificate in a standardized, reliable way. This is because Mozilla's position is that, in security terms, there is no relevant difference. Clearly EV is very much the gold standard, but I there is a relevant general difference between EV and DV even if not a security one. It would be nice if Firefox could state that the certificate was DV or EV in a neutral way without making / implying any security difference. This is unreasonable as the validation and assurance on such certificates are very different. They are different, but not in a way that is reasonably measurable and auditable. The very reason EV (which does have identifying OIDs, and can be distinguished programmatically) exists is because when it did not, there were a wide variety of practices concerning what was an appropriate level of validation for the O field in certificates. (And, I would say, _all_ of them were inadequate, some more so than others.) EV sets the minimum levels of validation, in a way which is agreed, auditable and audited. That meant that we were confident in displaying the O field to the user as a trusted piece of data - which we do in the URL bar. If a cert does not meet the EV standards for information validation, we feel you cannot sufficiently trust the O field, and therefore from a security perspective there is no difference between that certificate and one where the O field is absent. Hence we make no UI distinction between OV and DV. There is a conceptual separation of concerns though from a certificate specifying that it is DV or OV and what, if any, UI would be appropriate to separate the two in a Web browser. No difference is a valid option. An extension to Firefox, for example, may want to show EV style UI in blue for those who understand the difference between the three types of certificate to draw inference from. Presently one could not do so based on standardized information contained within a certificate. Were it mandated that this information be included, Firefox would still be completely free to ignore the information from a UI perspective. Appropriate UI is a completely separate question to a certificate containing this information. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Proposal: Advocate to get Section 9.3.1 (Reserved Certificate Policy Identifiers) made mandatory.
Sorry, I meant to write: It would be nice if Firefox could state that the certificate was DV or -OV- in a neutral way without making / implying any security difference. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Proposal: Advocate to get Section 9.3.1 (Reserved Certificate Policy Identifiers) made mandatory.
Right - all adding the OIDs does is specify in the certificate which BR section was used to perform the validation. There isn't a security indicator attached. Jeremy -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org] On Behalf Of nick.l...@lugatech.com Sent: Wednesday, July 23, 2014 7:20 AM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Proposal: Advocate to get Section 9.3.1 (Reserved Certificate Policy Identifiers) made mandatory. Sorry, I meant to write: It would be nice if Firefox could state that the certificate was DV or -OV- in a neutral way without making / implying any security difference. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Proposal: Advocate to get Section 9.3.1 (Reserved Certificate Policy Identifiers) made mandatory.
Ryan Hurst wrote a blog post on this very topic not too long ago. His conclusion was that determining, programmatically, the difference was difficult. See http://unmitigatedrisk.com/?p=203. This is mostly because there are some certs that still include a domain in the org field. Requiring a BR OID serves two purposes - 1) the OID is a positive assertion to the browser by the CA that the cert was issued under the BRs and intended for SSL and 2) the OID identifies the sections relied on for validation. The OID assists in auditing whether a CA is aware of its practices and how it is choosing to comply with the BRs. Jeremy -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org] On Behalf Of Robin Alden Sent: Wednesday, July 23, 2014 8:02 AM To: 'Gervase Markham'; nick.l...@lugatech.com; mozilla-dev-security-pol...@lists.mozilla.org Subject: RE: [SPAM] Re: Proposal: Advocate to get Section 9.3.1 (Reserved Certificate Policy Identifiers) made mandatory. On 23/07/14 10:06, nick.l...@lugatech.com wrote: The status quo today means that it is not possible to discriminate programatically between a DV and OV certificate in a standardized, reliable way. Gerv said.. This is because Mozilla's position is that, in security terms, there is no relevant difference. That is not the reason. That may be a contributory reason to Mozilla not proposing or supporting the proposition of language to change the BR's 9.3.1 which result in it not being compulsory to include a mandated policy OID in a certificate which would identify it unequivocally as being a DV or an OV certificate, but it is not the definitive reason why the BRs do not mandate it. If the BRs already mandated it I would not expect your opinion or your UI to change, but the OP's question would not have arisen as he would have easily programmatically been able to tell whether a certificate was OV or DV. This is unreasonable as the validation and assurance on such certificates are very different. They are different, but not in a way that is reasonably measurable and auditable. snip If a cert does not meet the EV standards for information validation, we feel you cannot sufficiently trust the O field, and therefore from a security perspective there is no difference between that certificate and one where the O field is absent. Hence we make no UI distinction between OV and DV. Whilst I disagree with your sentiment, in your UI (browser, certificate viewer, mail client, etc.) it's your game, so it's your rules. The compulsory inclusion of a Policy Identifier OID in the certificate definitively stating DV or OV need not offend you, since you will probably continue to ignore it. As to the issue which presumably ignited the thread in the first place, I think that for a non-EV BR compliant certificate you probably can distinguish programmatically between OV and DV. According to section 9.2.4 of the BRs, if the certificate subject contains an organizationName field and also contains one or both of (stateOrProvinceName and localityName) then it is an OV certificate. If the certificate subject does not contain an organizationName field then it is an OV certificate. This begs the question of whether the certificate is claiming to be an EV certificate or claiming to be BR compliant. Regards Robin Alden Comodo ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Proposal: Advocate to get Section 9.3.1 (Reserved Certificate Policy Identifiers) made mandatory.
Having these identifiers takes us a long way towards our goal of deterministic evaluation of certificate issuance policy — that said not all CAs have adopted them which is technically alright since the Baseline Requirements do allow them to use their own Policy Identifiers. This is what Ryan said about Policy OID based (Deterministic) approach, I read this as in favor of Policy OIDs. Any other criticism why CAs should not support the Deterministic approach? Thanks, M.D. On 7/23/2014 5:34 PM, Jeremy Rowley wrote: Ryan Hurst wrote a blog post on this very topic not too long ago. His conclusion was that determining, programmatically, the difference was difficult. See http://unmitigatedrisk.com/?p=203. This is mostly because there are some certs that still include a domain in the org field. Requiring a BR OID serves two purposes - 1) the OID is a positive assertion to the browser by the CA that the cert was issued under the BRs and intended for SSL and 2) the OID identifies the sections relied on for validation. The OID assists in auditing whether a CA is aware of its practices and how it is choosing to comply with the BRs. Jeremy -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org] On Behalf Of Robin Alden Sent: Wednesday, July 23, 2014 8:02 AM To: 'Gervase Markham'; nick.l...@lugatech.com; mozilla-dev-security-pol...@lists.mozilla.org Subject: RE: [SPAM] Re: Proposal: Advocate to get Section 9.3.1 (Reserved Certificate Policy Identifiers) made mandatory. On 23/07/14 10:06, nick.l...@lugatech.com wrote: The status quo today means that it is not possible to discriminate programatically between a DV and OV certificate in a standardized, reliable way. Gerv said.. This is because Mozilla's position is that, in security terms, there is no relevant difference. That is not the reason. That may be a contributory reason to Mozilla not proposing or supporting the proposition of language to change the BR's 9.3.1 which result in it not being compulsory to include a mandated policy OID in a certificate which would identify it unequivocally as being a DV or an OV certificate, but it is not the definitive reason why the BRs do not mandate it. If the BRs already mandated it I would not expect your opinion or your UI to change, but the OP's question would not have arisen as he would have easily programmatically been able to tell whether a certificate was OV or DV. This is unreasonable as the validation and assurance on such certificates are very different. They are different, but not in a way that is reasonably measurable and auditable. snip If a cert does not meet the EV standards for information validation, we feel you cannot sufficiently trust the O field, and therefore from a security perspective there is no difference between that certificate and one where the O field is absent. Hence we make no UI distinction between OV and DV. Whilst I disagree with your sentiment, in your UI (browser, certificate viewer, mail client, etc.) it's your game, so it's your rules. The compulsory inclusion of a Policy Identifier OID in the certificate definitively stating DV or OV need not offend you, since you will probably continue to ignore it. As to the issue which presumably ignited the thread in the first place, I think that for a non-EV BR compliant certificate you probably can distinguish programmatically between OV and DV. According to section 9.2.4 of the BRs, if the certificate subject contains an organizationName field and also contains one or both of (stateOrProvinceName and localityName) then it is an OV certificate. If the certificate subject does not contain an organizationName field then it is an OV certificate. This begs the question of whether the certificate is claiming to be an EV certificate or claiming to be BR compliant. Regards Robin Alden Comodo ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy 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: Proposal: Advocate to get Section 9.3.1 (Reserved Certificate Policy Identifiers) made mandatory.
+1 Robin -Original Message- From: Jeremy Rowley [mailto:jeremy.row...@digicert.com] Sent: 23 July 2014 16:05 To: 'Moudrick M. Dadashov'; 'Robin Alden'; 'Gervase Markham'; nick.l...@lugatech.com; mozilla-dev-security-pol...@lists.mozilla.org Subject: RE: Proposal: Advocate to get Section 9.3.1 (Reserved Certificate Policy Identifiers) made mandatory. I agree he was in favor of requiring the BR OIDs, as I think most CAs are. Jeremy -Original Message- From: Moudrick M. Dadashov [mailto:m...@ssc.lt] Sent: Wednesday, July 23, 2014 9:02 AM To: Jeremy Rowley; 'Robin Alden'; 'Gervase Markham'; nick.l...@lugatech.com; mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Proposal: Advocate to get Section 9.3.1 (Reserved Certificate Policy Identifiers) made mandatory. Having these identifiers takes us a long way towards our goal of deterministic evaluation of certificate issuance policy - that said not all CAs have adopted them which is technically alright since the Baseline Requirements do allow them to use their own Policy Identifiers. This is what Ryan said about Policy OID based (Deterministic) approach, I read this as in favor of Policy OIDs. Any other criticism why CAs should not support the Deterministic approach? Thanks, M.D. On 7/23/2014 5:34 PM, Jeremy Rowley wrote: Ryan Hurst wrote a blog post on this very topic not too long ago. His conclusion was that determining, programmatically, the difference was difficult. See http://unmitigatedrisk.com/?p=203. This is mostly because there are some certs that still include a domain in the org field. Requiring a BR OID serves two purposes - 1) the OID is a positive assertion to the browser by the CA that the cert was issued under the BRs and intended for SSL and 2) the OID identifies the sections relied on for validation. The OID assists in auditing whether a CA is aware of its practices and how it is choosing to comply with the BRs. Jeremy -Original Message- From: dev-security-policy [mailto:dev-security-policy- bounces+jeremy.rowley=digicert.com@lists.m ozilla.org] On Behalf Of Robin Alden Sent: Wednesday, July 23, 2014 8:02 AM To: 'Gervase Markham'; nick.l...@lugatech.com; mozilla-dev-security-pol...@lists.mozilla.org Subject: RE: [SPAM] Re: Proposal: Advocate to get Section 9.3.1 (Reserved Certificate Policy Identifiers) made mandatory. On 23/07/14 10:06, nick.l...@lugatech.com wrote: The status quo today means that it is not possible to discriminate programatically between a DV and OV certificate in a standardized, reliable way. Gerv said.. This is because Mozilla's position is that, in security terms, there is no relevant difference. That is not the reason. That may be a contributory reason to Mozilla not proposing or supporting the proposition of language to change the BR's 9.3.1 which result in it not being compulsory to include a mandated policy OID in a certificate which would identify it unequivocally as being a DV or an OV certificate, but it is not the definitive reason why the BRs do not mandate it. If the BRs already mandated it I would not expect your opinion or your UI to change, but the OP's question would not have arisen as he would have easily programmatically been able to tell whether a certificate was OV or DV. This is unreasonable as the validation and assurance on such certificates are very different. They are different, but not in a way that is reasonably measurable and auditable. snip If a cert does not meet the EV standards for information validation, we feel you cannot sufficiently trust the O field, and therefore from a security perspective there is no difference between that certificate and one where the O field is absent. Hence we make no UI distinction between OV and DV. Whilst I disagree with your sentiment, in your UI (browser, certificate viewer, mail client, etc.) it's your game, so it's your rules. The compulsory inclusion of a Policy Identifier OID in the certificate definitively stating DV or OV need not offend you, since you will probably continue to ignore it. As to the issue which presumably ignited the thread in the first place, I think that for a non-EV BR compliant certificate you probably can distinguish programmatically between OV and DV. According to section 9.2.4 of the BRs, if the certificate subject contains an organizationName field and also contains one or both of (stateOrProvinceName and localityName) then it is an OV certificate. If the certificate subject does not contain an organizationName field then it is an OV certificate. This begs the question of whether the certificate is claiming to be an EV certificate or claiming to be BR compliant. Regards Robin Alden Comodo ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org
Re: Proposal: Switch generic icon to negative feedback for non-https sites
on Tue, 22 Jul 2014 12:24:30 -0700, Brian Smith wrote: Having said all of that, I remember that Mozilla did some user research ~3 years ago that showed that when we show a negative security indicator like the broken lock icon, a significant percentage of users interpreted the problem to lie in the browser, not in the website--i.e. the security problem is Firefox's fault, not their favorite website. It would be important to do research to confirm or (hopefully) refute this finding. How about showing a red border around the webpage, possibly with a banner at the top (but inside the page area)? -- begin .sig Jernej Simončič ◊ jernej|s-ng at eternallybored.org end ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
