Re: Proposal: Switch generic icon to negative feedback for non-https sites
On Wed, Jul 23, 2014 at 4:06 AM, Jernej Simončič wrote: > How about showing a red border around the webpage, possibly with a banner > at the top (but inside the page area)? The page area (the Viewport) is not a good place for UI that needs to be trustworthy. Trustworthy UI controls and indicators need to be in the chrome. ___ 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.
It makes a difference because you can tell whether the CA is operating effective polices in accordance with the BRs. Too many DV certs hold themselves out as OV certs without actually providing the verification under the BRs. Requiring the BR OIDs is an assertion by the CA of compliance that is independent of any display in the UI. Jeremy -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org] On Behalf Of Gervase Markham Sent: Wednesday, July 23, 2014 8:51 AM To: 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. On 23/07/14 14:18, nick.l...@lugatech.com wrote: > 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. If it makes no difference to the security, why would the average user want to know (how would they even understand the difference?), and why would a web browser want to complicate its UI by showing them? Gerv ___ 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.
On Wed, Jul 23, 2014 at 7:50 AM, Gervase Markham wrote: > If it makes no difference to the security, why would the average user > want to know (how would they even understand the difference?), and why > would a web browser want to complicate its UI by showing them? Anyone making the UX of a UA that performs X.509 validation can certainly try to distinguish OV from DV programatically (potentially hard, as Hurst notes), but I am pretty sure they'll find that their users don't appreciate the distinction. In the case of browsers specifically, the same-origin policy is the law of the land, and complicating it further (to distinguish levels of subject validation) would not fly in any case — with users or with web developers. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
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
Re: Proposal: Switch generic icon to negative feedback for non-https sites
On Tue, Jul 22, 2014 at 2:00 PM, 'Chris Palmer' via Security-dev < security-...@chromium.org> wrote: > So, it seems we're mixing the Lock metaphor with the Traffic Light > metaphor, and that mixing them does not make sense. I have proposed > dropping the lock part and just going with red, yellow, and green > colors. No more lock. > While we should sort out our mixed metaphors, I don't think this wouldn't work for accessibility reasons. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Proposal: Switch generic icon to negative feedback for non-https sites
This is not uncommon. We found the same issue among all 3-letter agency users of the P25 radios. They frequently confused the *not* encrypted icon for the encrypted one. In fact, we still hear them over the air giving the wrong instructions on how to encrypt. I don't think developers are the best choice for this, instead we should let the users decide. There was a meetup of HCI security people at HOPE X last weekend. Somebody proposed a contest to help find which icons are the easiest to comprehend. -sandy On Tue, Jul 22, 2014 at 2:00 PM, 'Chris Palmer' via Security-dev < security-...@chromium.org> wrote: > On Mon, Jul 21, 2014 at 7:15 PM, Michal Zalewski > wrote: > > > Indeed. Instinctively [*], I think that a prominent always-on > > indicator - say, an icon alternating between a red peering eye and a > > green / gray closed lock - is strictly better than showing nothing for > > Tangential, fun note: felt, et al. found that ~50% of users thought a > green lock was *open*, hence unsafe — green means you can go, through > the locked door, while red means the lock is securely locked. Like an > airplane toilet... > > So, it seems we're mixing the Lock metaphor with the Traffic Light > metaphor, and that mixing them does not make sense. I have proposed > dropping the lock part and just going with red, yellow, and green > colors. No more lock. > > Or, like Safari, just the lock, no color. But that doesn't get us the > 3-state indicator I think we need. (Although that need is, ideally, > temporary.) > > > HTTP and then having a DHS-grade fifteen-level color-coded threat > > level system for HTTPS. The latter mostly teaches people that the > > browser always cries wolf - and it leaves them vulnerable to > > sslstrip-type attacks. > > Agree. > > > We should also explicitly and very vocally tell website owners is that > > if their stuff is important, they *need* to start using HSTS. > > Agree. > > To unsubscribe from this group and stop receiving emails from it, send an > email to security-dev+unsubscr...@chromium.org. > ___ 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. > >> > > > >> 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 c
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@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. >> > >> 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 ___ 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. 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.
On 23/07/14 14:18, nick.l...@lugatech.com wrote: > 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. If it makes no difference to the security, why would the average user want to know (how would they even understand the difference?), and why would a web browser want to complicate its UI by showing them? 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.
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. > > > 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.
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.
We'd support that motion in the CAB Forum. In fact, I last time we discussed
this, a majority of CAs supported requiring the BR/EV OIDs in certificates. If
Mozilla would vote in favor of such a motion, the proposal would likely pass.
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 3:07 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: 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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
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. > > > 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 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.
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.
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.
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: 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: Switch generic icon to negative feedback for non-https sites
- Original Message - > From: "Adrienne Porter Felt" > To: "Daniel Roesler" > Cc: dev-security-policy@lists.mozilla.org, "Eric Mill" , > "security-dev" > , "Chris Palmer" > Sent: Tuesday, 22 July, 2014 1:42:05 AM > Subject: Re: Proposal: Switch generic icon to negative feedback for non-https > sites > > On Mon, Jul 21, 2014 at 4:20 PM, Daniel Roesler wrote: > > > Gotta start somewhere. > > > Best case: no one will notice it after the first few days. > Worst case: people notice it, and therefore start ignoring all https > authentication errors. > > Is there a way to make the best case better, without ending up at the worst > case? > > > > I actually kind of like the idea of showing the > > current generic icon for self-signed ssl certificates, and the broken > > lock icon for insecure connections. > > > That would mean that any active attacker on your network could silently > MITM bank of america, with no visible change except for a subtle downgrade > of the icon. And how is this worse than the current sslstrip attacks? People click through certificate warnings because in vast majority of instances they are false positives. We need to remove false positives. For example through mechanism sort of like of TOFU - remember if the web site did provide a valid cert (signed by a trusted CA) in the past. If it did and we now get a self signed cert - cry wolf. If it always did provide self signed or untrusted certificate - keep silent. Sure, this will not catch the MITM attack when the user uses a site for the first time. I'd say that's ok, the point is that we don't want to leak valid authentication cookies. Not to deny access to web servers. Users provide personally identifiable data or passwords over untrusted connections -- we really can't stop them from doing that. In fact, it's more problematic if it happens over HTTP than when it happens over HTTPS with self signed certs. The latter requires an active attack. -- Regards, Hubert Kario ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
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
