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
On Mon, Nov 25, 2019 at 7:10 AM Bowen, James E. wrote:
> DHS is only using Mozilla’s trust store for determining trust. They are
> not using a government-based trust store.
>
>
>
> We talked to Entrust last week. Entrust was creating certificates with “
> entrust.net” as the old way. Recently,
nt certs are more trustworthy than public certs is
> accurate. VA is likely already dependent on the security of public CAs for
> most or all of its public web services already, since anyone who gets a
> publicly trusted cert for a va.gov hostname can use it to intercept
> traffic to that se
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
>> or for the Mozilla program. As you
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
Both :)
Having a new audit per online CA is going to be very expensive and
cause TSPs heavily limit the number of online CAs they have.
Additionally all of these would be point-in-time audits, which only
report on design of controls. Assuming the design is consistent
between CAs, then there is no
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
> > > extended ascii characters. CertLin
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. For example, "It used to take 10 minu
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
Ryan,
Both Gerv and I posted follow up questions almost two weeks ago. I
know you have been busy with CT days. When do you expect to have
answers available?
Thanks,
Peter
On Fri, Feb 10, 2017 at 2:01 AM, Gervase Markham via
dev-security-policy wrote:
> Hi Ryan,
>
> On 09/02/17 19:55, Ryan Hur
On Wed, Feb 22, 2017 at 8:31 PM, Matt Palmer via dev-security-policy
wrote:
> On Wed, Feb 22, 2017 at 10:00:45PM -0500, George Macon via
> dev-security-policy wrote:
>> On 2/22/17 7:30 PM, Gervase Markham wrote:
>> > On Hacker News, Josh Aas writes:
>> > Update: Squarespace has confirmed that the
Rather than what you suggest, I think the following could be high risk:
свiтова-пошта.info.
xn--i--7kcbgb7fdinng1f.info.
гooms17139.link.
xn--ooms17139-uzh.link.
мцяsц.lol.
xn--s-wtb4ab7b.lol.
сaентология.net.
xn--a-ftbfnnlhbvn2m.net.
aμ.net.
xn--a-mmb.net.
μc.net.
xn--c-lmb.net.
ωe.net.
xn-
"auditing standards that underlie the accepted audit schemes found in
Section 8.1"
This is obviously a error in the BRs. That language is taken from
Section 8.1 and there is no list of schemes in 8.1.
8.4 does have a list of schemes:
1. WebTrust for Certification Authorities v2.0;
2. A national
On Mon, Feb 27, 2017 at 1:41 PM, Ryan Sleevi via dev-security-policy
wrote:
> The EV Guidelines require certificates issued for .onion include the
> cabf-TorServiceDescriptor extension, defined in the EV Guidelines, as part of
> these certificates. This is required by Section 11.7.1 (1) of the E
On Sat, Mar 4, 2017 at 12:22 PM, Daniel Cater via dev-security-policy
wrote:
> On Saturday, 4 March 2017 20:14:09 UTC, Jeremy Rowley wrote:
>> 1.0 is not the definitive version any more. As of 2015‐04‐01, Section
>> 6.3.2 prohibits validity periods longer than 39 months.
>>
>
> Thanks for the pr
Ryan,
I appreciate you finally sending responses. I hope you appreciate
that they are clearly not adequate, in my opinion. Please see the
comments inline.
On Mon, Mar 6, 2017 at 6:02 PM, Ryan Hurst wrote:
> First, let me apologize for the delay in my response, I have had a draft of
> this lett
One more question, in addition to the ones in my prior response:
On Mon, Mar 6, 2017 at 6:02 PM, Ryan Hurst wrote:
> rmh: I just attached two opinion letters from our auditors, I had previously
> provided these to the root programs directly but it took some time to get
> permission to release the
On Tue, Mar 7, 2017 at 7:07 AM, Ryan Sleevi via dev-security-policy
wrote:
> On Tue, Mar 7, 2017 at 5:09 AM, Gervase Markham wrote:
>> > 4.1.2
>> > - You link to the "Baseline Requirements" document, but don't define
>> what
>> > a BR audit is. While 4.1.1 lists audit criteria, this ambiguity ma
On Tue, Mar 7, 2017 at 9:27 PM, Ryan Sleevi via dev-security-policy
wrote:
> On Tue, Mar 7, 2017 at 11:23 PM, Jakob Bohm via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
]>
>> For example, an RA whose sole involvement is to receive a daily list of
>> company name/idno/addr
On Wed, Mar 8, 2017 at 5:08 AM, Ryan Sleevi wrote:
>
>
> On Wed, Mar 8, 2017 at 12:57 AM, Peter Bowen via dev-security-policy
> wrote:
>>
>> If the DTP is only performing the functions that Jakob lists, then
>> they only need an auditor's opinion covering thos
On Wed, Mar 8, 2017 at 6:50 AM, Ryan Sleevi wrote:
>
> On Wed, Mar 8, 2017 at 9:23 AM, Peter Bowen wrote:
>
>> > Does this make it clearer the point I was trying to make, which is that
>> > they're functionally equivalent - due to the fact that both DTPs and
>> > sub-CAs
>> > have the issue of mul
Richard,
I'm afraid a few things are confused here.
First, a single CA Operator may have multiple roots in the browser
trust list. Each root may list one or more certificate policies that
map to the EV policy. Multiple roots that follow the same policy may
use the same policy IDs and different
On Wed, Mar 8, 2017 at 10:14 PM, Richard Wang wrote:
> Why we setup one EV OID for all roots is that we use the same policy for all
> EV SSL certificate no matter it is issued by which root. The policy OID is
> unique ID
>
> If Google use the GlobalSign EV OID, and GlobalSign also use this EV OI
That is the Starfield Services EV policy identifier, not the Starfield
EV policy identifier. We clearly call out in section 1.1 of the our
CPS that Starfield Services Root Certificate Authority - G2 is covered
under the CPS.
On Thu, Mar 9, 2017 at 10:29 PM, Richard Wang wrote:
> Good demo, thank
On Thu, Mar 9, 2017 at 11:02 PM, Jakob Bohm via dev-security-policy
wrote:
>
> Of all these, Starfield seems to be the only case where a single CA
> name now refers to two different current CA operators (GoDaddy and
> Amazon). All the others are cases of complete takeover. None are
> cases where
On Mon, Mar 13, 2017 at 6:08 PM, Nick Lamb via dev-security-policy
wrote:
> On Monday, 13 March 2017 21:31:46 UTC, Ryan Sleevi wrote:
>> Are you saying that there are one or more clients that require DigiCert to
>> support Teletext strings?
>
> Can we stop saying Teletext? The X500 series standa
On Fri, Mar 17, 2017 at 8:30 AM, Gervase Markham via
dev-security-policy wrote:
> The URL for the draft of the next CA Communication is here:
> https://mozilla-mozillacaprogram.cs54.force.com/Communications/CACommunicationSurveySample?CACommunicationId=a050S00G3K2
>
> Note that this is a _draf
On Mon, Mar 20, 2017 at 8:36 AM, Gervase Markham via
dev-security-policy wrote:
> On 17/03/17 15:30, Gervase Markham wrote:
>> The URL for the draft of the next CA Communication is here:
>> https://mozilla-mozillacaprogram.cs54.force.com/Communications/CACommunicationSurveySample?CACommunicationId
On Mon, Mar 20, 2017 at 10:43 AM, Jeremy Rowley via
dev-security-policy wrote:
> A) Does your CA have an RA program, whereby non-Affiliates of your company
> perform aspects of certificate validation on your behalf under contract? If
> so, please tell us about the program, including:
>
> * How man
On Mon, Mar 20, 2017 at 4:52 PM Rob Stradling
wrote:
> On 20/03/17 17:07, Peter Bowen via dev-security-policy wrote:
>
> >> B) Your attention is drawn to the cablint and x509lint tools, which you
> >> may wish to incorporate into your certificate issuance pipeline to g
On Thu, Mar 23, 2017 at 12:54 PM, Jakob Bohm via dev-security-policy
wrote:
>
> The above message (and one by Symantec) were posted to the
> mozilla.dev.security.policy newsgroup prior to becoming aware of
> Google's decision to move the discussion to its own private mailing
> list and procedures.
On Fri, Mar 24, 2017 at 9:06 AM, Ryan Sleevi via dev-security-policy
wrote:
> (Wearing an individual hat)
>
> On Fri, Mar 24, 2017 at 10:35 AM, Jakob Bohm via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>>
>> One common scenario that a new wording should allow is a "fully
On Fri, Mar 31, 2017 at 8:18 AM, Gervase Markham via
dev-security-policy wrote:
> On 30/03/17 15:01, Peter Kurrasch wrote:
>> By "not new", are you referring to Google being the second(?)
>> instance where a company has purchased an individual root cert from
>> another company? It's fair enough to
> On Mar 31, 2017, at 6:01 PM, Daniel Baxter via dev-security-policy
> wrote:
>
> On Saturday, April 1, 2017 at 6:27:27 AM UTC+11, Jakob Bohm wrote:
>> Oh, come on, if that's her job title, that's her job title, and at any
>> CA, that is actually an important job that /someone/ should have.
>
On Fri, Mar 31, 2017 at 4:38 PM, Ryan Sleevi via dev-security-policy
wrote:
> On Fri, Mar 31, 2017 at 2:39 PM, Gervase Markham wrote:
>
>> As we continue to consider how best to react to the most recent incident
>> involving Symantec, and given that there is a question of whether it is
>> part of
On Fri, Mar 31, 2017 at 11:39 AM, Gervase Markham via
dev-security-policy wrote:
> As we continue to consider how best to react to the most recent incident
> involving Symantec, and given that there is a question of whether it is
> part of a pattern of behaviour, it seemed best to produce an issue
On Fri, Mar 31, 2017 at 11:39 AM, Gervase Markham via
dev-security-policy wrote:
> As we continue to consider how best to react to the most recent incident
> involving Symantec, and given that there is a question of whether it is
> part of a pattern of behaviour, it seemed best to produce an issue
On Sun, Apr 2, 2017 at 9:36 PM, Ryan Sleevi wrote:
>
> On Sun, Apr 2, 2017 at 11:14 PM Peter Bowen via dev-security-policy
> wrote:
>>
>> On Fri, Mar 31, 2017 at 11:39 AM, Gervase Markham via
>> dev-security-policy wrote:
>> > As we continue to consider
On Mon, Apr 3, 2017 at 12:36 PM, Jakob Bohm via dev-security-policy
wrote:
> On 03/04/2017 19:24, Ryan Sleevi wrote:
>>
>> On Mon, Apr 3, 2017 at 12:58 PM, Jakob Bohm via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>>>
>>>
>>> taking a holiday and not being able to proce
On Mon, Apr 3, 2017 at 1:45 PM, Jakob Bohm via dev-security-policy
wrote:
> On 03/04/2017 21:48, Ryan Sleevi wrote:
>>
>> On Mon, Apr 3, 2017 at 3:36 PM, Jakob Bohm via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>>>
>>>
>>> The assumptions are:
>>>
>>> 0. All relevant r
On Wed, Apr 12, 2017 at 5:57 AM, Ryan Sleevi via dev-security-policy
wrote:
>
> A certificate hash does provide distinct value.
>
> The certificate hash is what is desired. Yes, there could be multiple
> certificates. But within the context of the scope of an audit and a
> 'logical' CA, the audito
On Thu, Apr 13, 2017 at 9:33 AM, douglas.beattie--- via
dev-security-policy wrote:
> On Thursday, April 13, 2017 at 10:49:17 AM UTC-4, Gervase Markham wrote:
>> On 13/04/17 14:23, Doug Beattie wrote:
>> > There is no statement back to scope or corresponding audits. Were
>> > secure email capable
On Wed, May 3, 2017 at 10:52 AM, Kathleen Wilson via
dev-security-policy wrote:
> All,
>
> I think it is time for us to change the domains that we are using for the
> CCADB as follows.
>
> Change the links for...
>
> 1) CAs to login to the CCADB
> from
> https://mozillacacommunity.force.com/
> t
Yes
On Fri, May 5, 2017 at 2:22 AM Rob Stradling
wrote:
> On 05/05/17 04:25, Peter Bowen via dev-security-policy wrote:
> > On Wed, May 3, 2017 at 10:52 AM, Kathleen Wilson via
> > dev-security-policy wrote:
> >> All,
> >>
> >> I think it is time for
1 - 100 of 167 matches
Mail list logo
