On Fri, Apr 26, 2019 at 5:39 PM Wayne Thayer wrote:
> This does not, however, address the last part of what Brian proposes -
>> which is examining if, how many, and which CAs would fail to meet these
>> encoding requirements today, either in their roots, subordinates, or leaf
>> certificates.
>>
On Tue, Apr 30, 2019 at 8:51 AM Fotis Loukos wrote:
> Hello Ryan,
>
> On 29/4/19 5:20 μ.μ., Ryan Sleevi via dev-security-policy wrote:
> > On Fri, Apr 26, 2019 at 7:02 PM Wayne Thayer via dev-security-policy <
> > dev-security-policy@lists.mozilla.org> wrote:
> >
On Tue, Apr 30, 2019 at 11:49 AM Fotis Loukos wrote:
> On 30/4/19 6:34 μ.μ., Ryan Sleevi via dev-security-policy wrote:
> > On Tue, Apr 30, 2019 at 8:51 AM Fotis Loukos wrote:
> >
> >> Hello Ryan,
> >>
> >> On 29/4/19 5:20 μ.μ., Ryan Sleevi via dev-s
On Tue, Apr 30, 2019 at 1:10 PM Fotis Loukos wrote:
> I am just arguing that there is no risk involved in having a single
> certificate. I do agree that the model you proposed with the two
> certificates is a model that can be used right now, but I do not see any
> additional risks by having a si
On Thu, May 2, 2019 at 9:14 AM Fotis Loukos wrote:
> The PCA (I am calling it PCA even if it does not follow all the design
> and architecture of RFC5288 PCAs for simplicity's sake) has the
> technical ability to issue both TLS and S/MIME end-entity certs but is
> constrained to issue only SubCAs
On Thu, May 2, 2019 at 6:57 PM Daniel Marschall via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Hello,
>
> I have two improvement suggestions for the page crt.sh.
>
> I often stumble across extentions or other kind of OIDs which are not
> known/named by the system. For ex
On Wed, May 8, 2019 at 6:42 AM Fotis Loukos wrote:
> I agree with you that technically verifiable controls are always better
> than procedural controls, however we are already relying on procedural
> controls for many of the requirements, such as CAA. In addition, this
> specific change can be mo
On Tue, May 7, 2019 at 7:48 PM Wayne Thayer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> To continue to participate in the Mozilla CA program, I recommend that we
> require Certinomis to create a new hierarchy and demonstrate their ability
> to competently operate thei
On Wed, May 8, 2019 at 10:36 PM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> [ Note, I am arguing a neutral position on the specific proposal ]
>
> The common purpose of having an internally secured (managed or on-site)
> CA in a public hierarchy is to have
On Thu, May 9, 2019 at 8:59 AM Han Yuwei via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Hi m.d.s.p
> I have reported a key compromise incident to digicert by contacting
> support(at)digicert.com at Apr.13, 2019 and get replied at same day. But
> it seems like this certif
On Thu, May 9, 2019 at 10:44 PM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 09/05/2019 16:35, Ryan Sleevi wrote:
> > Given that the remark is that such a desire is common, perhaps you can
> > provide some external references documenting how one might go
On Thu, May 9, 2019 at 10:05 PM Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> We checked all the applicable CAA records and found 16 where the CAA record
> would not permit us to issue if we were issuing a new cert today. What we
> are proposing is to revo
On Fri, May 10, 2019 at 3:55 PM Jeremy Rowley
wrote:
> The analysis was basically that all the verification documents are still
> good, which means if we issued the cert today, the issuance would pass
> without further checks (since the data itself is good for 825 days).
> Because of this, custom
On Mon, May 13, 2019 at 1:25 PM Wayne Thayer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> The BRs forbid delegation of domain and IP address validation to third
> parties. However, the BRs don't forbid delegation of email address
> validation nor do they apply to S/MIM
On Wed, May 15, 2019 at 9:28 AM Ryan Hurst via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Pedro,
>
> That scenario is addressed by Wayne proposed change.
>
> That same change does not allow for applications that use GMail or there
> federated authentication providers to
On Wed, May 15, 2019 at 11:52 AM Ryan Hurst via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> I believe the case where Google requests a certificate from the CA is
> accommodated but not the case where SAAS requests a certificate from the CA
> based on the authentication of
On Wed, May 15, 2019 at 1:18 PM Ryan Hurst via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> > I think this bears expansion because I don't think it's been clearly
> > documented what flow you believe is currently permitted today that will
> be
> > prevented tomorrow with
On Wed, May 15, 2019 at 2:10 PM Ryan Hurst via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> > Thanks. I think this is desirable to forbid, as it is insecure, and I
> > believe it's already forbidden, because the process of step (4) is
> relying
> > on GMAIL to act as a Del
On Fri, May 17, 2019 at 1:21 AM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 17/05/2019 01:39, Wayne Thayer wrote:
> > On Thu, May 16, 2019 at 4:23 PM Wayne Thayer
> wrote:
> >
> > I will soon file a bug requesting removal of the “Certinomis - Root CA”
>
On Thu, May 9, 2019 at 4:48 PM Brian Smith wrote:
> On Fri, Apr 26, 2019 at 11:39 AM Wayne Thayer wrote:
>
>> On Wed, Apr 24, 2019 at 10:02 AM Ryan Sleevi wrote:
>>
>>> Thank you David and Ryan! This appears to me to be a reasonable
>>> improvement to our policy.
>>>
>>
>> Brian: could I ask yo
On Tue, May 21, 2019 at 3:32 PM Daniel McCarney wrote:
>
>> Of the 8 unrevoked, they're all issued by a single CA - GlobalSign - and
>> are all RSA keys that lack the explicit NULL parameter, and thus violate
>> the requirements of https://tools.ietf.org/html/rfc3279#section-2.3.1
>
>
>> These ar
On Wed, May 22, 2019 at 7:43 PM Brian Smith wrote:
> Ryan Sleevi wrote:
>
>>
>>
>>> It would be easier to understand if this is true if the proposed text
>>> cited the RFCs, like RFC 4055, that actually impose the requirements that
>>> result in the given encodings.
>>>
>>
>> Could you clarify,
On Mon, May 27, 2019 at 4:34 AM Matt Palmer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Hi everyone,
>
> In pondering ways of getting yet more keys for pwnedkeys.com, my mind
> turned
> to everyone's favourite bug, Heartbleed. Whilst hitting all the vulnerable
> serv
On Monday, May 27, 2019, Matt Palmer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Mon, May 27, 2019 at 06:06:42AM +0300, Ryan Sleevi wrote:
> > On Mon, May 27, 2019 at 4:34 AM Matt Palmer via dev-security-policy <
> > dev-security-policy@lists.mozilla.org> wrote:
>
On Tue, May 28, 2019 at 1:03 PM Nick Lamb via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> If they shove an valid but nonsensical policy OID into a cert I don't know
> what Mozilla policy about that would be, but certainly the browser and
> common TLS clients will just ign
I agree with Corey.
On Wed, Jun 12, 2019 at 4:28 AM Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> That argument applies to every extension not expressly permitted by the
> BRs.
Yup. It definitely puts the onus on the CA to demonstrate how they're not
vi
On Thu, Jun 13, 2019 at 2:04 AM kirkhalloregon--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Jeremy is correct - including strongly verified registered trademarks via
> extensions in EV certs is permitted (i.e., not forbidden) by BR Section
> 7.1.2.4.
It's unclear
On Fri, Jun 14, 2019 at 4:12 PM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> In such a case, there are two obvious solutions:
>
> A. Trademark owner (prompted by applicant) provides CA with an official
>permission letter stating that Applicant is explici
On Fri, Jul 5, 2019 at 8:04 PM Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> I think my biggest concern is that there hasn't actual been any proof that
> this would mislead relying parties. You'd actual have to have Mozilla do
> something with it first.
On Tue, Jul 9, 2019 at 5:50 PM Kathleen Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> All,
>
> There is some confusion about disclosure of new intermediate certs that
> are issued to subordinate CAs with currently valid audit statements.
>
> Section 5.3.2 of Mozi
On Wed, Jul 10, 2019 at 12:29 PM fabio.pietrosanti--- via
dev-security-policy wrote:
> Said that, given the approach that has been following with DarkMatter
> about "credible evidence" and "people safety" principles, i would strongly
> argue that Mozilla should take action against the subject pre
On Wed, Jul 10, 2019 at 1:07 PM Nadim Kobeissi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> I would like to support the statements made by both Fabio and Scott to the
> extent that if Mozilla is to go forward with this decision, then I fully
> expect them to review the
On Wed, Jul 10, 2019 at 2:15 PM Nadim Kobeissi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Indeed I would much rather focus on the rest of the elements in the Mozilla
> Root Store Policy (
>
> https://www.mozilla.org/en-US/about/governance/policies/security-group/cert
On Wed, Jul 10, 2019 at 2:41 PM housley--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> People find logos very helpful. That is why many browsers display a tiny
> logo in the toolbar.
>
Are you talking the favicon? An attacker controlled resource which should
not be
On Wed, Jul 10, 2019 at 3:17 PM Nadim Kobeissi
wrote:
> Many times in this discussion, we have all been offered a choice between
> two paths. The first path would be to examine difficult problems and
> shortcomings together and attempting to present incremental--often
> onerous--improvements. The
Alternatively:
There is zero reason these should be included in publicly trusted certs
used for TLS, and ample harm. It is not necessary nor essential to securing
TLS, and that should remain the utmost priority.
CAs that wish to issue such certificates can do so from alternate
hierarchies. There
ue to
> remote issuance)..
>
> I think this is section you are citing as prohibiting issuance correct? So
> as long as the CA can show that this is not true, then issuance is
> permitted under the current policy.
>
>
>
> -Original Message-----
> From: dev-security-pol
Thanks for mentioning this here.
Could you explain why you see it as an issue? RFC 5280 defines a trust
anchor as a subject and a public key. Everything else is optional, and the
delivery of a trust anchor as a certificate does not necessarily imply the
constraints of that certificate, including e
On Sun, Jul 14, 2019 at 8:32 PM Vincent Lours via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Monday, 15 July 2019 04:41:12 UTC+10, Ryan Sleevi wrote:
> > Thanks for mentioning this here.
> >
> > Could you explain why you see it as an issue? RFC 5280 defines a trust
>
For the easiest one first: with respect to the GoDaddy disclosure [1 (your
#2)], I can't see either certificate being disclosed in the audit report.
That definitely sounds like a clear and obvious incorrect disclosure - but
perhaps I'm missing something?
With respect to the Sectigo disclosure [2 (
On Wed, Jul 17, 2019 at 8:09 PM Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Just FYI, there is an upcoming change in control event that will happen at
> DigiCert where TA and Clearlake will take equity ownership of the company.
> TA is currently a minori
(In a personal capacity, as normally noted but making sure to extra-note it
here)
Hi Wayne,
It wasn't clear to me from the inclusion request, did Entrust give a reason
for the requested addition? For example, do they plan to stop issuing from
one of the included roots and have it removed?
In gen
On Fri, Jul 26, 2019 at 4:29 PM Bruce via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Friday, July 26, 2019 at 1:45:06 PM UTC-4, Ryan Sleevi wrote:
> > (In a personal capacity, as normally noted but making sure to extra-note
> it
> > here)
> >
> > Hi Wayne,
> >
> > It
On Fri, Aug 2, 2019 at 9:59 AM Doug Beattie
wrote:
> Ryan,
>
> GlobalSign has been thinking along these lines, but it's not clear how
> browsers build their path when a cross certificate is presented to them in
> the TLS handshake.
>
Excellent! Happy to help in any way to make that possible and
Hi Doug,
Unfortunately, it looks like your approach to replying inline completely
destroyed the formatting. I'm unable to follow or determine your responses,
based on your mail client.
You can see both as rich text [1] and plain text [2] that your formatting
makes your responses illegible, to the
Top-posting, to try and reset the legibility on things.
Regarding the definition for "cross-certified intermediate":
Both scenarios you describe are cross-certificates. This is perhaps clearer
with RFC 4158's treatment of it (for which the BR language was borrowed
from), and may not be as obvious
On Wed, Aug 7, 2019 at 6:28 PM Kathleen Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> I have been working towards extending Audit Letter Validation (ALV) to
> intermediate certificate records in the CCADB. This is involving some
> changes.
>
> I added a field to
On Wed, Aug 14, 2019 at 1:16 PM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> EV was originally an initiative to make the CAs properly vet OV
> certificates, and to mark those CAs that had done a proper job.
> EV issuing CAs were permitted to still sell the s
On Tue, Aug 13, 2019 at 11:12 AM Nuno Ponte via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Dear m.d.s.p.,
>
> I would like to bring into discussion the use of certificate/public key
> pinning and the impacts on the 5-days period for certificate revocation
> according to
On Mon, Aug 19, 2019 at 10:26 AM Mathew Hodson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> If these situations were common, it could create a chilling effect on
> problem reporting that would hurt the WebPKI ecosystem. Are specific
> procedures and handling of contact
(Apologies if this triple or quadruple posts. There appears to be some
hiccups somewhere along the line between my mail server and the m.d.s.p.
mail server and the Google Groups reflector)
I've recently shared some choice words with several CAs over their Incident
Reporting process, highlighting t
(Apologies if this double posts; (my || the) e-mail gateway seems to be having
some trouble so I'm trying this through the Google Groups interface)
I've recently shared some choice words with several CAs over their Incident
Reporting process, highlighting to them how their approach is seriously
(Apologies if this triple or quadruple posts. There appears to be some
hiccups somewhere along the line between my mail server and the m.d.s.p.
mail server)
I've recently shared some choice words with several CAs over their Incident
Reporting process, highlighting to them how their approach is ser
I've recently shared some choice words with several CAs over their Incident
Reporting process, highlighting to them how their approach is seriously
undermining trust in their CA and the operations.
While https://wiki.mozilla.org/CA/Responding_To_An_Incident provides
Guidance on the minimum expecta
On Thu, Aug 22, 2019 at 12:46 AM Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Hey all,
>
> An interesting issue came up recently with audits. Because the Mozilla
> policy includes some requirements that diverge from the BRs, the audit
> criteria don't nec
On Thu, Aug 22, 2019 at 10:29 PM Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> I posted this tonight:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1576013. It's sort of an
> extension of the "some-state" issue, but with the incorporation information
> of
On Fri, Aug 23, 2019 at 2:00 PM Jeremy Rowley
wrote:
>
>
>- Could you highlight a bit more your proposal here? My understanding
>is that, despite the Handelsregister ("Commercial Register") being
>available at a country level, it's further subdivided into a list of
>couunty or reg
On Fri, Aug 23, 2019 at 4:18 PM Jeremy Rowley
wrote:
> > I can think of some incremental steps here:
>
> > - Disclosing exact detailed procedures via CP/CPS
>
>
>
> Maybe an addendum to the CPS. Or RPS. I’ll experiment and post something
> to see what the community thinks.
>
Yup. I've seen plent
On Fri, Aug 23, 2019 at 4:37 PM Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> >> 1. I believe the BRs and/or underlying technical standards are very
>clear if the ST field should be a full name ("California") or an
>abbreviation ("CA").
>
> This is
On Wed, Aug 28, 2019 at 7:13 AM Corey Bonnell via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Anyhow, judging from censys.io, it looks like there are far bigger
> offenders of this particular quirky rule than Digicert and GlobalSign. I'd
> love to know why the BRs/EVGs ar
On Wed, Aug 28, 2019 at 12:36 PM Jeremy Rowley
wrote:
> I've always thought the reason OV/EV ballots haven't been proposed/passed
> is combination of a lack of interest from the browsers and the fact that
> governance reform seems to get in the way of everything else. I've for
> proposed tons of
(Posting in a personal capacity)
On Wed, Aug 28, 2019 at 7:01 PM Kirk Hall via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Most of the comments against EV certificates on this list have been
> focused on whether or not the current Firefox EV UI is relied on by Firefox
>
On Thu, Aug 29, 2019 at 1:15 PM Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Thanks for posting this Curt. We investigated and posted an incident
> report on Bugzilla. The root cause was related to pre-certs and an error in
> generating certificates for
On Thu, Aug 29, 2019 at 2:49 PM Kirk Hall via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Sure, I’m happy to explain, using Bank of America as an example.
Kirk,
Thanks for providing this example. Could you help me understand how it
helps determine that things are safe?
On Thu, Aug 29, 2019 at 5:18 PM Kirk Hall via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> > In this case, the use of EV certificates, and the presumption of
> > reputation, would lead to actively worse security.
> >
> > Did I misunderstand the scenario?
>
> Don't argue wi
On Thu, Aug 29, 2019 at 6:26 PM Kirk Hall via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> > Could you point to the browsing phishing filters and anti-phishing
> services
> > that do? It might be an opportunity for you to find out how they deal
> with
> > this, and report
On Thu, Aug 29, 2019 at 8:23 PM Kirk Hall via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Thursday, August 29, 2019 at 5:07:03 PM UTC-7, Ryan Sleevi wrote:
> > On Thu, Aug 29, 2019 at 6:26 PM Kirk Hall via dev-security-policy <
> > dev-security-policy@lists.mozilla.org
On Thu, Aug 29, 2019 at 8:54 PM Kirk Hall via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> What the heck does it mean when sometimes you say you are posting "in a
> personal capacity" and sometimes you don't?
It sounds like you were very prescient in your inability to re
On Fri, Aug 30, 2019 at 11:26 AM Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Is our answer right though? I wasn't sure. I said "Good" because "a
> promise to issue a cert" could be considered the same issued. In that case
> the BRs say you must respond g
On Fri, Aug 30, 2019 at 12:06 PM Kirk Hall via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> This is super easy, and doesn't even require you to do any work, like
> contacting Google Safe Browsing and asking them to participate in this
> conversation.
>
> Here's the questio
On Mon, Sep 2, 2019 at 2:14 PM Alex Cohn via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Mon, Sep 2, 2019 at 12:42 PM Jakob Bohm via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > If an OCSP server supports returning (or always returns) pro
On Tue, Sep 3, 2019 at 2:18 PM Santhan via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Thursday, August 29, 2019 at 4:37:04 PM UTC-7, Jacob Hoffman-Andrews
> wrote:
> > Also filed at https://bugzilla.mozilla.org/show_bug.cgi?id=1577652
> >
> > On 2019.08.28 we read App
On Wed, Sep 4, 2019 at 9:47 AM Peter Mate, Erdosi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> My question is the following: is it allowed to issue an OCSP Responder
> certificate with "id-kp-OCSPSigning" EKU from a technically constrained CA
> if the "id-kp-OCSPSignin
On Wed, Sep 4, 2019 at 11:06 AM Ben Wilson wrote:
> I thought that the EKU "id-kp-OCSPSigning" was for the OCSP responder
> certificate itself (not the CA that issues the OCSP responder certificate).
> I don't think I've encountered a problem before, but I guess it would
> depend
> on the impleme
Thanks Jeremy,
This is great. I filed https://github.com/mozilla/pkipolicy/issues/188
because this seems like something that can be reused and perhaps even
required by policy.
On Wed, Sep 11, 2019 at 5:59 PM Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
On Thu, Sep 12, 2019 at 11:25 AM Alex Cohn via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Wed, Sep 11, 2019 at 10:09 PM Jeremy Rowley via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > This means, for example, that (i) a CA must provide OC
Without wanting to be antagonistic, I've come to learn I can count on you
to suggest that X deserves clarification because it's ambiguous, but I've
also learned I have trouble learning where the ambiguity exists or why.
Recall that part of this confusion, regrettably, came from an earnest
attempt t
a could add a policy to require exactly that, as the
> proposed addition does. But I'm struggling to see the practical value in
> doing so.
>
> Regards,
> Tim
>
> -Original Message-
> From: dev-security-policy
> On Behalf Of Ryan Sleevi via dev-security-pol
On Mon, Sep 16, 2019 at 3:25 PM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 16/09/2019 19:08, Andrew Ayer wrote:
> > On Fri, 13 Sep 2019 08:22:21 +
> > Rob Stradling via dev-security-policy
> > wrote:
> >
> >> Thinking aloud...
> >> Does anything ne
On Mon, Sep 16, 2019 at 6:59 PM Wayne Thayer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Mon, Sep 16, 2019 at 5:02 AM Rob Stradling wrote:
>
> > On 14/09/2019 00:27, Andrew Ayer via dev-security-policy wrote:
> >
> >
> > If a certificate (with embedded SCTs and n
On Tue, Sep 17, 2019 at 10:00 AM Neil Dunbar via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
>
> > On 17 Sep 2019, at 14:34, Rob Stradling via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> >
> > Hi Kurt. I agree, hence why I proposed:
> >
> >
Thanks for raising this!
There some some slight past discussion in the CA/B Forum on this -
https://cabforum.org/pipermail/public/2013-November/002440.html - as well
as a little during the SHA-1 deprecation discussions (
https://cabforum.org/pipermail/public/2016-November/008979.html ) and
crypto
On Thu, Sep 19, 2019 at 1:52 PM Tim Hollebeek via dev-security-policy <
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 do so, but I think it would also be helpful in
> the long term to fix the dis
On Thu, Sep 19, 2019 at 2:55 PM Tim Hollebeek
wrote:
> I also don’t think it’s helpful to try to redefine long-standing and
> well-understood terminology like what it means to issue a certificate. In
> fact, I just checked, and using a definition like “reserving a serial
> number” causes many of
On Fri, Sep 20, 2019 at 9:58 AM Rob Stradling wrote:
> On 19/09/2019 21:01, Ryan Sleevi wrote:
>
> > It would be helpful for one of the relevant documents, or another
> > document, or even an errata, to clarify that OCSP services can be
> > offered for pre-certificates. It’s merely
I'll share this publicly, so that there's no suggestion that personally or
professionally Google Trust Services is treated any differently than any
other CA. As a publicly trusted CA, I personally find this a deeply
disappointing post towards positive engagement. It's disappointing because
it lacks
On Fri, Sep 20, 2019 at 4:20 PM Curt Spann via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> This is a great discussion and I want to thank everyone for their
> continued input. Let me try and summarize my interpretation based on the
> input from this thread and related RFC
On Thu, Feb 9, 2017 at 3:39 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> Additional issue #2: The information at https://pki.goog/ about how to
> report misissuance directs visitors to a generic reporting page for
> code vulnerabilities, which (by their
On Thu, Feb 9, 2017 at 11:40 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> For clarity, I was pointing out that GTS seems to have chosen a method
> likely to fail if an when actually needed, due to the typical dynamics
> of large human organizations. Pr
On Fri, Feb 10, 2017 at 8:00 AM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> I am trying to say that I use the word "issue" as the weakest category,
> orders of magnitude less serious than an absolute cause for rejection.
And I'm trying to suggest that it
On Mon, Feb 13, 2017 at 8:17 AM, Steve Medin via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Getting all user agents with interest is issuance limits to implement the
> CA Issuers form of AIA for dynamic path discovery and educating server
> operators to get out of the pr
On Mon, Feb 13, 2017 at 11:56 AM, Steve Medin via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Patrick, thanks, it appears my attempt at brevity produced density.
>
> - No amount of mantra, training, email notification, blinking text and
> certificate installation checkers
On Mon, Feb 13, 2017 at 4:48 AM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Hi Steve,
>
> On 12/02/17 15:27, Steve Medin wrote:
> > A response is now available in Bugzilla 1334377 and directly at:
> > https://bugzilla.mozilla.org/attachment.cgi?id=883
On Mon, Feb 13, 2017 at 2:39 PM, Steve Medin
wrote:
> With de facto use of AIA, there is no issuer installation on the server
> that could be improper. Proper is defined at the moment, either by cache or
> discovery hints.
>
I think this may be the crux of our disagreement. I believe that an ide
On Tue, Feb 14, 2017 at 5:47 AM, Steve Medin via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> - The caching I’m talking about is not header directives, I mean
> how CAPI and NSS retain discovered path for the life of the intermediate.
> One fetch, per person, per
On Tue, Feb 14, 2017 at 10:13 AM, Steve Medin via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> I mention P7 because IIS inhales them in one click and ensures that the
> intermediate gets installed.
Yes, but that's not because of PKCS#7, as I tried to explain and capture
Hi Steve,
Two more question to add to the list which is already pending:
In [1], in response to question 5, Symantec indicated that Certisign was a
WebTrust audited partner RA, with [2] provided as evidence to this fact.
While we discussed the concerns with respect to the audit letter,
specifical
On Fri, Feb 17, 2017 at 5:17 PM, urijah--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Friday, February 17, 2017 at 7:50:31 PM UTC-5, uri...@gmail.com wrote:
> > On Friday, February 17, 2017 at 7:23:54 PM UTC-5, Ryan Sleevi wrote:
> > > I have confirmed with CPA
>
Hi Richard,
There's no policies in the Baseline Requirements or Mozilla Requirements
that normalize or define high risk domain, which I believe your suggestion
presupposes.
Perhaps you (or Qihoo 360, as the voting member of the Forum of the
Qihoo/WoSign/StartCom collection) would consider proposi
Hi Richard,
My point was that policy requirement simply states that there needs to be a
procedure, but does not establish any normative requirements. For example,
a CA could develop, maintain, and implement procedures which states that
any certificate that is qualified as High Risk requires Gerv M
701 - 800 of 1146 matches
Mail list logo
