RE: Proposal: Advocate to get Section 9.3.1 (Reserved Certificate Policy Identifiers) made mandatory.
Per our CPS and the BR/EV requirements, we always abide by the latest version of the BRs From Section 8.3: [Name of CA] conforms to the current version of the CA/Browser Forum Guidelines for Issuance and Management of Extended Validation Certificates published at http://www.cabforum.org. In the event of any inconsistency between this document and those Guidelines, those Guidelines take precedence over this document. Therefore, any CA compliant would have to abide by the latest version, regardless of when their CPS is published. Asserting the appropriate OID in the certificate is an assertion of compliance with the latest version of the guidelines, meaning versioning is largely irrelevant. Jeremy -Original Message- From: Ryan Sleevi [mailto:ryan-mozdevsecpol...@sleevi.com] Sent: Sunday, July 27, 2014 9:11 PM To: Jeremy Rowley Cc: 'ryan-mozdevsecpol...@sleevi.com'; 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 Sun, July 27, 2014 7:41 pm, Jeremy Rowley wrote: You can tell which BR version the cert complies with by looking at the issuance date, No. You can't. Surely you don't mean to tell me that if I go find a cert DigiCert issued last week that I can safely assume it's going to conform to BR 1.1.8, do you? The most recent WebTrust Seal linked from your page, Seal ID 1527, documents that DigiCert was audited to WebTrust 2.0 by KPMG, dated 12 July 2013, and covering through 31 March 2013. Your CP (v4.06) and CPS (v4.06) are both dated May 14, 2014. But BR 1.1.8 is dated 5 June 2014 (Replacing 1.1.7, dated 3 April 2014). Can I tell, from looking at the issuance date, which BR version a cert issued on July 20 2014 was issued? Would I be safe in assuming 1.1.8, even though it's newer than your CP/CPS? Should I assume your CP/CPS were updated to reflect through 1.1.7? What about the fact that WebTrust for BR, v1.1 (Amended), the most recent version published by AICPA, is set with an effective Jan 31, 2013 date, which corresponds to the time between BR 1.1.1 and BR 1.1.2 (1.1.2 introducing the language regarding wildcard certs and gTLDs)? There's no reasonable, programatic way to determine which, out of all these criteria, DigiCert is claiming conformance to. Short of manually inspecting CP/CPSes. This is where the OID nightmare comes from. There are 15 versions of the BRs. There are three versions of WebTrust for BRs. I haven't bothered to count how many ETSI versions. From the DigiCert repository ( http://www.digicert.com/ssl-cps-repository.htm ) I see there have been four versions of your CP/CPS since the BRs went into effect. And this, of course, ignores the practice that some CAs (but presumably not Digicert) practice, of 'backdating' the issuance date of certs for compatibility reasons (or, allegedly, accounting, although that's a bit specious). ___ 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.
So, based off of the comments that have been made, please can Mozilla support such a change? If not, what would Mozilla's objections be that are in scope to the question/issue? Presently, none appear to have been articulated. The immediate benefit to Mozilla would be consistency and conformity among the OV certificates that get issued. This is because, as Jeremy mentions, they will be bound by the requirements that inclusion of the OID brings as it is an assertion of compliance. As has been said but probably needs to be reiterated, we all need to be careful not to conflate, confuse and overload the issue with the entirely separate and distinct questions that surround handling of the certificate in code and what appropriate UX is. These are clearly far more contentious, perhaps political in nature, and should be considered and discussed independently to this. Thanks! Nick ___ 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 https
