On Sun, Oct 30, 2016 at 11:34 PM, wrote:
> wangs...@gmail.com於 2016年10月31日星期一 UTC+8下午2時22分05秒寫道：
>> 在 2016年10月28日星期五 UTC+8上午8:19:43，Percy写道：
>> > "When facing any requirements of laws and regulations or any demands for
>> > undergoing legal
>> > process of court and other agencies, GDCA must pro
On Wed, Nov 2, 2016 at 8:26 AM, Tom Ritter wrote:
> On 2 November 2016 at 09:44, Jakob Bohm wrote:
>> The only thing that might be a CA / BR issue would be this:
>
> There's been (some) mention that even if a user moves off Cloudflare,
> the CA is not obligated to revoke. I don't agree with that
On Wed, Nov 2, 2016 at 9:38 AM, Jakob Bohm wrote:
> On 02/11/2016 17:08, Peter Bowen wrote:
>>
>> On Wed, Nov 2, 2016 at 8:26 AM, Tom Ritter wrote:
>>>
>>> On 2 November 2016 at 09:44, Jakob Bohm wrote:
>>>>
>>>> The only thing that mi
On Thu, Nov 3, 2016 at 11:28 AM, Jeremy Rowley
wrote:
> This email is intended to gather public and browser feedback on how we are
> handling the transitioning Verizon's customers to DigiCert and share with
> everyone the plan for when all non-DigiCert hosted sub CAs will be fully
> compliant with
> On Nov 5, 2016, at 6:49 AM, Ryan Sleevi wrote:
>
> On Saturday, November 5, 2016 at 2:06:00 AM UTC-7, Gervase Markham wrote:
>> On 04/11/16 21:23, Ryan Sleevi wrote:
>>> If there's concerns about GAs - would it be best to reply on this thread or
>>> start a new one per-CA?
>>
>> If there's m
On Tue, Nov 8, 2016 at 8:18 AM, Gervase Markham wrote:
> Of course, if intermediates aren't disclosed, we can't be certain what
> they are, but crt.sh has a good idea of many of them:
> https://crt.sh/mozilla-disclosures#undisclosed
>
> There is also a list on that page of certs which CAs have dis
On Tue, Nov 8, 2016 at 10:17 AM, Gervase Markham wrote:
> Hi Peter,
>
> On 08/11/16 16:53, Peter Bowen wrote:
>> Can the "undisclosed" list be broken down further into "CA not
>> disclosed at all" versus "missing disclosure of some
>> cross-c
On Tue, Nov 8, 2016 at 11:05 AM, Gervase Markham wrote:
> On 08/11/16 18:25, Peter Bowen wrote:
>> No, the problem is that the Issuer reported their subCA but Salesforce
>> links the audit info to certificates not to CAs. In the above
>> example, there are three different
On Wed, Nov 9, 2016 at 1:58 AM, Gervase Markham wrote:
> So, it is now possible to change Firefox to mandate the presence of
> id-kp-serverAuth for EE server certs from Mozilla-trusted roots? Or is
> there some reason I've missed we can't do that?
Here are some certs that appear to be for server
is, either the CAB Forum should define all certs with anyEKU,
> serverAuth or no EKU as in scope of the BRs or the browsers should require
> an EKU to function.
>
> -Original Message-
> From: dev-security-policy
> [mailto:dev-security-policy-bounces+jeremy.rowley=digice
Given that there is a lack of clarity on when the CABF BRs apply, and
that applicability of the BRs is outside the scope of the BRs, I
propose the following text to clarify and help CAs understand the
expectations of operating a publicly trusted CA.
Thanks,
Peter
Requirements for a CA in the WebP
On Fri, Nov 11, 2016 at 6:03 AM, Dimitris Zacharopoulos
wrote:
> (something weird happened in the reply all. Re-sending).
>
> On 11/11/2016 3:45 μμ, Gervase Markham wrote:
>>
>> On 11/11/16 13:26, Dimitris Zacharopoulos wrote:
>>>
>>> Although this is very helpful so that people can better underst
On Fri, Nov 11, 2016 at 4:42 AM, Gervase Markham wrote:
> Hi Peter,
>
> On 11/11/16 01:42, Peter Bowen wrote:
>> Given that there is a lack of clarity on when the CABF BRs apply, and
>> that applicability of the BRs is outside the scope of the BRs, I
>> propose the fo
On Tue, Nov 8, 2016 at 8:18 AM, Gervase Markham wrote:
> I'd like to take some action about persistent failures to properly
> disclose intermediates. The deadline for this was June, and CAs have had
> a number of reminders, so there's no excuse.
>
> Of course, if intermediates aren't disclosed, we
On Mon, Nov 14, 2016 at 3:46 AM, Gervase Markham wrote:
>
> If this is the only privacy mechanism available for 6962bis, I suspect
> we will see a lot more TCSCs about, particularly if CAs figure out ways
> to mint them at scale within the letter of the BRs and other requirements.
It is very easy
On Mon, Nov 14, 2016 at 7:14 AM, Gervase Markham wrote:
> On 14/11/16 14:00, Peter Bowen wrote:
>> It is very easy to mint TCSCs at scale without violating the letter or
>> the spirit of the BRs and other requirements.
>
> I guess I didn't mean to imply that it was
On Mon, Nov 14, 2016 at 8:51 AM, Jakob Bohm wrote:
> On 14/11/2016 16:31, Peter Bowen wrote:
>>
>> On Mon, Nov 14, 2016 at 7:14 AM, Gervase Markham wrote:
>>>
>>> On 14/11/16 14:00, Peter Bowen wrote:
>>>>
>>>> It is very easy to min
Is there a CSV version of the upcoming root removals report?
https://mozillacaprogram.secure.force.com/CA/UpcomingRootRemovalsReport
Thanks,
Peter
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listin
On Tue, Nov 15, 2016 at 7:25 AM, Kurt Roeckx wrote:
>
> - If it's an enterprise root they need to switch to SHA-2
This is a lot easier said than done for many organizations. Depending
on the CA software this might be a small configuration change or might
involve a very large software upgrade. I
On Tue, Nov 15, 2016 at 3:02 AM, wrote:
>
> Because we misunderstand that we only need to provide the related chapters of
> CP/CPS in English, and non-related sections are not required. We are terribly
> sorry that we misinterpreted your requirement and upload an inconsistent
> CP/CPS in Engli
On Thu, Nov 17, 2016 at 4:38 PM, Matt Palmer wrote:
>> (Note: Key pinning isn't the only advantage to being able to freely operate
>> your own intermediate CA.)
>
> I don't see how freely operating your own intermediate CA is a pre-requisite
> for key pinning, either.
If you don't have your own C
On Sat, Dec 3, 2016 at 9:22 AM, Jakob Bohm wrote:
> On 03/12/2016 09:34, lcchen.ci...@gmail.com wrote:
>>
>> In CA/Browser Forum 34th F2F meeting, the minutes is in
>> https://cabforum.org/2015/03/11/2015-03-11-minutes-of-cupertino-f2f-meeting-34/.
>> Li-Chun Chen (me) of Chunghwa Telecom presente
On Thu, Sep 22, 2016 at 12:57 AM, wrote:
> Peter Bowen於 2016年9月20日星期二 UTC+8下午11時53分29秒寫道：
>> On Fri, Sep 16, 2016 at 2:00 PM, Kathleen Wilson wrote:
>> >
>> > * CA Hierarchy: Diagram of CA Hierarchy: http://grca.nat.gov.tw/
>> > All subordinate C
On Sun, Dec 4, 2016 at 7:26 AM, 王文正 wrote:
> Gervase Markham於 2016年12月4日星期日 UTC+8下午6時27分55秒寫道：
>> On 03/12/16 17:42, Peter Bowen wrote:
>> > As to the inclusion request, I think Mozilla should reject this
>> > request and add a clear rule to the Mozilla CA policy th
> On Jan 18, 2017, at 7:18 AM, Gervase Markham wrote:
>
> On 17/01/17 23:33, Jakob Bohm wrote:
>> How about "_and versions and strong (>= 256 bits) hashes_",
>
> Do people think we need to go this far?
>
> If we do, we'll need them to specify filenames, not just document
> titles. Otherwise, o
On Mon, Jan 23, 2017 at 3:32 PM, Kathleen Wilson wrote:
> Does section 7.1.4.2 of the CA/Browser Forum's Baseline Requirements only
> apply to end-entity certificates?
>
> If yes, where does it specify that in the document?
>
> This has come up in a few CA requests, due to errors we get when we r
On Tue, Jan 24, 2017 at 12:28 AM, Inigo Barreira wrote:
> Yes, I´m also agree. This was also taken into account when writting the ETSI
> standards, and for the CA certs, the minumun is what Peter has indicated
> plus the common name. We indicate that "... shall contain at least the
> following att
On Tue, Jan 24, 2017 at 8:00 AM, Richard Barnes wrote:
> On Tue, Jan 24, 2017 at 10:48 AM, Gervase Markham wrote:
>>
>> This helpful spreadsheet shows that they were removed in Firefox 47 and
>> 51 respectively:
>> https://mozillacaprogram.secure.force.com/CA/RemovedCACertificateReport
>> Althoug
On Tue, Jan 24, 2017 at 8:05 AM, Gervase Markham wrote:
> On 24/01/17 15:48, Peter Bowen wrote:
>> I think it would be completely reasonable for Mozilla to require a
>> commonName in an update to the policy. I thought it was there, but a
>> CA pushed back on a cablint error
While it is very hard to validate the subject content of certificates
outside of DNS names, there are a number of heuristics that may be
useful to trigger a deeper check to ensure that the data is accurate.
A couple of these that I've found useful are:
1) If stateOrProvince or Locality type attri
See notes inline about known cities with numbers in their name.
On Mon, Jan 30, 2017 at 10:39 AM, Peter Bowen wrote:
> While it is very hard to validate the subject content of certificates
> outside of DNS names, there are a number of heuristics that may be
> useful to trigger a deeper
On Tue, Jan 31, 2017 at 5:50 AM, Hubert Kario wrote:
> On Monday, 30 January 2017 23:48:51 CET Peter Bowen wrote:
>> See notes inline about known cities with numbers in their name.
>>
>> On Mon, Jan 30, 2017 at 10:39 AM, Peter Bowen wrote:
>> > While it is ver
https://tools.ietf.org/html/draft-ietf-curdle-pkix-03 needs to move
forward first. It is currently in working group last call.
https://tools.ietf.org/html/rfc8032 is now published, which replaces
I-D.irtf-cfrg-eddsa, so that removes the last dangling reference from
curdle-pkix.
We also need to sor
On Wed, Feb 8, 2017 at 4:28 AM, Gervase Markham wrote:
> On 24/01/17 00:01, Peter Bowen wrote:
>> I agree that the BRs could be clearer, but it seems to me that the
>> only requirements are country and organization name.
>
> Hi Peter,
>
> Can you point me at which
A couple of weeks ago, Google announced Google Trust Services
(https://security.googleblog.com/2017/01/the-foundation-of-more-secure-web.html)
and also announced that they have acquired two roots that are in
Mozilla trust store.
As discussed in this group previously, Mozilla does not have a very
c
On Fri, Oct 18, 2019 at 6:31 PM Peter Gutmann via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Paul Walsh via dev-security-policy
> writes:
>
> >I have no evidence to prove what I’m about to say, but I *suspect* that
> the
> >people at BSI specified “EV” over the use of o
On Sat, Nov 23, 2019 at 1:08 PM O'Donnell, Derek via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> We have a customer at the VA who uses an Entrust root:
> Issuer Entrust
>
> AIA:
> http://nfitestweb.managed.entrust.com/AIA/CertsIssuedToNFIMediumSSPCA.p7c
>
> They are rep
a trusted CA, then the certificate is trusted.
If you provide the full issuer name for the certificate you are referring
to, then it might be possible to determine if you are actually on a
government-only certificate or if you have some other issue.
Thanks,
Peter
>
>
>
>
> *Fr
ice Operations - Infrastructure Operations
>
> VA Office of Information and Technology, IT Operations and Services
>
> Mobile (571) 235-5277
>
>
>
>
>
>
>
> *From:* Eric Mill
> *Sent:* Tuesday, November 26, 2019 4:28 PM
> *To:* Peter Bowen
> *Cc:* Bowen,
Why not use OCSP?
On Wed, Dec 4, 2019 at 3:52 PM Matthew Hardeman via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Not that anyone is presently doing or would do such a thing, but...
>
> Imagine a CA that wanted to offer up a user/browser tracking service to
> their subsc
On Thu, Dec 19, 2019 at 9:23 AM Wayne Thayer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Tue, Nov 26, 2019 at 6:10 PM Nick Lamb via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > On Mon, 25 Nov 2019 14:12:46 -0800
> > Kathleen Wilson vi
On Sat, May 16, 2020 at 8:18 PM Peter Gutmann via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Kurt Roeckx via dev-security-policy
> writes:
>
> >Browsing crt.sh, I found this: https://crt.sh/?id=1902422627
> >
> >It's a certificate for api.pillowz.kz with the public key
Ryan,
I have read through this thread and am also somewhat perplexed.
I want to be clear, I'm posting only for myself, as an individual, not
on behalf of any current or former employers.
On Fri, Jul 3, 2020 at 4:26 AM Ryan Sleevi via dev-security-policy
wrote:
> On Fri, Jul 3, 2020 at 3:24 AM P
On Fri, Jul 3, 2020 at 9:18 AM Ryan Sleevi wrote:
>
>
>
> 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
>>
On Sat, Jul 4, 2020 at 11:06 AM Ryan Sleevi via dev-security-policy
wrote:
>
> On Sat, Jul 4, 2020 at 12:52 PM mark.arnott1--- via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > This is insane!
> > Those 300 certificates are used to secure healthcare information system
On Sat, Jul 4, 2020 at 7:12 PM Matt Palmer via dev-security-policy
wrote:
>
> On Sat, Jul 04, 2020 at 08:42:03AM -0700, Mark Arnott via dev-security-policy
> wrote:
> > I was informed yesterday that I would have to replace just over 300
> > certificates in 5 days because my CA is required by rule
On Sat, Nov 14, 2020 at 2:05 PM Ryan Sleevi via dev-security-policy
wrote:
>
> So, perhaps now that we've had this conversation, and you've learned about
> potentially illegitimate revocations are a thing, but that they were not
> the thing I was worrying about and that you'd misunderstood, perhap
On Sun, Dec 20, 2020 at 9:54 AM Matthew Thompson via
dev-security-policy wrote:
>
> It's not ideal that Google Chrome now states "The connection to this site is
> using a valid, trusted server certificate issued by R3" (desktop) and "Google
> Chrome verified that R3 issued this website's certifi
On Thu, Mar 11, 2021 at 12:01 AM pfuen...--- via dev-security-policy
wrote:
>
> In summary, my understanding is that we can ignore that illustrative control
> of the Webtrust Criteria and that the community is cool with these
> subordinations of CAs with stronger keys (same or different algorith
On Mon, Dec 25, 2017 at 7:10 AM, Adrian R. via dev-security-policy
wrote:
> since it's a webserver running on the local machine and is using that
> certificate key/pair, i think that someone more capable than me can easily
> extract the key from it.
>
> From my point of view as an observer it's
On Thu, Dec 28, 2017 at 10:24 PM, Jakob Bohm via dev-security-policy
wrote:
> After looking at some real certificates both in the browser and on crt.sh, I
> have some followup questions on certificate serial numbers:
>
> 4. If the answers are yes, no, yes, why doesn't cablint flag
> certificates
On Tue, Jan 16, 2018 at 3:45 PM, Wayne Thayer via dev-security-policy
wrote:
> I would like to open a discussion about the criteria by which Mozilla
> decides which CAs we should allow to apply for inclusion in our root store.
>
> Section 2.1 of Mozilla’s current Root Store Policy states:
>
> CAs
On Wed, Jan 17, 2018 at 11:49 AM, Jakob Bohm via dev-security-policy
wrote:
> 4. Selected company CAs for a handful of too-bit-to-ignore companies
> that refuse to use a true public CA. This would currently probably
> be Microsoft, Amazon and Google. These should be admitted only on
> a te
> On Jan 19, 2018, at 7:22 AM, Doug Beattie via dev-security-policy
> wrote:
>
> Many CA’s haven’t complied with the Mozilla requirement to list the methods
> they use (including Google btw), so it’s hard to tell which CAs are using
> method 10. Of the CA CPSs I checked, only Symantec has m
On Sat, Jan 20, 2018 at 8:31 AM, James Burton via dev-security-policy
wrote:
> Approximate date of retirement of RSA-2048?
This is a very broad question, as you don't specify the usage. If you
look at the US National Institute of Standards and Technology's SP
800-57 part 1 rev 4
(http://nvlpubs.
On Thu, Jan 25, 2018 at 1:02 PM, Ryan Sleevi via dev-security-policy
wrote:
> On Thu, Jan 25, 2018 at 3:34 PM, Wayne Thayer wrote:
>
>> On Thu, Jan 25, 2018 at 11:48 AM, Jonathan Rudenberg <
>> jonat...@titanous.com> wrote:
>>
>>> This is a great improvement. I think we should also ask that any C
On Fri, Feb 16, 2018 at 3:34 AM, Kevin Chadwick via
dev-security-policy wrote:
>
> On that subject I think the chromium reported plan to label sites as
> insecure should perhaps be revised to page insecured or something more
> accurate?
Given this group focused on Mozilla, it is likely out of sco
On Wed, Feb 28, 2018 at 9:37 AM, Jeremy Rowley via dev-security-policy
wrote:
> Once we were alerted, the team kicked
> off a debate that I wanted to bring to the CAB Forum. Basically, our
> position is that resellers do not constitute subscribers under the Baseline
> Requirement's definitions (Se
On Wed, Feb 28, 2018 at 11:29 AM, Wayne Thayer via dev-security-policy
wrote:
> On Wed, Feb 28, 2018 at 12:13 PM, timx84039--- via dev-security-policy
> wrote:
>
>>
>> Regarding to our investigation they were only able to send the private
>> keys for those certificates where the CSR / private ke
On Tue, Mar 13, 2018 at 7:19 AM, Kai Engert via dev-security-policy
wrote:
> On 13.03.2018 14:59, Ryan Sleevi wrote:
>> the blog post says, the subCAs controlled by Apple and Google are the
>> ONLY exceptions.
>>
>> However, the Mozilla Firefox code also treats certain DigiCert subCAs
On Tue, Mar 13, 2018 at 7:55 AM, Kai Engert via dev-security-policy
wrote:
> On 13.03.2018 15:35, Ryan Sleevi via dev-security-policy wrote:
>>
>>> Are the DigiCert transition CAs, which are part of the exclusion list,
>>> and which you say are used for "Managed Partner Infrastructure",
>>> strict
On Fri, Mar 23, 2018 at 11:34 AM, Wayne Thayer via dev-security-policy
wrote:
> Recently I've received a few questions about audit requirements for
> subordinate CAs newly issued from roots in our program. Mozilla policy
> section 5.3.2 requires these to be disclosed "within a week of certificate
e?
>
> On Fri, Mar 23, 2018 at 6:18 PM, Peter Bowen wrote:
>>
>> On Fri, Mar 23, 2018 at 11:34 AM, Wayne Thayer via dev-security-policy
>> wrote:
>> > Recently I've received a few questions about audit requirements for
>> > subordinate CAs newly iss
On Mon, Apr 2, 2018 at 5:15 PM, Wayne Thayer via dev-security-policy
wrote:
> On Mon, Apr 2, 2018 at 4:36 PM, Jakob Bohm via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>>
>> While Entrust happens to do this, as a relying party, I dislike frequent
>> updates to CP/CPS d
As far as I know, this has nothing to do with Mozilla policy.
On Mon, Apr 9, 2018 at 10:28 PM westmail24--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> If Mozilla develops an open product, then why are some discussions
> unavailable to users even for reading? (I'm no
I don't think that is true. Remember for OV/IV/EV certificates, the
Subscriber is the natural person or Legal Entity identified in the
certificate Subject. If the Subscriber is using the certificate on a
CDN, it is probably better to have the CDN generate the key rather
than the Subscriber. The
In reviewing a recent CA application, the question came up of what is
allowed in a certificate in data encoded as "TeletexString" (which is
also sometimes called T61String).
Specifically, certlint will report an error if a TeletexString
contains any characters not in the "Teletex Primary Set of Gr
On Sun, Jul 8, 2018 at 2:34 PM Kurt Roeckx wrote:
> On Sun, Jul 08, 2018 at 04:41:27PM -0400, Ryan Sleevi wrote:
> >
> > Is that because you believe it forbidden by spec, or simply unwise?
>
> It's because nobody implements the spec. Those the claim some
> support for it are just broken. I have ye
On Fri, Jul 20, 2018 at 6:39 PM Daymion Reynolds via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> The certificates were identified by analyzing results from both zlint and
> certlint. We also verified all lint findings against current and past BRs.
> We discovered multiple
On Wed, Jul 25, 2018 at 2:08 PM Joanna Fox via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Friday, July 20, 2018 at 9:39:04 PM UTC-7, Peter Bowen wrote:
> > > *Total of 17 certificates issued in 2018 were revoked due to invalid
> > >
Richard,
Unfortunately Gerv is no longer with us, so he cannot respond to this
accusation. Having been involved in many discussions on m.d.s.p and with
Gerv directly, I am very sure Gerv deeply owned the decisions on StartCom
and WoSign. It was by no means Ryan telling Gerv or Mozilla what to do
On Tue, Dec 18, 2018 at 6:52 PM Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Ballot 202 failed. I’m not sure how it’s relevant other than to indicate
> there was definite disagreement about whether underscores were permitted or
> not. As previously mentio
In the discussion of how to handle certain certificates that no longer meet
CA/Browser Forum baseline requirements, Wayne asked for the "Reason that
publicly-trusted certificates are in use" by the customers. This seems to
imply that Mozilla has an opinion that the default should not be to use
"pu
On Thu, Dec 27, 2018 at 8:34 AM Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Thu, Dec 27, 2018 at 11:12 AM Jakob Bohm via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > Yes, you are consistently mischaracterizing everything I
On Thu, Dec 27, 2018 at 12:12 PM Wayne Thayer wrote:
> On Wed, Dec 26, 2018 at 2:42 PM Peter Bowen via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> In the discussion of how to handle certain certificates that no longer
>> meet
&
On Thu, Dec 27, 2018 at 12:53 PM thomas.gh.horn--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> As to why these certificates have to be revoked, you should see this the
> other way round: as a very generous service of the community to you and
> your customers!
>
> Ce
On Thu, Dec 27, 2018 at 9:04 AM Nick Lamb via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Thu, 27 Dec 2018 15:30:01 +0100
> Jakob Bohm via dev-security-policy
> wrote:
>
> > The problem here is that the prohibition lies in a complex legal
> > reading of multiple docum
On Thu, Dec 27, 2018 at 8:43 PM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> 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.
Consider the
On Thu, Jan 24, 2019 at 4:17 AM Buschart, Rufus via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Hello
>
> > -Ursprüngliche Nachricht-
> > Von: Hanno Böck
> > Gesendet: Donnerstag, 24. Januar 2019 12:36
> >
> > On Thu, 24 Jan 2019 11:14:11 + Buschart, Rufus wr
On Thu, Jan 24, 2019 at 7:36 AM Kurt Roeckx via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 2019-01-24 15:41, Rob Stradling wrote:
> >
> > Here's an example cert containing the A-label in the SAN:dNSName and the
> > U-label in the CN. (It was issued by Sectigo, known
On Fri, Jan 25, 2019 at 10:40 AM Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> I mean, it's using an ACE label. That's where Ballot 202 would have
> clarified and required more explicit validation of the ACE labels to
> address the SHOULD NOT from https://to
On Thu, Mar 7, 2019 at 12:09 AM Benjamin Gabriel via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> A fair and transparent public discussion requires full disclosure of each
> participant's motivations and ultimate agenda. Whether in CABForum, or
> Mozilla-dev-security-poli
On Thu, Mar 7, 2019 at 11:45 AM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Currently the Mozilla root program contains a large number of roots that
> are apparently single-nation CA programs serving their local community
> almost exclusively, including by
On Fri, Mar 8, 2019 at 7:55 PM Matthew Hardeman via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Fri, Mar 8, 2019 at 9:49 PM Ryan Sleevi wrote:
>
> > I consider that only a single CA has represented any ambiguity as being
> > their explanation as to why the non-complia
On Mon, Mar 11, 2019 at 10:00 AM Daymion Reynolds via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Glad you agree 64bit serial numbers can have no fixed bits, as a fixed bit
> in a 64 bit serial number would result in less than 64 bits of entropy. If
> you are going to fi
On Thu, Mar 14, 2019 at 4:33 AM Rob Stradling via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 14/03/2019 01:09, Peter Gutmann via dev-security-policy wrote:
>
> > I'd already asked previously whether any CA wanted to indicate publicly
> that
> > they were compliant wi
On Fri, Mar 22, 2019 at 11:51 AM Wayne Thayer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> I've been asked if the section 5.1.1 restrictions on SHA-1 issuance apply
> to timestamping CAs. Specifically, does Mozilla policy apply to the
> issuance of a SHA-1 CA certifica
I support this, as long as Policy CAs meet the same operations standards
and have the same issuance restrictions as root CAs. This would result in
no real change to policy, as I assume roots not directly included in the
Mozilla root store were already considered “roots” for this part of the
policy.
On Thu, Jul 18, 2019 at 11:40 AM Wayne Thayer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Andrew Ayer filed two bugs yesterday that might be worthy of a bit
> of discussion. They both appear to be in reference to root certificates
> included in the Mozilla program tha
On Tue, Aug 13, 2019 at 4:24 AM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> A policy of switching from positive to negative indicators of security
> differences is no justification to switch to NO indication. And it
> certainly doesn't help user understand
On Wed, Aug 14, 2019 at 10:16 AM Jakob Bohm wrote:
> On 14/08/2019 18:18, Peter Bowen wrote:
> > On thing I've found really useful in working on user experience is to
> > discuss things using problem & solution statements that show the before
> and
> > after.
On Thu, Aug 22, 2019 at 1:44 PM kirkhalloregon--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Some have responded there is no research saying EV sites have
> significantly less phishing (and are therefore safer) than DV sites – Tim
> has listed two studies that say ex
On Thu, Aug 29, 2019 at 10:38 AM Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> 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 po
(forking this to a new subject)
On Thu, Aug 29, 2019 at 5: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? To me, it always appears that
On Fri, Aug 30, 2019 at 10:22 AM Kirk Hall via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> I'll just reiterate my point and then drop the subject. EV certificate
> subject information is used by anti-phishing services and browser phishing
> filters, and it would be a los
Ryan,
Thank you for the quick reply. My comments and questions are inline.
On Thu, Feb 9, 2017 at 11:55 AM, Ryan Hurst via dev-security-policy
wrote:
> Peter,
>
> Thank you very much for your, as always, thorough review.
>
> Let me start by saying I agree there is an opportunity for improving t
On Thu, Feb 9, 2017 at 7:41 AM, Gervase Markham via
dev-security-policy wrote:
> On 09/02/17 14:32, Gijs Kruitbosch wrote:
>> Would Mozilla's root program consider changing this requirement so that
>> it *does* require public disclosure, or are there convincing reasons not
>> to? At first glance,
On Thu, Feb 9, 2017 at 9:56 PM, Richard Wang via dev-security-policy
wrote:
> I can't see this sentence
> " I highlight this because we (the community) see the occasional remark like
> this; most commonly, it's directed at organizations in particular countries,
> on the basis that we shouldn't
On Mon, Feb 13, 2017 at 4:14 AM, Gervase Markham via
dev-security-policy wrote:
> On 10/02/17 12:40, Inigo Barreira wrote:
>> I see many "should" in this link. Basically those indicating "should notify
>> Mozilla" and "should follow the physical relocation section".
>
> It may be that this documen
On Wed, Feb 22, 2017 at 7:35 PM, Richard Wang via dev-security-policy
wrote:
> As I understand, the BR 4.2.1 required this:
>
> “The CA SHALL develop, maintain, and implement documented procedures that
> identify and require additional verification activity for High Risk
> Certificate Requests p
201 - 300 of 402 matches
Mail list logo
