Re: Mozilla's Expectations for OCSP Incident Reporting

[Lee via dev-security-policy]

On 5/15/20, Peter Gutmann via dev-security-policy
 wrote:
> Hanno Böck  writes:
>
>>The impact it had was a monitoring system that checked whether the
>>certificate of a host was okay, using gnutls-cli with ocsp enabled (which
>>also uncovered a somewhat unexpected inconsistency in how the gnutls cli
>> tool
>>behaves[1]).
>
> Sure, but if the only impact was on a specially-configured setup
> (gnutls-cli
> with OCSP explicitly enabled rather than a standard web browser) then it
> didn't have any real impact on actual users.

How is this situation different from the time when the google ocsp
service was down?
https://groups.google.com/forum/?_escaped_fragment_=topic/mozilla.dev.security.policy/MMO3HSYghwQ

Not a whole lot of people noticed that.. but there was a real impact
on some actual users.

Lee
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: When should honest subscribers expect sudden (24 hours / 120 hours) revocations?

[Lee via dev-security-policy]

On 12/29/18, Ryan Sleevi  wrote:
> On Sat, Dec 29, 2018 at 10:24 AM Lee  wrote:
>
>> > It does not seem like a productive discussion will emerge if the
>> > ontology
>> > is going to be honest/dishonest participants.
>>
>> I think it's an excellent distinction.  An honest subscriber won't
>> deliberately attempt to spread malware.  But I like the idea of CAs
>> revoking certs for sites deliberately trying to do harm.. even tho I
>> get the impression that few actually revoke certs for that reason.
>>
>
> It's not, because it presumes to know the ineffable in order to make a
> judgement.

You've made your opinion clear in the past.  You're not going to
change my mind, I'm not going to change yours, so let's not waste our
time talking past each other.  OK?

Lee
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: When should honest subscribers expect sudden (24 hours / 120 hours) revocations?

[Lee via dev-security-policy]

On 12/29/18, Ryan Sleevi via dev-security-policy
 wrote:
> On Fri, Dec 28, 2018 at 11:21 PM Jakob Bohm via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> > My guess is all CAs have something like
>> >https://www.digicert.com/certificate-terms/
>> > 15. Certificate Revocation. DigiCert may revoke a Certificate without
>> > notice for the reasons stated in the CPS, including if DigiCert
>> > reasonably believes that:
>> > ...
>> > h. the Certificate was (i) misused, (ii) used or issued contrary to
>> > law, the CPS, or industry standards, or (iii) used, directly or
>> > indirectly, for illegal or fraudulent purposes, such as phishing
>> > attacks, fraud, or the distribution of malware or other illegal or
>> > fraudulent purposes,
>>
>> These were covered in the list you snipped, and shouldn't happen for an
>> *honest* subscriber.
>
>
> It does not seem like a productive discussion will emerge if the ontology
> is going to be honest/dishonest participants.

I think it's an excellent distinction.  An honest subscriber won't
deliberately attempt to spread malware.  But I like the idea of CAs
revoking certs for sites deliberately trying to do harm.. even tho I
get the impression that few actually revoke certs for that reason.

> By setting it up with loaded
> terms like that, it seems more likely that the engagement you’ll get is
> your own.
>
> That said, it’s clear you recognize that certificate holders may, at any
> point, find the need for their certificates to be replaced, and whether you
> fault and blame them - or their CA - for it, it does not sound like you
> dispute that. So there’s likely nothing more to be said on the topic.

I thought the question was about how much warning an _honest_ cert
holder should expect / get before their cert was revoked.

Lee
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: When should honest subscribers expect sudden (24 hours / 120 hours) revocations?

[Lee via dev-security-policy]

On 12/28/18, Jakob Bohm via dev-security-policy
 wrote:
> On 28/12/2018 19:44, Lee wrote:
>> On 12/27/18, Jakob Bohm via dev-security-policy
>>  wrote:
>>> Looking at the BRs, specifically BR 4.9.1, the reasons that can lead
>>> to fast revocation fall into a few categories / groups:
>>  <.. snip ..>
>>> So absent a bad CA, I wonder where there is a rule that subscribers
>>> should be ready to quickly replace certificates due to actions far
>>> outside their own control.
>>
>> My guess is all CAs have something like
>>https://www.digicert.com/certificate-terms/
>> 15. Certificate Revocation. DigiCert may revoke a Certificate without
>> notice for the reasons stated in the CPS, including if DigiCert
>> reasonably believes that:
>> ...
>> h. the Certificate was (i) misused, (ii) used or issued contrary to
>> law, the CPS, or industry standards, or (iii) used, directly or
>> indirectly, for illegal or fraudulent purposes, such as phishing
>> attacks, fraud, or the distribution of malware or other illegal or
>> fraudulent purposes,
>
> These were covered in the list you snipped, and shouldn't happen for an
> *honest* subscriber.

^shrug^ seems to me that at the very least, certs with an underscore
that were issued after July 26, 2017 (announcement of cabf ballot 202
failing to pass) were issued contrary to industry standards

>> i. industry standards or DigiCert’s CPS require Certificate
>> revocation, or revocation is necessary to protect the rights,
>> confidential information, operations, or reputation of DigiCert or a
>> third party.
>
> This is a catch all clause covering emergencies and BR requirements.
> My list that you entirely snipped breaks down the circumstances where
> the BRs require revocation at short notice.
>
>>
>> An underscore in the name ...>
>
> Please keep the underscore issue out of this thread, which is about
> the general question of what kind of notice the millions of small
> (and large) certificate subscribers are realistically supposed to
> get when CAs change their mind about already issued certificates.

Enough advance notice to keep them from getting so upset they buy
their certs from someone else?

Maybe some CAs will chime in with an answer.. but my guess is that you
won't find _a_ rule somewhere; it'll be in the CA user agreement where
they're told their cert could be revoked without notice because of
events outside their control.

Regards,
Lee
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: When should honest subscribers expect sudden (24 hours / 120 hours) revocations?

[Lee via dev-security-policy]

On 12/27/18, Jakob Bohm via dev-security-policy
 wrote:
> Looking at the BRs, specifically BR 4.9.1, the reasons that can lead
> to fast revocation fall into a few categories / groups:
<.. snip ..>
> So absent a bad CA, I wonder where there is a rule that subscribers
> should be ready to quickly replace certificates due to actions far
> outside their own control.

My guess is all CAs have something like
  https://www.digicert.com/certificate-terms/
15. Certificate Revocation. DigiCert may revoke a Certificate without
notice for the reasons stated in the CPS, including if DigiCert
reasonably believes that:
   ...
h. the Certificate was (i) misused, (ii) used or issued contrary to
law, the CPS, or industry standards, or (iii) used, directly or
indirectly, for illegal or fraudulent purposes, such as phishing
attacks, fraud, or the distribution of malware or other illegal or
fraudulent purposes,
i. industry standards or DigiCert’s CPS require Certificate
revocation, or revocation is necessary to protect the rights,
confidential information, operations, or reputation of DigiCert or a
third party.

An underscore in the name now (will after Jan 15? has since cabf
ballot 202 failed to pass?) violates industry standards?  If so, no
notice required.

And it seems to me that if digicert doesn't revoke certs with
underscores in the name it'll adversely affect the reputation of
DigiCert, so again it looks like no notice is required.  (but anything
that has "legally valid and enforceable agreement" in the text
probably requires lawyers to decide the issue & I'm not a lawyer)

Regards,
Lee
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Disallowed company name

[Lee via dev-security-policy]

On 6/1/18, Ryan Sleevi wrote:
> On Fri, Jun 1, 2018 at 9:14 AM, Peter Kurrasch wrote:
>
>> Security can be viewed as a series of AND's that must be satisfied in
>> order to conclude "you are probably secure". For example, when you browse
>> to an important website, make sure that "https" is used AND that the
>> domain name looks right  AND that a "lock icon" appears in the UI AND,
>> if the site uses EV certs, that the name of the organization seems
>> correct. Failing any of those, stop immediately; if all of them hold
>> true, you are probably fine.
>
> Note that research has shown

citation required

> that your first,
>> make sure that "https" is used

trivially easy after one adds the line
  user_pref("browser.urlbar.trimURLs", false);
to user.js.

> second,
>> the domain name looks right

easier after one adds the line
  user_pref("network.IDN_show_punycode", true);
to user.js & while not so easy on your first visit, trivially easy thereafter.

> third,
>> a "lock icon" appears

trivially easy

> and fourth options
>> the name of the organization seems correct

a problem on your _first_ visit.

> are all unreasonable requests of humans trying to be productive.

They wouldn't be so unreasonable if Mozilla had picked better defaults.

Lee
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Misissued certificates

[Lee via dev-security-policy]

What's it going to take for mozilla to set up near real-time
monitoring/auditing of certs showing up in ct logs?

Lee

On 8/9/17, Alex Gaynor via dev-security-policy
 wrote:
> (Whoops, accidentally originally CC'd to m.d.s originally! Original mail
> was to IdenTrust)
>
> Hi,
>
> The following certificates appear to be misissued:
>
> https://crt.sh/?id=77893170=cablint
> https://crt.sh/?id=77947625=cablint
> https://crt.sh/?id=78102129=cablint
> https://crt.sh/?id=92235995=cablint
> https://crt.sh/?id=92235998=cablint
>
> All of these certificates have a pathLenConstraint value with CA:FALSE,
> this violates 4.2.1.9 of RFC 5280: CAs MUST NOT include the
> pathLenConstraint field unless the cA boolean is asserted and the key usage
> extension asserts the keyCertSign bit.
>
> Alex
>
> --
> "I disapprove of what you say, but I will defend to the death your right to
> say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
> "The people's good is the highest law." -- Cicero
> GPG Key fingerprint: D1B3 ADC0 E023 8CA6
>
>
>
>
> --
> "I disapprove of what you say, but I will defend to the death your right to
> say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
> "The people's good is the highest law." -- Cicero
> GPG Key fingerprint: D1B3 ADC0 E023 8CA6
> ___
> 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: Certificates issued with HTTPS OCSP responder URL (IdenTrust)

[Lee via dev-security-policy]

On 8/9/17, Eric Mill  wrote:
> On Wed, Aug 9, 2017 at 4:28 PM, Lee  wrote:
>
>> On 8/9/17, Eric Mill via dev-security-policy
>>  wrote:
>> > On Tue, Aug 8, 2017 at 5:53 PM, identrust--- via dev-security-policy <
>> > dev-security-policy@lists.mozilla.org> wrote:
>> >
>> >> On Tuesday, August 8, 2017 at 12:06:47 PM UTC-4, Jonathan Rudenberg
>> wrote:
>> >> > > On Aug 8, 2017, at 10:29, identrust--- via dev-security-policy <
>> >> dev-security-policy@lists.mozilla.org> wrote:
>> >> > >
>> >> > > On Monday, August 7, 2017 at 4:47:39 PM UTC-4, Jonathan Rudenberg
>> >> wrote:
>> >> > >> “IdenTrust ACES CA 2” has issued five certificates with an OCSP
>> >> responder URL that has a HTTPS URI scheme. This is not valid, the OCSP
>> >> responder URI is required to have the plaintext HTTP scheme according
>> >> to
>> >> Baseline Requirements section 7.1.2.2(c).
>> >> > >>
>> >> > >> Here’s the list of certificates: https://misissued.com/batch/4/
>> >> > >>
>> >> > >> Jonathan
>> >> > >
>> >> > > IdenTrust had previously interpreted HTTP to be inclusive of HTTPS
>> in
>> >> this
>> >> > > context.  That being said, we have altered our profiles for
>> >> certificates
>> >> > > issued under this Sub CA to include only HTTP OCSP URLs.  All
>> >> certificates
>> >> > > issued going forward will contain an HTTP OCSP URL.  We will also
>> >> examine all
>> >> > > other sub CA to ensure only HTTP OCSP URLs are included.  Thank
>> >> > > you
>> >> for giving
>> >> > > us an opportunity to address this with the community
>> >> >
>> >> > Thanks for the update.
>> >> >
>> >> > Can you also clarify why the subject organizationName is "U.S.
>> >> Government” for all of these certificates, despite the other subject
>> >> fields
>> >> indicating organizations that are not a component of the US
>> >> Government?
>> >> >
>> >> > Jonathan
>> >>
>> >> Yes,
>> >> IdenTrust ACES SSL Certificates are issued in accordance with the ACES
>> >> certificate policy defined by U.S. General Service Administration (
>> >> http://csrc.nist.gov/groups/ST/crypto_apps_infra/csor/docum
>> >> ents/ACES-CP-v3-2_signed_05122017.pdf) and the GSA approved IdenTrust
>> CPS
>> >> (https://secure.identrust.com/certificates/policy/aces/IdenT
>> >> rust_ACES_CPS_v5.1_20161110.pdf)
>> >> These ACES SSL certificates are issued to either U.S. Government
>> agencies
>> >> and/or their sub-contractors in support of government
>> >> programs\projects.
>> >> The
>> >> CP requires an approved CA, such as IdenTrust, to identify U.S.
>> Government
>> >> in
>> >> subject organizationName along with other applicable organizations
>> >> (e.g.
>> >> sub-contractors, or local government agency, etc...).
>> >>
>> >
>> > If that's the case, I would expect each certificate to be
>> > authenticating
>> > hostnames that are used solely to provide such services to the U.S.
>> > Government. That doesn't appear to be the case with these.
>> >
>> > For example, one of them is for the homepage for a service provider:
>> > www.mudiaminc.com
>>
>> What am I doing wrong?  goto https://www.mudiaminc.com/
>> check the cert and it says
>> Issued To
>> Common Name (CN)*.opentransfer.com
>> Organization (O)ECOMMERCE, INC.
>>
>
> You're not doing anything wrong, that hostname is just not using that
> certificate at this time, at least not to public users. But issuance is
> what matters here.
>
> Given the capitalization of the common name, and the
> organizationalUnitName, the certificate was clearly issued to the same
> company.
>
>
>> And one of them is for what appears to be a state government revenue
>> > service's VPN: vpn.revenue.louisiana.gov
>>
>> I see that one - goto https://vpn.revenue.louisiana.gov/
>> check the cert and it says
>> Issued To
>> Common Name (CN)Vpn.revenue.louisiana.gov
>> Organization (O)U.S. Government
>>
>> > (So it's clear, "U.S. Government" only refers to the federal
>> > government,
>> > not state/local/tribal governments.)
>> >
>> > I personally (and to be clear, this is in my individual capacity and I
>> > am
>> > not representing my employer) think these are invalid
>> > organizationNames,
>> > constitute misissuance, and that Identrust should be using the "U.S.
>> > Government" only for hostnames providing services operated exclusively
>> > on
>> > behalf of the federal government.
>>
>> playing devils' advocate: how do you know that
>> https://vpn.revenue.louisiana.gov/ wasn't set up in collaboration with
>> the IRS or some other branch of the U.S. Government?
>>
>
> That wouldn't meet the definition that Identrust said in their email above,
> which is that certificates are "issued to either U.S. Government agencies

if it was a cooperative project, it seems possible/reasonable that the
USG ordered the certs.

> and/or their sub-contractors in support of government programs\projects".
> Maybe there's some very novel arrangement I'm not familiar with where the
> State 

Re: Certificates issued with HTTPS OCSP responder URL (IdenTrust)

[Lee via dev-security-policy]

On 8/9/17, Eric Mill via dev-security-policy
 wrote:
> On Tue, Aug 8, 2017 at 5:53 PM, identrust--- via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> On Tuesday, August 8, 2017 at 12:06:47 PM UTC-4, Jonathan Rudenberg wrote:
>> > > On Aug 8, 2017, at 10:29, identrust--- via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>> > >
>> > > On Monday, August 7, 2017 at 4:47:39 PM UTC-4, Jonathan Rudenberg
>> wrote:
>> > >> “IdenTrust ACES CA 2” has issued five certificates with an OCSP
>> responder URL that has a HTTPS URI scheme. This is not valid, the OCSP
>> responder URI is required to have the plaintext HTTP scheme according to
>> Baseline Requirements section 7.1.2.2(c).
>> > >>
>> > >> Here’s the list of certificates: https://misissued.com/batch/4/
>> > >>
>> > >> Jonathan
>> > >
>> > > IdenTrust had previously interpreted HTTP to be inclusive of HTTPS in
>> this
>> > > context.  That being said, we have altered our profiles for
>> certificates
>> > > issued under this Sub CA to include only HTTP OCSP URLs.  All
>> certificates
>> > > issued going forward will contain an HTTP OCSP URL.  We will also
>> examine all
>> > > other sub CA to ensure only HTTP OCSP URLs are included.  Thank you
>> for giving
>> > > us an opportunity to address this with the community
>> >
>> > Thanks for the update.
>> >
>> > Can you also clarify why the subject organizationName is "U.S.
>> Government” for all of these certificates, despite the other subject
>> fields
>> indicating organizations that are not a component of the US Government?
>> >
>> > Jonathan
>>
>> Yes,
>> IdenTrust ACES SSL Certificates are issued in accordance with the ACES
>> certificate policy defined by U.S. General Service Administration (
>> http://csrc.nist.gov/groups/ST/crypto_apps_infra/csor/docum
>> ents/ACES-CP-v3-2_signed_05122017.pdf) and the GSA approved IdenTrust CPS
>> (https://secure.identrust.com/certificates/policy/aces/IdenT
>> rust_ACES_CPS_v5.1_20161110.pdf)
>> These ACES SSL certificates are issued to either U.S. Government agencies
>> and/or their sub-contractors in support of government programs\projects.
>> The
>> CP requires an approved CA, such as IdenTrust, to identify U.S. Government
>> in
>> subject organizationName along with other applicable organizations (e.g.
>> sub-contractors, or local government agency, etc...).
>>
>
> If that's the case, I would expect each certificate to be authenticating
> hostnames that are used solely to provide such services to the U.S.
> Government. That doesn't appear to be the case with these.
>
> For example, one of them is for the homepage for a service provider:
> www.mudiaminc.com

What am I doing wrong?  goto https://www.mudiaminc.com/
check the cert and it says
Issued To
Common Name (CN)*.opentransfer.com
Organization (O)ECOMMERCE, INC.


> And one of them is for what appears to be a state government revenue
> service's VPN: vpn.revenue.louisiana.gov

I see that one - goto https://vpn.revenue.louisiana.gov/
check the cert and it says
Issued To
Common Name (CN)Vpn.revenue.louisiana.gov
Organization (O)U.S. Government

> (So it's clear, "U.S. Government" only refers to the federal government,
> not state/local/tribal governments.)
>
> I personally (and to be clear, this is in my individual capacity and I am
> not representing my employer) think these are invalid organizationNames,
> constitute misissuance, and that Identrust should be using the "U.S.
> Government" only for hostnames providing services operated exclusively on
> behalf of the federal government.

playing devils' advocate: how do you know that
https://vpn.revenue.louisiana.gov/ wasn't set up in collaboration with
the IRS or some other branch of the U.S. Government?

Lee
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Private key corresponding to public key in trusted Cisco certificate embedded in executable

[Lee via dev-security-policy]

On 6/20/17, mfisch--- via dev-security-policy
 wrote:
> On Monday, June 19, 2017 at 7:37:23 PM UTC-4, Matt Palmer wrote:
>> On Sun, Jun 18, 2017 at 08:17:07AM -0700, troy.fridley--- via
>> dev-security-policy wrote:
>> > If you should find such an issue again in a Cisco owned domain, please
>> > report it to ps...@cisco.com and we will ensure that prompt and proper
>> > actions are taken.
>>
>> I don't know, this way seems to have worked Just Fine.
>>
>> - Matt
>
> Does no-one else see the lack of responsible disclosure in this thread
> distressing?

Nope.  The first requirement for "responsible disclosure" is knowing
you're disclosing something.  Take a look at the original msg:
-- I wasn't entirely sure whether this is considered a key compromise. I asked
-- Hanno Böck on Twitter (https://twitter.com/koenrh/status/873869275529957376
-- ), and he advised me to
-- post the matter to this mailing list.
 <.. snip ..>
-- If this is indeed considered a key compromise, where do I go from
here, and what
-- are the recommended steps to take?

If you want to argue that I should have replied with something about
sending the info to ps...@cisco.com instead of just forwarding the 1st
two messages in the thread to them.. yeah, maybe I should have done it
that way.

> Instead -- this was posted to a public forum giving many thousands of people
> the opportunity to chain a vector attack against Cisco CCO IDs (which in
> some cases might lead to customer network compromise).

I'm curious - how does one use a cert for drmlocal.cisco.com to chain
a vector attack against Cisco CCO IDs?

Regards,
Lee
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.5 Proposal: Indicate direction of travel with respect to permitted domain validation methods

[Lee via dev-security-policy]

On 5/1/17, Ryan Sleevi <r...@sleevi.com> wrote:
> On Mon, May 1, 2017 at 1:53 PM, Lee via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> On 5/1/17, Gervase Markham via dev-security-policy
>> <dev-security-policy@lists.mozilla.org> wrote:
>> > The last CA Communication laid down our policy of only permitting the
>> > 10
>> > Blessed Methods of domain validation. A CA Communication is an official
>> > vehicle for Mozilla Policy so this is now policy, but it's not
>> > reflected
>> > in the main policy doc. I was planning to wait until the latest version
>> > of the BRs had all 10 methods in, but that ballot (ballot 190) seems to
>> > be taking a bit of time to draft. So perhaps it would be good to add
>> > language to indicate direction of travel.
>> >
>> > This would involve replacing section 2.2.3 of the policy with:
>> >
>> > "for a certificate capable of being used for SSL-enabled servers, the
>> > CA
>> > must ensure that the applicant has registered the domain(s) referenced
>> > in the certificate or has been authorized by the domain registrant to
>> > act on their behalf. This must be done using one or more of the 10
>> > methods documented in section 3.2.2.4 of version 1.4.1 (and not any
>> > other version) of the CA/Browser Forum Baseline Requirements. The CA's
>> > CP/CPS must clearly specify the procedure(s) that the CA employs, and
>> > each documented procedure should state which subsection of 3.2.2.4 it
>> > is
>> > complying with. Even if the current version of the BRs contains a
>> > method
>> > 3.2.2.4.11, CAs are not permitted to use this method."
>>
>> You seem to be replacing a "meets or exceeds" requirement with a
>> "strictly meets" requirement.
>>
>> I'd suggest something along the lines of
>> The CA MUST use one of the allowed methods of domain validation
>> () and, in addition,
>> MAY use additional and/or stricter methods of domain validation.
>>
>> In other words, make it clear to an auditor that while the CA must
>> meet the baseline requirements, it's not an audit failure if they go
>> above & beyond the minimum requirements of domain validation.
>>
>> Regards,
>> Lee
>
>
> You can only go "above and beyond" if you're implementing those literal 10
> methods. That is, there is a real risk with that MAY that it may be
> interpreted as reintroducing the "Any other method" loophole that's
> explicitly trying to be avoided.
>
> Any CA who is "exceeding" this method strictly meets the definition.

Maybe it's because I've worked with some incredibly bad auditors, but
the way I read the proposal, doing anything other than one of those
exact 10 methods is risking an audit failure.

How would you word the policy to make it clear that while a CA is
required to use one of those 10 methods, the CA is also allowed to do
additional/stricter checks?

Regards,
Lee
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.5 Proposal: Indicate direction of travel with respect to permitted domain validation methods

[Lee via dev-security-policy]

On 5/1/17, Gervase Markham via dev-security-policy
 wrote:
> The last CA Communication laid down our policy of only permitting the 10
> Blessed Methods of domain validation. A CA Communication is an official
> vehicle for Mozilla Policy so this is now policy, but it's not reflected
> in the main policy doc. I was planning to wait until the latest version
> of the BRs had all 10 methods in, but that ballot (ballot 190) seems to
> be taking a bit of time to draft. So perhaps it would be good to add
> language to indicate direction of travel.
>
> This would involve replacing section 2.2.3 of the policy with:
>
> "for a certificate capable of being used for SSL-enabled servers, the CA
> must ensure that the applicant has registered the domain(s) referenced
> in the certificate or has been authorized by the domain registrant to
> act on their behalf. This must be done using one or more of the 10
> methods documented in section 3.2.2.4 of version 1.4.1 (and not any
> other version) of the CA/Browser Forum Baseline Requirements. The CA's
> CP/CPS must clearly specify the procedure(s) that the CA employs, and
> each documented procedure should state which subsection of 3.2.2.4 it is
> complying with. Even if the current version of the BRs contains a method
> 3.2.2.4.11, CAs are not permitted to use this method."

You seem to be replacing a "meets or exceeds" requirement with a
"strictly meets" requirement.

I'd suggest something along the lines of
The CA MUST use one of the allowed methods of domain validation
() and, in addition,
MAY use additional and/or stricter methods of domain validation.

In other words, make it clear to an auditor that while the CA must
meet the baseline requirements, it's not an audit failure if they go
above & beyond the minimum requirements of domain validation.

Regards,
Lee



>
> Once the BRs are back to the way they should be, a few edits to this
> para should normalize the situation.
>
> There is a deadline associated with this change of July 21st 2017;
> traditionally, we communicate deadlines for particular requirements
> out-of-band.
>
> This is: https://github.com/mozilla/pkipolicy/issues/77
>
> ---
>
> This is a proposed update to Mozilla's root store policy for version
> 2.5. Please keep discussion in this group rather than on Github. Silence
> is consent.
>
> Policy 2.4.1 (current version):
> https://github.com/mozilla/pkipolicy/blob/2.4.1/rootstore/policy.md
> Update process:
> https://wiki.mozilla.org/CA:CertPolicyUpdates 
> ___
> 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