I know where this kind of requirement is coming from ... it's a common
requirement in key management systems, but they generally operate in worlds
that are completely different from the Web PKI. Even there, it often causes
more problems than it solves. I've spent more of my life dealing with the
In the definition of EV TLS Capable, I'd move the last bullet up to the top.
This is because the definition is inherently recursive, and it's easy to
miss that
if the recursion rule isn't first.
For example, I had a question about whether "revoked" meant just the
certificate
itself, or whether a
Ben,
We're concerned that these changes could unintentionally prevent many new
auditors from being able to conduct audits, despite being Qualified Auditors.
The problem is that CAs will understandably be very hesitant to use a new
auditor, as they cannot risk having an audit conducted, and the
So, I'd like to drill down a bit more into one of the cases you discussed.
Let's assume the following:
1. The CAO [*] may or may not have requested removal of the CAC, but removal
has not been completed. The CAC is still trusted by at least one public
root program.
2. The CAO has destroyed the C
So, from our perspective, the security implications are the most important here.
We understand them, and even in the absence of any compliance obligations they
would constitute an unacceptable risk to trustworthiness of our OCSP responses,
so we have already begun the process of replacing the ICAs
Generally, I'm in favor of transparency requirements, and many of Ryan's ideas
would be useful or interesting to pursue. Transparency is often the first and
best
step towards improving business practices. And the entire purpose of a CPS is
to
disclose the business practices that implement a p
> On 3/11/20 3:51 PM, Paul Walsh wrote:
> > Can you provide some insight to why you think a shorter frequency in
> domain validation would be beneficial?
>
> To start with, it is common for a domain name to be purchased for one year.
> A certificate owner that was able to prove ownership/control o
I agree with Corey on this. I was disappointed that the LAMPS discussion two
years ago was not as helpful as it could have been.
For what it's worth, while we generally try to accept any reasonable proof of
key
compromise, we have seen quite a large variety of things sent to us. This
includes
Hello,
I'd like to start a discussion about some practices among other commercial
CAs that have recently come to my attention, which I personally find
disturbing. While it's perfectly appropriate to have Terms and Conditions
associated with digital certificates, in some circumstances, those
Someone really should write up "AIA chasing considered harmful". It was
disputed at the TLS session at IETF 105, which shows that the reasoning
behind it is not as widely understood as it needs to be, even among TLS
experts.
I'm very appreciative of Firefox's efforts in this area. Leveraging the
Subject: Re: DigiCert OCSP services returns 1 byte
On Thu, Sep 19, 2019 at 1:52 PM Tim Hollebeek via dev-security-policy
mailto:dev-security-policy@lists.mozilla.org> > wrote:
I think that's fine as Mozilla and/or the CABF can and should override RFCs
when it makes sense to
> Thanks Wayne. You're right.
>
> (I read the "SHOULD NOT" requirement, forgot it had been superseded, and
> didn't read further. I wonder if it would be reasonable to remove the
> superseded requirement from the BRs now, given that it was superseded over
> 6 years ago?)
Removing out of date req
b Stradling
> >> Sent: Friday, September 13, 2019 4:22 AM
> >> To: Tim Hollebeek ; Jeremy Rowley
> >> ; Alex Cohn
> >> Cc: mozilla-dev-security-pol...@lists.mozilla.org; Wayne Thayer
> >>
> >> Subject: Re: DigiCert OCSP services returns 1 byte
r
>
> Subject: Re: DigiCert OCSP services returns 1 byte
>
> On 12/09/2019 20:48, Tim Hollebeek via dev-security-policy wrote:
> > So, this is something that would be helpfully clarified via either an
> > IETF draft,
>
> There's already a 6962-bis draft [1] in
hat seems like the best starting point.
On Thu, Sep 12, 2019 at 3:49 PM Tim Hollebeek via dev-security-policy
mailto:dev-security-policy@lists.mozilla.org> > wrote:
So, this is something that would be helpfully clarified via either an IETF
draft, or clarifications in the BRs. There ar
So, this is something that would be helpfully clarified via either an IETF
draft, or clarifications in the BRs. There are various things in the OCSP RFCs
and even the BRs that can be read as precluding good OCSP responses for
pre-certificates, although the situation is unclear since the relevan
DigiCert currently has a policy of not publishing the names of those who
report things to us without their permission. It just seems like the right
thing to do.
If we do find that people are abusing that protection to selectively harass
people that they personally have issues with, we may need
So, pinning is an extremely complicated topic that I've always wanted to write
a blog post about, but have never had the time to do it. It happens fairly
regularly that we have to assist a company that has painted themselves into a
corner with a poorly thought out pinning scheme.
In my experie
What is the rationale for waiting until March 20th for revocation given that
the issue was noticed on March 7th?
-Tim
> -Original Message-
> From: dev-security-policy
On
> Behalf Of Bruce via dev-security-policy
> Sent: Friday, March 15, 2019 4:59 PM
> To: mozilla-dev-security-pol...@lis
> On 27/02/2019 00:10, Matthew Hardeman wrote:
> > Is it even proper to have a SAN dnsName in in-addr.arpa ever?
> >
> > While in-addr.arpa IS a real DNS heirarchy under the .arpa TLD, it
> > rarely has anything other than PTR and NS records defined.
> >
>
> While there is no current use, and the
> On 2019-01-24 20:19, Tim Hollebeek wrote:
> > I think the assertion that the commonName has anything to do with what
> > the user would type and expect to see is unsupported by any of the
> > relevant standards, and as Rob noted, having it be different from the
> > SAN strings is not in complian
I think the assertion that the commonName has anything to do with what the
user would type and expect to see is unsupported by any of the relevant
standards, and as Rob noted, having it be different from the SAN strings is
not in compliance with the Baseline Requirements. It's also deprecated. I
Here's the article we published on this subject a while ago:
https://www.digicert.com/blog/keeping-subscribers-safe-partner-best-practices/
-Tim
> -Original Message-
> From: dev-security-policy
> On Behalf Of Jeremy Rowley via dev-security-policy
> Sent: Thursday, January 10, 2019 4:47
The problem is that the attackers get to choose the CA they use, so
multi-perspective validation doesn't provide any benefits unless everyone
has to do it.
I brought it up several times at the validation working group and as a
discussion topic at the Shanghai face to face, but unfortunately there
I don't think we've commented on this before, but I'll note that sending an
e-mail
from the e-mail address listed as the contact address on a website is not
one of
the approved methods of showing ownership or control of a website as
specified
in section 3.2.2.4. The approved methods of validating
That may be true, but I don't see any upside for using that date. If you need
to make a minor CPS update in early January for any reason, you now have
additional work.
I think late December policy changes should be avoided as a general rule.
-Tim
> -Original Message-
> From: dev-securit
I agree with you, but December 31 is a particularly horrible compliance
deadline. Perhaps January 31?
-Tim
> -Original Message-
> From: dev-security-policy On
> Behalf Of Wayne Thayer via dev-security-policy
> Sent: Monday, October 22, 2018 6:00 PM
> To: Kathleen Wilson
> Cc: mozilla-
I think blank sections should be disallowed. The entire purpose of "No
stipulation" is to make it clear that the omission of content was intentional.
With regards to some of these sections being useful, I agree that a good CPS
contains more than the minimum content required from the BRs. I per
I think "Not applicable" would be superior to "No stipulation", when
appropriate.
"3.2.2.5. No IP address certificates are issued under this CPS." is even
clearer.
I haven't looked into the implications of this, but perhaps it would be worth
considering not allowing "No stipulation" in CPSs fo
RFC 3647 disagrees:
"Rather, a particular CP or CPS may state "no stipulation" for a component,
subcomponent, or element on which the particular CP or CPS imposes no
requirements or makes no disclosure."
" It is recommended that each and every component and subcomponent be
included in a CP o
Getting the whitelist figured out and workable will take a while. Disclosure
could happen much faster.
And I’m curious why you think it would be unauditable. It seems
pretty straightforward to verify such disclosures.
It think both ideas are worth considering. There’s no reason we hav
Perhaps a simple first step is to mandate disclosure of which information
source was used for validation. Then if someone uses Google Maps or
similar, People Who Pay Attention To Such Things can start a public
discussion about whether the source is a QIIS, and whether the certificate
is mis-issued
I'm glad you added the smiley, because in my experience CAs have rarely, if
ever, have had any discretion in such matters. Nor do we (DigiCert)
particularly want to, to be honest. I prefer clear, open, and transparent
validation rules that other CAs can't play games with.
Whitelisting and dis
> On Thu, 27 Sep 2018 14:52:27 +
> Tim Hollebeek via dev-security-policy
> wrote:
>
> > My personal impression is that by the time they are brought up here,
> > far too many issues have easily predicted and pre-determined outcomes.
>
> It is probably true tha
> The question and concern about QIIS is extremely reasonable. As discussed in
> past CA/Browser Forum activities, some CAs have extended the definition to
> treat Google Maps as a QIIS (it is not), as well as third-party WHOIS services
> (they’re not; that’s using a DTP).
It's worth noting that
Speaking for myself ...
My personal impression is that by the time they are brought up here, far too
many issues have easily predicted and pre-determined outcomes.
I know most of the security and key management people for the payment
industry very well [1], and they're good people. The discussio
There have been previous discussions about this very issue at CA/Browser
Forum Validation Working Group meetings (see also draft Ballot 225). I
think it is widely recognized that the rules around QIISs are far too weak
and in need of improvement.
I actually recently asked Kirk to add an item on t
There are lots of useful ways to publish unverified and potentially
inaccurate information.
Putting that information into a certificate signed by a public Certificate
Authority is
not one of them.
By the way, OUs need to be accurate as well, not just "partially verified",
so you might
want to loo
Yeah, but unvalidated "information" is not "informative" in any useful way.
-Tim
> -Original Message-
> From: dev-security-policy
On
> Behalf Of pekka.lahtiharju--- via dev-security-policy
> Sent: Tuesday, August 21, 2018 9:59 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subj
Previous discussions on this list, which all CAs are required to follow,
have made
it clear that either challenge-response or domain validation is sufficient
to meet
Mozilla's policy for e-mail addresses.
Yes, the context was SMIME validation, but I am very troubled to hear that
instead of using t
The BRs indeed do not have many requirements about the validation of email
addresses, but Mozilla policy is much more proscriptive here. See, for
example, the first two items of section 2.2.
These make it pretty clear that unverified addresses are prohibited by
Mozilla policy, and validation of e
The only thing I'm going to say in this thread is that ICANN, registrars,
and registries had two years to figure out how to handle GDPR and email
addresses in WHOIS, and we all know how that turned out.
Maybe we should let them figure out how to handle their existing
responsibilities before we st
Also, I'd like to encourage other CAs to comply with Issue 98 pro-actively,
even if it is not required. We're already in compliance.
-Tim
> -Original Message-
> From: dev-security-policy On
> Behalf Of Tim Hollebeek via dev-security-policy
> Sent: Thursday, A
s captured in Issue 98, this did not result in a normative
change to the CP/CPS.
On Wed, Aug 8, 2018 at 10:22 PM, Tim Hollebeek via dev-security-policy
mailto:dev-security-policy@lists.mozilla.org> > wrote:
IIRC we recently passed a CABF ballot that the CPS must contain instruction
IIRC we recently passed a CABF ballot that the CPS must contain instructions
for submitting problem reports in a specific section of its CPS, in an attempt
to solve problems like this. This winter or early spring, if my memory is
correct.
-Tim
> -Original Message-
> From: dev-security-p
I agree.
I've actually thought about adding definitions of categories of misissuance
to the BRs before. Some of the requirements like revocation are really hard
to write and understand if you don't first categorize all the misissuance use
cases, many of which are very, very different. And just
Yeah, I agree I don’t think it was intended. But now that I am aware of the
issue, I think the crossing workaround per EKU is actually a good thing for
people to be doing. Unless someone can point out why it's bad ...
Might want to give people a little more time to plan and adapt to that chang
Doesn't the "created after January 1, 2019" mean that there is no problem with
old crosses? It would just be a new policy for new crosses as of next year?
-Tim
> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+tim.hollebeek=digicert@lists.mozill
ups.google.com/d/msg/mozilla.dev.security.policy/7AcHi_MgKWE/juHBkWV4CwAJ
[5]
https://groups.google.com/d/msg/mozilla.dev.security.policy/7AcHi_MgKWE/O5rwCV96CwAJ
[6]
https://groups.google.com/d/msg/mozilla.dev.security.policy/7AcHi_MgKWE/lpU2dpl8CwAJ
On Wed, May 23, 2018 at 11:29 AM, Tim H
You’re free to misattribute whatever motives you want to me. They’re not true.
In fact, I would like to call on you yet again to cease speculating and
imputing malicious motives onto well-intentioned posts.
The CAA logging requirements failed in this instance. How do we make them
better?
What that wall of text completely misses is the point I and others have been
trying to make.
The logs have to have enough information so you don’t end up in the situation
Let’s Encrypt is currently, and unfortunately, in. Yes, what they did is
compliant, and that’s exactly what most concern
What precisely was the antecedent of “this” in your message? Re-reading it,
I’m not clear which sentence you were referring to.
The only reasons I can think of for not keeping DNSSEC signed RRs are storage
and/or performance, and we think those concerns should not be the driving force
in lo
> Given the TTLs and the key sizes in use on DNSSEC records, why do you
believe
> this?
DigiCert is not sympathetic to disk space as a reason to not keep sufficient
information
in order to detect misissuance due to CAA failures.
In fact, inspired by this issue, we are taking a look internally at
Ok. My biggest concern is not you guys, who are pretty security conscious,
but whether we need to improve the language to make it more clear that the
logging has to be sufficient so that in the event of a bug in the CAA logic,
it is possible to determine which issued certificates are affected and
> Our logging of the CAA records processed does not provide the case
> information we need to determine whether other issuances were affected by
> this bug.
We put a requirement in the BRs specifically so this problem could not occur:
"The CA SHALL log all actions taken, if any, consistent with i
> On Wednesday, May 16, 2018 at 2:16:14 AM UTC-4, Tim Hollebeek wrote:
> > This is the point I most strongly agree with.
> >
> > I do not think it's at odds with the LAMPS charter for 6844-bis,
> > because I do not think it's at odds with 6844.
>
> Updating 6844 is easy. Just define the tag and
When we debated it last, my predictions were hypothetical.
I wish they had remained hypothetical.
-Tim
From: Wayne Thayer [mailto:wtha...@mozilla.com]
Sent: Wednesday, May 16, 2018 12:33 AM
To: Tim Hollebeek ; mozilla-dev-security-policy
Subject: Re: Bit encoding (AW: Policy 2.6 Proposal
This is the point I most strongly agree with.
-Tim
I do not think it's at odds with the LAMPS charter for 6844-bis, because I do
not think it's at odds with 6844.
smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mail
The usual ANSI/ISO rule is that if you protect a strong key with a weak key,
the
strong key is now weak.
This is true pretty much regardless of your threat model. It is absurdly hard
to
express in terms of auditable requirements, though.
"Your AES-128 key has 112 bits of security because you
> This going to require 19 randomly generated Base64 characters and that does
> not include removing common confused characters which will drive up the
> length a bit more, but if this is what the Mozilla risk assessment came up
> with,
> then we’ll all have to comply. I hope there is a sufficie
I agree with Phillip; if we want email CAA to be a thing, we need to define
and
specify that thing. And I think it should be a thing.
New RFCs are not that hard and need not even be that long.
-Tim
> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+t
My only objection is that this will cause key generation to shift to partners
and
affiliates, who will almost certainly do an even worse job.
If you want to ban key generation by anyone but the end entity, ban key
generation by anyone but the end entity.
-Tim
> -Original Message-
> Fro
I think CAA is and should be HTTPS only until there are clear rules for how it
should work for email, and how to keep web CAA from interfering with email CAA.
E-mail is currently the wild west and that needs to be fixed.
I’m strongly in favor of email CAA, once we get it ‘right’. But there’
to server certificates. The scope of the LAMPS recharter for
6844bis appears too narrow to include this. What is the best path forward?
- Wayne
On Tue, May 15, 2018 at 9:29 AM Tim Hollebeek via dev-security-policy
mailto:dev-security-policy@lists.mozilla.org> > wrote:
Blatantly false. I
Blatantly false. I actually suspect DigiCert might already support CAA for
email. I haven’t double-checked.
-Tim
The only reason that "CAA is HTTPS-only" today is because CAs are not
interested in doing the 'right' thing.
smime.p7s
Description: S/MIME cryptographic signature
_
the
road, with S/MIME BRs, that it didn't actually 'protect' the site operator -
the same way you can't say "Restrict access to these five email addresses" and
then introduce a dozen more 2 years down the road.
On Mon, May 14, 2018 at 11:07 PM, Tim Hollebeek
don't actually think there is any IETF component to this. There can be, but
it's not required to be.
On Mon, May 14, 2018 at 6:20 PM, Tim Hollebeek via dev-security-policy
mailto:dev-security-policy@lists.mozilla.org> > wrote:
There’s an IETF component, but minimum necessa
There’s an IETF component, but minimum necessary standards for email
certificate issuance is a policy issue, not a technical one.
Somewhere, it needs to say “CAs issuing e-mail certificates MUST check CAA in
accordance with CAA-bis.”
-Tim
With CABF governance reform coming into effect
> Today this is a "non-issue" because nothing is obligating CAs to respect
> CAA,
> and thus they can (and are) doing the thing that helps them issue more
> certificates (and, presumably, make more money) - but that doesn't
> necessarily
> mean its the right thing.
I can think of at least one C
Yes, but as you correctly point out, this should be taken care of as part of
the CAA-bis
effort. The original RFC had enough errors with respect to web certificates; I
think
it would be irresponsible to apply it to e-mail certificates right now without
carefully
considering the consequences.
W
For the record, I posted someone else's strength testing algorithm, and pointed
out that it was bad 😊 I personally don't think building strength testing
algorithms
is hopeless, and I think good ones are very useful. I tend to agree with the
current
NIST recommendation, which is to primarily o
> Maybe you want n = 112 / 8 = 14 bytes.
Doh! Yes.
-Tim
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
It has generally been understood that a string still "contains at least 112
bits of output from a CSPRNG" if that string has been fed through an
encoding mechanism like Base64 or Base32.
Furthermore, explicit requirements about including mixed case or special
characters leads to some very, very ba
> I'd recommend making a requirement that it be "protected" by at least as
many
> bits of strength as the key it protects. Not doing so could cause
compliance
> issues: things like PCI [1] and the NIST [2] recommendations require this
type of
> protection.
You don't have compliance problems becau
I get that, but any CA that can securely erase and forget the user’s
contribution to the password and certainly do the same thing to the entire
password, so I’m not seeing the value of the extra complexity and interaction.
-Tim
From: Ryan Hurst [mailto:ryan.hu...@gmail.com]
Sent: Tuesday
OOB passwords are generally tough to integrate into automation, and if the
channel really is “secure” then they might not be buying you anything,
depending where the “secure” channel starts and ends and how it is
authenticated.
That might not be a GOOD reason to allow it, but it is the one r
Once again, CSPRNGs are not overkill. They are widely available in virtually
every
programming language in existence these days. I have never understood why
there is so much pushback against something that often appears near the top of
many top ten lists about basic principles for secure coding
zilla-dev-security-policy
> Subject: RE: "multiple perspective validations" - AW: Regional BGP hijack
of
> Amazon DNS infrastructure
>
> On Mon, 30 Apr 2018, Tim Hollebeek via dev-security-policy wrote:
>
> >> I don't think this opinion is in conflict wi
32 bits is rather ... low.
> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+tim.hollebeek=digicert@lists.mozilla.org] On Behalf Of Buschart,
> Rufus via dev-security-policy
> Sent: Monday, April 30, 2018 2:25 AM
> To: mozilla-dev-security-policy
> I don't think this opinion is in conflict with the suggestion that we
> required
> DNSSEC validation on CAA records when (however rarely) it is deployed. I
> added this as https://github.com/mozilla/pkipolicy/issues/133
One of the things that could help quite a bit is to only require DNSSEC
v
> > which is why in the near future we can hopefully use RDAP over TLS
> > (RFC
> > 7481) instead of WHOIS, and of course since the near past, DNSSEC :)
>
> I agree moving away from WHOIS to RDAP over TLS is a good low hanging fruit
> mitigator once it is viable.
My opinion is it is viable now,
> Independent of EV, the BRs require that a CA maintain a High Risk
Certificate
> Request policy such that certificate requests are scrubbed against an
internal
> database or other resources of the CAs discretion.
Unless you're Let's Encrypt, in which case you can opt out of this
requirement via
Call me crazy, but for this particular requirement, I think simple sentences
might
be better.
"The audit information MUST be publicly available. An English version MUST
be provided. The English version MUST be authoritative."
-Tim
> -Original Message-
> From: dev-security-policy [mailt
Subject: Re: 825 days success and future progress!
On Mon, Apr 2, 2018 at 2:28 PM, Tim Hollebeek via dev-security-policy
mailto:dev-security-policy@lists.mozilla.org> > wrote:
18 months is not significantly different from 825 days. So there's really
no benefit.
So it sounds
Yes, if we wanted to go to 13 months quickly, we would have gone directly
there. Getting to 13 months quickly is not a goal. That’s not having it both
ways, that having an understanding of how the ecosystem actually works.
The majority of the CAB forum, and not just CAs, but also many brows
18 months is not significantly different from 825 days. So there's really
no benefit.
People have to stop wanting to constantly change the max validity period.
It's difficult enough to communicate these changes to consumers and
customers, and it really drives them nuts. I can only imagine what
I like this one.
It will be very useful as a starting point if we finally get a CABF S/MIME
working
group, which is likely to happen.
-Tim
> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+tim.hollebeek=digicert@lists.mozilla.org] On Behalf Of Wa
The language you quoted from me is a bit imprecise, my apologies.
I was trying to get CAs to disclose previously undisclosed uses of (4). There
are
disclosed uses of (4), including from DigiCert, that haven’t made it into the BR
methods yet, because in the past year, we have failed to pass
My reaction was primarily based on the following suggestion:
"Generally speaking I would insist on the fact that for country CAs, some
kind
of fast tracks should be established because the impact of time losing at
country level is highly expensive."
The answer is, and must be, no.
-Tim
> -
Nobody is blocking any country from advancing. There are no Mozilla rules
that prevent any country from having the best CA on the planet. If a bunch
of penguins at McMurdo station run an awesome CA, I'll ask some hard
questions about how they meet the OCSP requirements with their limited
bandwid
You might be interested in the following blog post:
https://www.digicert.com/blog/keeping-subscribers-safe-partner-best-practice
s/
We are continuing to look into whether there are any additional partners or
resellers that are misbehaving. This may indeed be an area where stricter
requirements a
Wow, this is a tough one. I've wanted to write such an extension myself for
quite some time. In fact, I probably would write one or more extensions, if
Mozilla were to allow this, for a variety of use cases.
That said, such extensions are extremely dangerous, and users are just going
to accept
Ryan,
Wayne and I have been discussing making various improvements to 1.5.2
mandatory for all CAs. I've made a few improvements to DigiCert's CPSs in
this area, but things probably still could be better. There will probably be
a CA/B ballot in this area soon.
DigiCert's 1.5.2 has our support em
> OK. I'm researching what approach should be used for the Fedora Linux
> distribution, where a single CA trust list (based on Mozilla's CA trust
> list) is used for the whole system, including Firefox, and other
> applications that
> use other certificate validation logic, like the ones built in
ht now. Therefore I think the essential part of your email is
your agreement that CAs which are persistently low performing need to be
recognized and potentially penalized for the sum total of their behaviors.
Alex
On Tue, Feb 6, 2018 at 8:30 PM, Tim Hollebeek via dev-security-policy
m
actionable - as
“most bad” is more likely to receive sanctions.
On Tue, Feb 6, 2018 at 10:03 PM Tim Hollebeek via dev-security-policy
mailto:dev-security-policy@lists.mozilla.org> > wrote:
Absolutely not. I view the competition as being based as the “most best”.
You cannot get an “
Absolutely not. I view the competition as being based as the “most best”.
You cannot get an “A” (or even A- or B+) without significantly exceeding the
minimum requirements, or demonstrating behaviors and practices that, while not
required, are behaviors Mozilla wants to encourage.
Sticks
Paul,
I understand your frustration. I've read some of the recent threads about
"how long does it take to update a CPS?" and clearly there needs to be
some stronger compliance language in either the BRs or Mozilla policy
("CAs MUST be able to update their CPS within 90 days"). And as you note
(4) "any other method"
On Tue, Jan 30, 2018 at 10:37 AM, Tim Hollebeek via dev-security-policy
mailto:dev-security-policy@lists.mozilla.org> > wrote:
I'm sending this to this list because CAs are required to monitor this list,
and I need to get feedback from smaller
I'm sending this to this list because CAs are required to monitor this list,
and I need to get feedback from smaller and more obscure CAs.
The validation working group is thinking about proposing removal of 3.2.2.5
(4) in the near future. If you are currently using that method to validate
I
1 - 100 of 137 matches
Mail list logo