On Sat, Jul 4, 2020 at 9:41 PM Peter Gutmann
wrote:
> Ryan Sleevi writes:
>
> >And they are accomodated - by using something other than the Web PKI.
>
> That's the HTTP/2 "let them eat cake" response again. For all intents and
> purposes, PKI *is* the Web PK
On Sat, Jul 4, 2020 at 9:21 PM Peter Gutmann
wrote:
> So the problem isn't "everyone should do what the Web PKI wants, no matter
> how
> inappropriate it is in their environment", it's "CAs (and protocol
> designers)
> need to acknowledge that something other than the web exists and
> accommodate
On Sat, Jul 4, 2020 at 5:32 PM Mark Arnott via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Why aren't we hearing more from the 14 CAs that this affects. Correct me
> if I am wrong, but the CA/B form has something like 23 members?? An issue
> that affects 14 CAs indicate
zilla.org; r...@sleevi.com
> *Subject:* Re: Key-destruction audit web-trust vs. ETSI (RE: SECURITY
> RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder
> Cert)
>
>
>
>
>
>
>
> On Sat, Jul 4, 2020 at 9:17 AM Buschart, Rufus
> wrote:
>
the first time
you're hearing about them, because the CA is responsible for making sure
their Subscribers know about this.
> After wading through this very long chain of messages I see little
> discussion of the impact this will have on end users. Ryan Sleevi, in the
> name o
Pedro: I said I understood you, and I thought we were discussing in the
abstract.
I encourage you to reread this thread to understand why such a response
varies on a case by case basis. I can understand your *attempt* to balance
things, but I don’t think it would be at all appropriate to treat you
On Sat, Jul 4, 2020 at 9:17 AM Buschart, Rufus
wrote:
> Dear Ryan!
>
> > From: dev-security-policy
> On Behalf Of Ryan Sleevi via dev-security-policy
> > Sent: Freitag, 3. Juli 2020 23:30
> > To: Peter Bowen
> > Cc: Ryan Sleevi ; Pedro Fuentes ;
> mozilla-d
On Sat, Jul 4, 2020 at 6:22 AM Pedro Fuentes via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> El viernes, 3 de julio de 2020, 18:18:49 (UTC+2), Ryan Sleevi escribió:
> > Pedro's option is to reissue a certificate for that key, which as you
> p
On Fri, Jul 3, 2020 at 10:49 PM Corey Bonnell via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> > I don’t understand why you’re making a distinction as to CA certificates,
> which are irrelevant with respect to the Delegated Responder profile. That
> is, you’re trying to fi
On Fri, Jul 3, 2020 at 4:19 PM Peter Bowen wrote:
> >> For the certificates you identified in the beginning of this thread,
> >> we know they have a certain level of key protection - they are all
> >> required to be managed using cryptographic modules that are validated
> >> as meeting overall Le
On Fri, Jul 3, 2020 at 10:57 AM Peter Bowen wrote:
> While it may be viewed as best practice to have short lived responder
> certificates, it must not be viewed as a hard requirement for the BRs
> or for the Mozilla program. As you have pointed out previously, a
> browser could make this a requi
On Fri, Jul 3, 2020 at 10:04 AM Arvid Vermote
wrote:
> GlobalSign recognizes the reported security issue and associated risk, and
> is working on a plan to remediate the impacted CA hierarchies with first
> priority on terminating those branches that include issuing CA with private
> keys outside
On Fri, Jul 3, 2020 at 8:06 AM Pedro Fuentes via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Ryan,
> I don’t think I’m failing to see the security problem, but we evidently
> have different perception of the risk level for the particular case of
> internal delegation.
> A
On Fri, Jul 3, 2020 at 6:14 AM clemens.wanko--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> All,
> on behalf of the Accredited Conformity Assessment Bodies council we would
> like to provide the following background information to the guideline
> “Verifying ETSI Audit
Hi Pedro,
I’m not sure how best to proceed here. It seems like we’ve reached a point
where you’re wanting to discuss possible ways to respond to this, as a CA,
and it feels like this should be captured on the bug.
I’m quite worried here, because this reply demonstrates that we’re at a
point where
On Thu, Jul 2, 2020 at 9:32 PM Corey Bonnell via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> For the avoidance of doubt, allow me to state that I'm posting this in an
> entirely personal capacity :)
:)
> The same logic being applied here would say that a Subscriber cer
e
> issue,
> but in the grand scheme of things probably makes the problem worse, as ICAs
> have fairly long lifetimes, and doing so effectively makes the inadvertent
> delegated
> responder certificate unrevokable. So while the compliance problems might
> be
> fixed, it makes
On Thu, Jul 2, 2020 at 7:13 PM Ben Wilson wrote:
> We are concerned that revoking these impacted intermediate certificates
> within 7 days could cause more damage to the ecosystem than is warranted
> for this particular problem. Therefore, Mozilla does not plan to hold CAs
> to the BR requirement
On Thu, Jul 2, 2020 at 6:42 PM Pedro Fuentes via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Does the operator of a root and it’s hierarchy have the right to delegate
> OCSP responses to its own responders?
>
> If your answer is “No”, then I don’t have anything else to sa
On Thu, Jul 2, 2020 at 6:05 PM Pedro Fuentes via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> I understand your rational, but my point is that this is happening in the
> same infrastructure where the whole PKI is operated, and under the
> responsibility of the same operato
On Thu, Jul 2, 2020 at 5:30 PM Pedro Fuentes via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Hello Ryan,
> Thanks for your detailed response.
>
> Just to be sure that we are in the same page. My question was about
> reissuing a new CA using the same key pair, but this imp
On Thu, Jul 2, 2020 at 2:34 PM Pedro Fuentes via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Hello.
> Sorry if this question is incorrect, but I’d like to know if it would
> acceptable that, for CAs that are owned and operated by the same entity
> that the Root, the CA ce
On Thu, Jul 2, 2020 at 1:33 PM Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Threatening distrust over a discussion about applicability of requirements
> seems contrary to Mozilla's open discussion policy, and I don't think that
> should be an answer while
On Thu, Jul 2, 2020 at 1:15 PM Paul van Brouwershaven <
p...@vanbrouwershaven.com> wrote:
> That's not correct, and is similar to the mistake I originally/previously
>> made, and was thankfully corrected on, which also highlighted the
>> security-relevant nature of it. I encourage you to give anot
On Thu, Jul 2, 2020 at 12:51 PM Rob Stradling via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 02/07/2020 17:13, Ryan Sleevi via dev-security-policy wrote:
> > On Thu, Jul 2, 2020 at 11:36 AM Corey Bonnell wrote:
>
> >> If there’s no di
On Thu, Jul 2, 2020 at 11:36 AM Corey Bonnell
wrote:
> >> If a certificate contains both a key usage extension and an extended
>
>key usage extension, then both extensions MUST be processed
>
>independently and the certificate MUST only be used for a purpose
>
>consistent with both ex
On Thu, Jul 2, 2020 at 10:47 AM Corey Bonnell
wrote:
> > No, this isn’t specified/required for Delegated Reaponders (at least,
> by 6960), and the client implementations I looked at did not check.
>
>
>
> From RFC 5280, section 4.2.1.12:
>
> If a certificate contains both a key usage extension an
On Thu, Jul 2, 2020 at 10:34 AM Paul van Brouwershaven via
dev-security-policy wrote:
> I did do some testing on EKU chaining in Go, but from my understand this
> works the same for Microsoft:
>
Go has a bug https://twitter.com/FiloSottile/status/1278501854306095104
The understanding for Micros
On Thu, Jul 2, 2020 at 9:36 AM Corey Bonnell
wrote:
> (Sorry Ryan and Neil for the double-email, I accidentally omitted the list
> on
> the first email)
>
> > As others have rightfully pointed out, if the EKU is present, it is a
> > delegated responder, full stop.
>
> For the certificate to be us
On Thu, Jul 2, 2020 at 8:44 AM Neil Dunbar via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> On 02/07/2020 13:31, Corey Bonnell via dev-security-policy wrote:
> > Wouldn't adding the nocheck extension make the subCA certificate
> irrevocable,
> > thus in the case of a sub
On Wed, Jul 1, 2020 at 11:48 PM Peter Gutmann
wrote:
> Ryan Sleevi via dev-security-policy
> writes:
>
> >Section 4.9.9 of the BRs requires that OCSP Delegated Responders MUST
> include
> >an id-pkix-ocsp-nocheck extension. RFC 6960 defines an OCSP Delegated
> >Re
On Wed, Jul 1, 2020 at 5:05 PM Ryan Sleevi wrote:
> While I'll be looking to create Compliance Incidents for the affected CAs,
>
This is now done, I believe. However, as mentioned, just because a
compliance bug was not filed does not mean that a CA may not be affected;
it may just
I've created a new batch of certificates that violate 4.9.9 of the BRs,
which was introduced with the first version of the Baseline Requirements as
a MUST. This is https://misissued.com/batch/138/
A quick inspection among the affected CAs include O fields of: QuoVadis,
GlobalSign, Digicert, HARICA
On Wed, Jun 24, 2020 at 3:08 PM Kathleen Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> I have updated the following section of the wiki page to incorporate
> feedback that I received from representatives of ACAB'c.
>
>
> https://wiki.mozilla.org/CA/Audit_Statemen
urage CAs to take a
> look and see what they can fix. (Also, comments welcome :-) ).
>
> While I'm here, here's a quick reminder of some other crt.sh features
> relating to CA compliance issues:
> https://crt.sh/ocsp-responders
> https://crt.sh/test-websites
>
On Tue, Jun 2, 2020 at 10:25 PM Paul Walsh via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> I dislike being added to lists as much as the next person. There are
> numerous reasons for what might have happened. Had you setup an address for
> the purpose of contacting them,
On Mon, Jun 1, 2020 at 7:23 PM Kathleen Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> ** Sub Item 3.2 -- Limit re-use of domain name and IP address
> verification to 398 days
> (https://github.com/mozilla/pkipolicy/issues/206)
> 19 CAs responded that they either
Thank you for your update.
This does not appear to answer the questions raised. I would appreciate if
GoDaddy shared a more meaningful response, in line with addressing the
concerns Nick raised, as well as the outstanding matters on the bug.
In particular, this response fails to analyze what went
, 2020 at 2:52 PM Hanno Böck wrote:
> Hi,
>
> On Fri, 22 May 2020 09:55:22 -0400
> Ryan Sleevi via dev-security-policy
> wrote:
>
> > Could you please cite more specifically what you believe is wrong
> > here? This is only a SHOULD level requirement.
>
&
On Fri, May 22, 2020 at 5:12 AM Kurt Roeckx via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Fri, May 22, 2020 at 10:38:34AM +0200, Hanno Böck via
> dev-security-policy wrote:
> > Just reported this to Chunghwa Telecom Co., Ltd.:
> >
> > --
> >
> > I'm contactin
Hanno,
Could you please cite more specifically what you believe is wrong here?
This is only a SHOULD level requirement.
Are you aware of any clients that enforce or even check the mime type for
these requests? I am not, nor am I aware of any issues deviating from the
SHOULD would present.
On Fri
On Tue, May 19, 2020 at 2:22 PM Matthias van de Meent
wrote:
> I agree that for any one bug, this metadata is not anything to make
> decisions over, but when looking over e.g. the last 3 years, you can
> start making more informed guesses on the metadata only. E.g. when you
> find that a CA has co
On Tue, May 19, 2020 at 12:38 PM sandybar497--- via
dev-security-policy wrote:
> I actually submitted this post 6 days ago and was only just approved today..
> is there a lack of resources approving blog posts? just don't see how it's
> helpful when posts show up so late.
It looks like you may
On Tue, May 19, 2020 at 12:35 AM Kyle Hamilton wrote:
>
>
> On Mon, May 18, 2020, 19:46 Ryan Sleevi wrote:
>
>> On Mon, May 18, 2020 at 7:55 PM Kyle Hamilton via dev-security-policy
>> wrote:
>>
>> > Regardless of that potential con, though, there is
On Tue, May 19, 2020 at 5:53 AM Matthias van de Meent <
matthias.vandeme...@cofano.nl> wrote:
> Hi Ryan,
>
> On Tue, 19 May 2020 at 00:47, Ryan Sleevi wrote:
> >
> > Hi Matthias,
> >
> > We're aware of this. Could you explain what issue or issues this
On Mon, May 18, 2020 at 7:55 PM Kyle Hamilton via dev-security-policy
wrote:
> A potential attack without Proof of Possession which PKIX glosses over
> could involve someone believing that a signature on a document combined
> with the non-possession-proved certificate constitutes proof of possessi
Hi Matthias,
We're aware of this. Could you explain what issue or issues this
presents to you?
Understanding that different projects can and do use different
workflows to address their needs, it's not immediately clear to me
what impact, if any, this might have for you, and it's unclear why the
d
On Mon, May 18, 2020 at 11:40 AM Matthew Hardeman via
dev-security-policy wrote:
> A scary example, I know, but StartCom's original system was once described
> as taking the public key data (and they emphasized _only_ the public key
> data) from the CSR. Everything else was populated out-of-band
On Sat, May 16, 2020 at 10:11 AM Kurt Roeckx via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Sat, May 16, 2020 at 10:04:24AM -0400, Andrew Ayer via
> dev-security-policy wrote:
> > On Sat, 16 May 2020 14:02:42 +0200
> > Kurt Roeckx via dev-security-policy
> > wrote:
>
Do you have a copy of the OCSP response?
With such issues, we may need signed artifacts to demonstrate
non-compliance. For example, it shows as revoked via both OCSP and CRL
for me.
On Thu, May 14, 2020 at 4:32 PM sandybar497--- via dev-security-policy
wrote:
>
> On 7 May 2020 at 12:07:07 PM UTC
Did you mean to ask this on the CABF list?
This is
https://github.com/cabforum/documents/issues/179 which I was going to try
to fix in
https://github.com/sleevi/cabforum-docs/pull/12 (aka “spring” cleanup that
is seeking endorsers)
The discussion thread is
https://cabforum.org/pipermail/validatio
On Wed, May 13, 2020 at 9:00 PM Matt Palmer via dev-security-policy
wrote:
> On the contrary, unless there's an override of RFC5280 4.2.2.1 in the BRs
> that I can't find, the requirement of universal access does exist. RFC5280
> 4.2.2.1 says, in relevant part:
>
> "Where the information is avail
On Wed, May 13, 2020 at 12:12 AM Peter Gutmann
wrote:
> Ryan Sleevi writes:
>
> >>Following up on this, would it be correct to assume that, since no-one
> has
> >>pointed out any impact that this had on anything, that it's more a
> >>certificat
On Tue, May 12, 2020 at 11:47 PM Matt Palmer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Tue, May 12, 2020 at 11:37:23PM -0400, Ryan Sleevi wrote:
> > On Tue, May 12, 2020 at 10:30 PM Matt Palmer via dev-security-policy
> > wrote:
> > &
On Tue, May 12, 2020 at 10:30 PM Matt Palmer via dev-security-policy
wrote:
>
> On Tue, May 12, 2020 at 07:35:50AM +0200, Hanno Böck via dev-security-policy
> wrote:
> > After communicating with Microsoft it turns out this is due to user
> > agent blocking, the URLs can be accessed, but not with
On Tue, May 12, 2020 at 10:29 PM Peter Gutmann via dev-security-policy
wrote:
>
> >Just to understand the scope of this, what was the impact on end users?
>
> Following up on this, would it be correct to assume that, since no-one has
> pointed out any impact that this had on anything, that it's mo
Sorry for the delayed reply here, but in the process of being surprised
that there are still CAs with delays > 90 days, I was looking through
historic patterns, and noticed this CA is a repeat from the year prior.
That is, this CA,
https://www.mail-archive.com/dev-security-policy@lists.mozilla.org
On Tue, May 5, 2020 at 12:35 PM sandybar497--- via dev-security-policy
wrote:
>
> I submitted a compromised key report to Sectigo [ssl_ab...@sectigo.com] on 1
> May 2020 at 2:03pm UTC but Sectigo failed to revoke the certificate per
> cab-forum guidelines [4.9.1.1. Reasons for Revoking a Subscri
Thanks. I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1635279
so you can fill in with the fuller set of details requested from
https://wiki.mozilla.org/CA/Responding_To_An_Incident
On Fri, May 1, 2020 at 4:50 PM IdenTrust Inc via dev-security-policy
wrote:
>
> This issue has been corrected
Pedro,
Did you mean Section 3, not Section 4?
Section 4 does not talk about certificate lifetimes at all, but covers
similar long-standing requirements imposed by other root programs
directly. Naturally, the CA Communications doesn't cover the many
existing Mozilla requirements that are also part
On Fri, May 1, 2020 at 12:48 PM Corey Bonnell via dev-security-policy
wrote:
>
> Hi Kathleen,
> Thank you for sending out this notification of the draft survey. I have
> briefly reviewed and would like to ask what is the intent of Item 4 and the
> associated sub-items? The Browser Alignment draf
On Tue, Apr 21, 2020 at 8:24 AM Wojtek Porczyk
wrote:
> This statement, snipped from above:
>
> > This is exactly the sort of case CCADB is supremely positioned to solve,
> > efficiently. In fact, all of these problems can be addressed by CCADB
> > improvements, providing programmatically readabl
On Tue, Apr 21, 2020 at 1:48 AM Matt Palmer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> That ship sailed so very, very long ago, though.
No it hasn’t. These are much easier to remove than to add new dependencies.
We’re already seeing progress in addressing some of t
On Mon, Apr 20, 2020 at 10:04 PM Matt Palmer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> A major difficulty I found in trying to report compromised keys to CAs was
> in finding a reporting address to use. Now, by itself, that could be
> solved
> by making CCADB repor
On Sun, Apr 19, 2020 at 5:41 PM Ben Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Recently at least one CA has expressed concern about Action 3 of Mozilla's
> January 2020 CA Communication [3]
What CA?
Transparency seems essential here, for the community, for
On Sun, Apr 19, 2020 at 6:13 AM Nick Lamb wrote:
> It's possible that I'm confused somehow, but for me §9.16.3 of the BRs
> does not have numbered item 5, and neither this nor §9.6.1 define
> "contractual jeopardy" nor do they clear up why a subscriber would want
> to shut down their service and
On Sat, Apr 18, 2020 at 6:39 PM Nick Lamb via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> What does "contractual jeopardy" mean here?
The Baseline Requirements address this. See 9.16.3 (particularly item 5)
and 9.6.1 (6).
For better or worse, the situation is as Neil d
On Thu, Apr 16, 2020 at 4:09 PM Tim Hollebeek
wrote:
> On the other hand, for example in Shanghai, some
> have argued that there is nothing wrong with a CPS that does not disclose
> anything
> about how CAs implement any of the policy requirements.
Understandably, it's a spectrum. For these sort
On Tue, Apr 14, 2020 at 8:13 PM Robin Alden wrote:
> I am ambivalent to the idea of having a list of business practices,
> presumably over and above those required in law, that CAs must publish to
> the community.
I know it was more an aside, but I’m not sure I follow what you mean by
“over an
On Mon, Mar 16, 2020 at 5:06 PM Tim Hollebeek via dev-security-policy
wrote:
>
>
>
> 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 h
On Mon, Mar 30, 2020 at 5:32 PM Matt Palmer via dev-security-policy
wrote:
> Righto, the goals are:
>
> * Make it a policy violation for CAs to issue a certificate using a public
> key they've revoked before.
>
> * Clarify the language around key compromise revocation to make it obvious
> that
On Tue, Mar 31, 2020 at 4:46 PM Sándor dr. Szőke via
dev-security-policy wrote:
>
>
> > - Microsec will review the CA software looking for possible similar
> > problems - deadline 2020-03-31
>
>
> Microsec has completed a detailed review of the automatic controls built into
> the CA software. Th
On Mon, Mar 30, 2020 at 5:43 PM Matt Palmer via dev-security-policy
wrote:
>
> On Mon, Mar 30, 2020 at 01:48:28PM -0700, Josh Aas via dev-security-policy
> wrote:
> > Matt - It would be helpful if you could report issues like this to the CA
> > in question, not just to mdsp.
>
> Helpful to *whom*
Thanks for starting this!
On Mon, Mar 30, 2020 at 6:28 AM Matt Palmer via dev-security-policy
wrote:
> If such a modification were deemed appropriate for the BRs, I would suggest
> that the following changes would fit the bill. All sections, etc taken from
> version 1.6.7 of the BRs.
Discussing
On Sat, Mar 28, 2020 at 6:39 PM Ian Carroll via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Hi Ryan,
>
> I don't see a reason why any obligation in 9.6.3 is not fulfillable by
> changing the obligation from a subscriber's notification to revoke to the
> CA, to an obligati
Apologies for the delay here. I filed
https://bugzilla.mozilla.org/show_bug.cgi?id=1625322 for this.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
On Thu, Mar 26, 2020 at 4:45 PM Ian Carroll via dev-security-policy
wrote:
>
> Hi all,
>
> A recent thread on CAs using contractual terms to revoke certificates has
> made me want to bring up a topic that I am surprised does not come up more:
> removing the control of revocation from CAs and mov
On Mon, Mar 23, 2020 at 6:18 PM Burton wrote:
> Hi Ryan,
>
> I’m in the believe that CAs are a public service and as such they should
> provide public information regarding their operational status. The
> questions outlined below were open ended to provide CAs flexibility in the
> way they approa
On Mon, Mar 23, 2020 at 3:13 PM Burton via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> CAs,
>
> Please can you give a brief statement regarding these questions below:
>
> a) What’s your operational status at this time?
>
> b) Do you expect in the next six months to mainta
On Mon, Mar 23, 2020 at 2:43 PM Bruce via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Thursday, March 19, 2020 at 2:02:39 AM UTC-4, Matt Palmer wrote:
>
> > 1. *Are* there explicit prohibitions on issuing a certificate for a
> private
> >key which has been previous
On Sun, Mar 22, 2020 at 10:03 PM Stephen Davidson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Hello:
> (Apologies if multiple copies of this are received. The initial send was
> bounced by mdsp.)
>
> Summary: The certificates noted in Matt Palmer's email below were
On Mon, Mar 23, 2020 at 11:01 AM Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Hey Matt,
>
> Ryan's post was the part I thought was relevant, but I understood it
> differently. The cert was issued, but we should have now revoked it (24
> hours after receiv
On Fri, Mar 20, 2020 at 4:15 PM Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> What about issues other than audits? For example, with certain locations
> closing, key ceremonies may become impossible, leading to downed CRLs/OCSP
> for intermediates. There's
On Fri, Mar 20, 2020 at 4:07 PM Kathleen Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> My question: What should "location" mean in the above requirement?
>
The WebTrust Practitioner Guidance offers a reasonable definition:
https://www.cpacanada.ca/en/business-an
On Thu, Mar 19, 2020 at 7:06 PM Matt Palmer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Thu, Mar 19, 2020 at 12:33:29PM -0400, Ryan Sleevi wrote:
> > I'm not sure an incident report is necessary. The CCADB policy allows
> both
>
Matt,
I'm not sure an incident report is necessary. The CCADB policy allows both
to be provided, and the mechanisms that CCADB uses (both for CAs and for
Root Stores) permit a host of expressiveness (and further changes are being
made).
While there is certainly benefit in highlighting the English
On Thu, Mar 19, 2020 at 9:58 AM Wojtek Porczyk
wrote:
> On Thu, Mar 19, 2020 at 05:30:31AM -0500, Ryan Sleevi via
> dev-security-policy wrote:
> > [...] but given that some negligent and
> > irresponsible CAs kept agitating to reduce revocation requirements than
> > prote
On Thu, Mar 19, 2020 at 1:02 AM Matt Palmer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Since I started requesting revocation for certificates with
> known-compromised private keys, I've noticed a rather disturbing pattern
> emerging in a few cases:
>
> 1. I find a pr
Suggestions:
1) Rename "Audit Delay" to [audit-delay] and rename "Audit Delay COVID-19"
to [audit-delay] [covid-19] or [audit-delay-covid-19], depending
Rationale: In general, our filters work on word searches, so the brackets
brackets help distinguish the two. To search for "Audit Delay" without
c
On Mon, Mar 16, 2020 at 3:12 PM Chris Kemmerer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> > It would appear that SSL.com is a member in good standing of the CA/B
> Forum.
> > Is there any intention on the part of SSL.com to propose this change as a
> > ballot? While
On Mon, Mar 16, 2020 at 11:13 AM Doug Beattie
wrote:
> For clarity, I think we need to discuss all the knobs along with proposed
> effective dates and usage periods so we get the whole picture.
>
I disagree with this framing, as I have pointed out it's been repeatedly
used disingenuously by some
ity remains at 398 days?
>
>
>
> *From:* Ryan Sleevi
> *Sent:* Monday, March 16, 2020 10:02 AM
> *To:* Doug Beattie
> *Cc:* r...@sleevi.com; Kathleen Wilson ;
> mozilla-dev-security-pol...@lists.mozilla.org
> *Subject:* Re: About upcoming limits on trusted certificates
&g
Hi Doug,
Perhaps it got mangled by your mail client, but I think I had that covered?
I've pasted it again, below.
Counter proposal:
April 2021: 395 day domain validation max
April 2021: 366 day organization validation max
April 2022: 92 day domain validation max
September 2022: 31 day domain val
On Sat, Mar 14, 2020 at 2:54 PM Nick Lamb via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Thu, 5 Mar 2020 14:15:17 +
> Nick Lamb via dev-security-policy
> wrote:
>
> > There is some value in policy alone but there's also substantial
> > independent value in writin
https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.6.8.pdf
4.10.2. Service Availability
The CA SHALL operate and maintain its CRL and OCSP capability with
resources sufficient to provide a
response time of ten seconds or less under normal operating conditions.
On Fri, Mar 13, 2020 at 6
On Fri, Mar 13, 2020 at 2:38 PM Doug Beattie via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> When we moved to SHA2 knew of security risks so the timeline could be
> justified, however, I don’t see the same pressing need to move to annual
> domain revalidation and 1 year m
Responses inline.
On Thu, Mar 12, 2020 at 12:46 PM Sándor dr. Szőke via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> > * Microsec issued two certificates in 2018 with 3-year validity periods
> [1].
>
> The certificates were issued for CISCO VPN servers. After receiving th
On Thu, Mar 12, 2020 at 12:46 PM Sándor dr. Szőke via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> So according to the RFC3647 the chapter 1.5.2 shall contain the contact
> person information who is responsible for the management of the CPS,
> but the BR requires, that the
On Thu, Mar 12, 2020 at 10:58 AM Jeremy Rowley
wrote:
> I think this statement is not accurate: "As a result, CAs don’t pursue
> automation, or when they support it, neither promote nor require it." I
> know very few CAs who want to spend extra resources on manual validations
> and just as few wh
The Baseline Requirements allow a number of methods that aren’t easily
automated, such as validation via email. As a result, CAs don’t pursue
automation, or when they support it, neither promote nor require it. This
leads CAs to be opposed to efforts to shorten the reuse time, as they have
historic
101 - 200 of 1416 matches
Mail list logo
