Thank you Rob.
On Tue, Oct 9, 2018 at 3:43 AM Rob Stradling via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> "ACTION 6" of Mozilla's September 2018 CA Communication [1] reminded CAs
> of the Mozilla Root Store Policy requirement [2] that
> non-technically-constrained
Thank you Yves. I do not have any other questions, and I do not believe
that any further actions are required.
- Wayne
On Mon, Oct 1, 2018 at 8:07 AM Yves Nullens
wrote:
> Wayne,
>
>
>
> I confirm that the only change following this investment is the update of
> the overview chapter.
>
>
>
>
Yves,
Thank you for bringing this to our attention. Section 8.1 of the Mozilla
Root Store policy [1] applies here. It is not completely clear to me that
50% ownership is a "controlling stake", but even if it is, InfoCert is
already a member of the Mozilla root program by way of its acquisition of
On Fri, Sep 28, 2018 at 12:29 PM Eric Mill wrote:
>
>
> On Thu, Sep 27, 2018 at 5:22 PM Wayne Thayer via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> Visa has filed a bug [1] requesting removal of the eCommerce root from the
>>
The responses to our latest survey are posted on the wiki [1].
I would like to thank all the CAs that responded promptly to the survey. We
have now received responses from all but two CAs:
- Visa - as of Firefox 64 [2], Visa will no longer be a program member.
- Certicamara - I have emailed and
On Tue, Oct 9, 2018 at 12:48 PM Kathleen Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Oh, so rather than trying to define what "No Stipulation" means and when
> it can be used, we could take a different approach -- list the sections
> that cannot contain "No
On Tue, Oct 9, 2018 at 5:30 AM Grabowski Piotr
wrote:
> Hello Wayne,
>
> Please find our comments below:
>
>
> So far the process for modifying policy templates was controlled by only
> one person at the moment. Although these persons
> have an extensive experience in PKI and preparing
Doug,
Responding to your original question, I look at crt.sh and other data
sources for certificate errors when reviewing inclusion requests or doing
other sorts of investigations. I am not currently reviewing the crt.sh
report for misissuance on a regular basis, but maybe I should.
I went
at 1:49 AM Nick Lamb via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Tue, 18 Sep 2018 17:53:34 -0700
> Wayne Thayer via dev-security-policy
> wrote:
>
> > ** EV Policy OID: 2.23.140.1.1
>
> This reminds me of a question I keep meaning to as
:34 -0700
> Wayne Thayer via dev-security-policy
> wrote:
>
> > * The version of the CPS that I initially reviewed (4.0) describes a
> > number of methods of domain name validation in section 3.2.10.5 that
> > do not appear to fully comply with the BRs. This was corrected
I'm disputing the conclusion that is being drawn from Jake's concerns,
rather than the concerns themselves. Primarily, I disagree with the
conclusion that because Google owns a browser with dominant market share
and - due to the substantial contributions they make here - because Google
has
I've held this discussion open for much longer than 3 weeks due to the
qualified audit reports that were received from Camerfirma. Since no
objections to the acquisition have been raised and the audit issues are
being discussed separately [1][2], I would like to close this discussion
and the
Hello Ramiro,
On Tue, Sep 4, 2018 at 3:13 PM Wayne Thayer wrote:
> Thank you for this response Ramiro. I have copied this to the bug [1] and
> have described Mozilla's expectations for point-in-time audits that confirm
> that these issues have been resolved.
>
> [1]
I believe that SHECA has addressed all the concerns raised during the
discussion period. I am now closing the discussion with a recommendation to
approve this inclusion request. Any further comments should be added
directly to the bug [1].
I would like to thank everyone who contributed to this
On Thu, Dec 27, 2018 at 8:22 PM Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> I can't speak for Mozilla here, but I tried to lay out some clear
> expectations:
> 1) This is an extension of an existing incident, rather than treating it as
> an exception to
On Wed, Jan 2, 2019 at 11:32 AM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 02/01/2019 17:17, Wayne Thayer wrote:
> > The options to consider are:
> > 1. Continue with current policy of treating non-disclosure of
> unconstrained
> > intermediates as an
described.
On Tue, Jan 15, 2019 at 4:40 PM Matthew Hardeman
wrote:
>
>
> On Mon, Jan 14, 2019 at 5:45 PM Wayne Thayer via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> > Am I wrong to expect US CAs to be monitoring OFAC sanctions lists
Piotr,
I agree with Ryan and am awaiting your response to Ryan's questions. I am
also awaiting an answer to why KIR did not report this misissuance.
- Wayne
On Fri, Jan 11, 2019 at 10:28 AM Ryan Sleevi wrote:
> I don't think it's reasonable to push the problem to your CA software
> vendor.
>
Hello Piotr,
On Thu, Jan 17, 2019 at 6:23 AM Grabowski Piotr
wrote:
> Hello Wayne,
>
>
>
> I am very sorry for the delay. Please find below our answers to Ryan's
> questions. Regarding the question why we didn't report this misissuance
> of this 1 certificate as separate incident in my opinion
On Fri, Jan 18, 2019 at 10:34 AM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> How does this match the policy that a name constrained intermediate (1st
> intermediate) can be placed in the control of an organization that has
> been validated as controlling
On Mon, Jan 14, 2019 at 9:57 AM Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Mon, Jan 14, 2019 at 11:10 AM tadahiko.ito.public--- via
> dev-security-policy wrote:
>
> > Hi
> >
> > I have question for following case of certificate chain.
> > (root
This request is for inclusion of the Government of Hong Kong, Hongkong
Post, Certizen Hongkong Post Root CA 3 trust anchor as documented in the
following bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1464306
* BR Self Assessment is here:
On Fri, Jan 11, 2019 at 11:51 AM Doug Beattie via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> A few of us have been discussing the usareally.com "issue" recently. In
> case you didn't know, the US Treasure put out a notice that US companies
> must not do business with
On Mon, Jan 14, 2019 at 11:43 PM Matt Palmer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Mon, Jan 14, 2019 at 05:18:18PM -0700, Wayne Thayer via
> dev-security-policy wrote:
> > * Fairly recent misissuance under the currently included Hong Kong
On Mon, Jan 14, 2019 at 5:58 PM David E. Ross via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> I would think that lack of a CP alone would disqualify this root.
>
> Does it? I'm not saying that there is missing information, only that the
document is called a "CPS" rather
Thanks Jeremy.
To be clear, in this case Mozilla policy requires disclosure, but a public
discussion 'resolved with a positive conclusion' is not required because
DigiCert is already a member of our program.
The policy also requires notification of any resulting changes in the
QuoVadis CP or
On Wed, Dec 12, 2018 at 9:13 AM Sándor dr. Szőke via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> Thank you for the detailed answer, I think that the requirement is clear
> for us now.
>
> The misunderstanding was caused by the different usage of the term 'Test
>
I have update the bug [1] and recommended approval of this emSign root
inclusion request.
- Wayne
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1442337
On Tue, Nov 27, 2018 at 10:19 AM Wayne Thayer wrote:
> I've reviewed the updated CPS and these period-of-time audit statements -
> I have
On Sat, Dec 8, 2018 at 12:50 PM pilgrim2223--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> thanks for the suggestions.
>
> We are exploring the OCSP and CRL checks. It has potential.
>
> Have you determined if these applications perform revocations checks, or
if
There are currently no program requirements for roots that have had their
websites trust bit turned off or been removed from NSS, but this is an open
area of concern [1]. When a root is disabled or removed, there is no
protection for Firefox users who haven't updated to a current version, nor
for
My main concern with this request is the misissued certificates identified
by linters that have not been revoked - I have included my comments and
links from the original message below.
It appears that DigiCert is not planning to remediate these certificates -
can a representative from DigiCert
On Sun, Dec 16, 2018 at 11:49 PM please please
wrote:
> I just noticed that Comodo CA has finally posted its incident report in
> https://bugzilla.mozilla.org/show_bug.cgi?id=1492006
>
> Comments:
> - The report suggests that no BR violation occurred because I was not the
> Subscriber to fulfill
Jeremy,
On Wed, Dec 19, 2018 at 10:55 PM Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Done:
>
>
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1515564
>
> Thanks for submitting this.
>
>
> It ended up being about 1200 certs total that we are hearing
On Thu, Dec 20, 2018 at 4:54 PM Matt Palmer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Thu, Dec 20, 2018 at 10:34:21PM +, Jeremy Rowley via
> dev-security-policy wrote:
> > Here’s the first of the companies. Figured I’d do one and see if it has
> the
wrote:
>
>> Can we request removal of these roots now? This seems very similar to the
>> SHA1 situation where CAs requested root removal and then treated the root
>> as
>> private, regardless of the trust in older platforms.
>>
>> -Original Message-
&
On Tue, Dec 11, 2018 at 10:27 AM Hector Martin 'marcan' via
dev-security-policy wrote:
> On 12/12/2018 01.47, Ryan Sleevi via dev-security-policy wrote:
> > Is this new from the past discussion?
>
> I think what's new is someone actually tried this, and found 5 CAs that
> are vulnerable and for
Adding mozilla.dev.security.policy back to this thread per Rob's suggestion:
On Fri, Dec 14, 2018 at 3:27 AM Rob Stradling wrote:
> On 13/12/2018 19:05, Wayne Thayer wrote:
> > Thank you Rob, this is terrific!
>
> Thanks Wayne.
>
> > I would like to ask that all CAs to take a look at this
Since a number of questions and concerns have been raised regarding the
sunset of underscore characters in dNSNames, I would like to summarize
Mozilla’s position on the issue as follows:
In early November, the CA/Browser Forum passed ballot SC12 [1], creating a
sunset period aimed at ending the
On Thu, Dec 13, 2018 at 10:53 AM pedro.wisekey--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Maybe we should set clear grounds on what is verified and how, not only in
> the frequency.
>
> I agree and think that creating piecemeal requirements is a bad idea. The
CAB
Thank you for making this announcement Pedro. This change of legal
ownership is covered by section 8.1 of the Mozilla Root Store Policy,
including the following statement:
If the receiving or acquiring company is new to the Mozilla root program,
it must demonstrate compliance with the entirety of
Reminder: the 3-week discussion period for this request to EV-enable two
DigiCert roots ends next Friday 7-December.
- Wayne
On Fri, Nov 16, 2018 at 5:00 PM Wayne Thayer wrote:
> This request is to enable EV treatment for the DigiCert Assured ID Root CA
> and DigiCert Global Root CA as
er denying EV status to these roots
> / removing (if a decision is made to grant) it?
>
> I realize the goal is to close discussion a month prior to that date, but
> I suspect such guidance about the risk of failing to abide by SC12, and
> failing to revoke by January 15, would be incredibl
On Wed, Dec 5, 2018 at 3:48 AM Dimitris Zacharopoulos via
dev-security-policy wrote:
> On 5/12/2018 10:02 π.μ., Fotis Loukos wrote:
>
> > The proposal was apparently to further restrict the ability of CAs to
> > make exceptions on their own, by requiring all such exceptions to go
> > through the
On Thu, Dec 6, 2018 at 10:36 PM pilgrim2223--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> I need some clarification on something here
>
> 1) Why are legacy certs not being allowed to expire, and instead we are
> being forced to replace in a very short window? We
.On Wed, Dec 5, 2018 at 1:58 PM dr. Sándor Szőke via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> 1./
> How your CA first became aware of the problem (e.g. via a problem report
> submitted to your Problem Reporting Mechanism, a discussion in
>
Thanks for pointing this out Kurt. The Certinomis / Docapost audit report
is now almost one month late. Also, last week the Certinomis representative
informed root programs that he was leaving his post and two others would be
taking his place. I have just emailed the two new representatives and
Hi Nick,
I had been thinking that 119 403-2 was just intended as an attestation
statement template, similar to the WebTrust reporting guidance [1]. Now I
understand that it can include more substantial requirements.
This is certainly not a complete list, but specific to this discussion I
would
This request is to enable EV treatment for the DigiCert Assured ID Root CA
and DigiCert Global Root CA as documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1165472
* BR Self Assessment is here:
https://bug1165472.bmoattachments.org/attachment.cgi?id=8960346
* Summary
The way that we currently handle these types of issues is about as good as
we're going to get. We have a [recently relaxed but still] fairly stringent
set of rules around revocation in the BRs. This is necessary and proper
because slow/delayed revocation can clearly harm our users. It was
On Thu, Nov 15, 2018 at 1:51 PM Ryan Sleevi wrote:
>
> On Wed, Nov 14, 2018 at 10:39 PM Wayne Thayer via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> While I see some small steps being made toward a common understanding of
>> the iss
Update: I heard back from Certinomis quickly. They provided the following
attestation statement from LSTI dated 23-November on the same day. The
audit was conducted back in July, so we still need an explanation from
Certinomis of why it took LSTI so long to provide the report.
Thanks Corey, Ryan, and Jonathan.
In one of the bugs that Ryan created, the CA stated that it's not clear if
or when Mozilla requires revocation of these P-521 certificates. I believe
the answer is that we do not require revocation. Our policy (section 6)
explicitly requires CAs to abide by the
On Mon, Jan 7, 2019 at 6:05 AM Rob Stradling wrote:
> On 02/01/2019 22:40, Wayne Thayer via dev-security-policy wrote:
>
> > Yes, the idea is that CT could remove the need to enforce intermediate
> > disclosures via policy.
>
> Hi Wayne. That seems at odd
Thanks Jeremy. The fact that CertCenter is just a reseller and not an RA
was not obvious to me. To your point, building an insecure website on top
of a CA's API does not strike me as something that we should be terribly
worried about.
I would encourage DigiCert to ask CertCenter to discontinue
KIR recently misissued another (pre-)certificate with an organizationName
field containing too many characters [1]. This is despite being given
specific guidance earlier in this thread on the organizationName attribute
[2]. I have requested a new incident report in the bug [3].
A pre-certificate
I am satisfied with the response to my questions. If no additional comments
are received by Tuesday, 8-January 2019, I will consider this request to
have been "resolved with a positive conclusion" as required by Mozilla
policy section 8.1.
- Wayne
On Fri, Nov 30, 2018 at 2:46 AM Pedro Fuentes
On Wed, Jan 2, 2019 at 7:10 AM Rob Stradling via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 02/01/2019 13:44, info--- via dev-security-policy wrote:
> > El miércoles, 2 de enero de 2019, 12:49:52 (UTC+1), Rob Stradling
> escribió:
> >> On 09/10/2018 23:53, Wayne
On Tue, Sep 11, 2018 at 12:37 AM josselin.allemandou--- via
dev-security-policy wrote:
> Hello,
>
> Thanks Wayne and Devon for your reply.
>
> We took the time to respond because we wanted to verify through an audit
> that the SSL certificate requests processed since September 8th were in
>
Josselin: thank you for filing this incident report, and for your answers
to the questions being asked in this thread.
Please add the incident report to the related bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1485413
I will also ask you to answer the new questions that have been asked to
Thank you Toria.
On Tue, Sep 11, 2018 at 7:32 AM chenxiaotong--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> 在 2018年9月1日星期六 UTC+8上午7:19:49，Wayne Thayer写道：
>
>
> > * The CP/CPS documents contain version histories, but they didn’t
> describe
> > what changed in each
The three week discussion period for this inclusion request has passed with
no comments received. I am now closing
this discussion with a recommendation to approve this request. Any further
comments should be added directly to the bug.
- Wayne
On Thu, Aug 23, 2018 at 3:58 PM Wayne Thayer wrote:
Even though the discussion period has ended, Mozilla will continue to
consider factual information that is submitted as comments here:
https://bugzilla.mozilla.org/show_bug.cgi?id=1325532
Your concern about "without comment and then get approved" may stem from a
misunderstanding of Mozilla's
On Mon, Sep 17, 2018 at 3:19 PM jtness--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> The risk of any given browser vendor also being a Root CA is small as most
> browser vendors do not have the requisite market share to make unilateral
> decisions. Google
I have created a bug and requested a response from Comodo:
https://bugzilla.mozilla.org/show_bug.cgi?id=1492006
As noted, there are no specific requirements regarding how CAs validate
revocation requests in the BRs. Every CA may do this however they choose,
so I don't believe there is any action
On Mon, Sep 17, 2018 at 9:43 AM Wayne Thayer wrote:
> Even though the discussion period has ended, Mozilla will continue to
> consider factual information that is submitted as comments here:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1325532
>
> Your concern about "without comment and then
Thanks everyone for your feedback. The September 2018 CA Communication has
just been sent to all primary points-of-contact for CAs in our program. CAs
have been asked to respond by 30-September. I will also be adding a post to
https://blog.mozilla.org/security/ announcing the survey,
- Wayne
On
On Fri, Sep 7, 2018 at 8:22 AM Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Fri, Sep 7, 2018 at 9:55 AM Bruce via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > On Thursday, September 6, 2018 at 7:44:15 PM UTC-4, Wayne
Visa recently delivered new qualified audit reports for their eCommerce
Root that is included in the Mozilla program. I opened a bug [1] and
requested an incident report from Visa.
Visa was also the subject of a thread [2] earlier this year in which I
stated that I would look into some of the
n Thu, Sep 13, 2018 at 3:26 PM Wayne Thayer via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> Visa recently delivered new qualified audit reports for their eCommerce
>> Root that is included in the Mozilla program. I opened a bug [1] and
>> r
This request is to enable EV treatment for the Identrust Commercial Root CA
1 as documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1339292
* BR Self Assessment is here:
https://bugzilla.mozilla.org/attachment.cgi?id=8964414
* Summary of Information Gathered and
On Tue, Dec 18, 2018 at 3:47 PM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> Removing the "underscore mandatory" and "specific name X_Y mandatory"
> rules
> from deployed systems without introducing security holes takes more than
> the
> 1 month they have
On Thu, Jan 24, 2019 at 8:17 AM Peter Bowen via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> I agree with Rufus. There are really two issues here:
>
> 1) The original reports to the CAs claimed an issue because RFC 5280
> references the original IDNA RFCs (now known as
Brian,
I think we are in agreement that this isn't a desirable addition to our
policy.
On Mon, Apr 1, 2019 at 5:36 PM Brian Smith via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Wayne Thayer via dev-security-policy <
> dev-security-policy@lists.mozil
Thank you for the report Will and for the tracking info Rob.
It appears that all but one of these certificates is currently revoked, but
roughly 5 more weren't revoked until earlier today, which I assume was more
than 24 hours since they were reported to the CA.
Will: can you share an
My general sense is that we should be doing more to discourage the use of
SHA-1 rather than less. I've just filed an issue [1] to consider a ban on
SHA-1 S/MIME certificates in the future.
On Mon, Mar 25, 2019 at 10:54 AM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org>
Melis: Thank you for this incident report. I have filed
https://bugzilla.mozilla.org/show_bug.cgi?id=1539190 and assigned it to you
to track this issue.
Will you please have one of your colleagues add you as a Kamu SM contact in
CCADB? That will allow me to confirm that you are representing Kamu
t 4:00 PM Andrew Ayer via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> On Fri, 22 Mar 2019 12:50:43 -0600
>> Wayne Thayer via dev-security-policy
>> wrote:
>>
>> > I've been asked if the section 5.1.1 restrictions on SHA-1 issuan
On Fri, Mar 22, 2019 at 6:54 PM Peter Bowen wrote:
>
>
> 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
>>
A number of ECC certificates that fail to meet the requirements of policy
section 5.1 were recently reported [1]. There was a lack of awareness that
Mozilla policy is more strict than the BRs in this regard. I've attempted
to address that by adding this to the list of "known places where this
In October we discussed the use of "No Stipulation", empty sections, and
blank sections in CP/CPSes. [1] The result was an update to the "Required
Practices" wiki page. [2] I propose moving this into policy by adding the
following paragraph to the bottom of section 3.3 "CPs and CPSes"
In addition
On Thu, Apr 4, 2019 at 7:57 AM CERT Coordination Center
wrote:
> Thanks Rob!
>
> Actually, as I look at one of these cases:
>
> https://crt.sh/?spkisha256=8628d8106b72c39d98e8e731fc3b9364940efea0dfbb4816b1382542a979c834
>
> The latest certificate using the above key expires in just a few days.
>
On Thu, Apr 4, 2019 at 1:50 PM Brian Smith wrote:
> Ryan Sleevi wrote:
>
>> Given that CAs have struggled with the relevant encodings, both for the
>> signatureAlgorithm and the subjectPublicKeyInfo field, I’m curious if
>> you’d
>> be open to instead enumerating the allowed (canonical)
On Wed, Apr 3, 2019 at 6:30 PM Brian Smith wrote:
> Wayne Thayer wrote:
>
>> On Mon, Apr 1, 2019 at 5:36 PM Brian Smith via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>>
>>> Here when you say "require EKUs," you mean that you are proposing that
>>> software that uses
On Fri, Mar 29, 2019 at 4:32 AM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 28/03/2019 21:52, Wayne Thayer wrote:
> > Our current Root Store policy assigns two different meanings to the term
> > "technically constrained":
> > * in sections 1.1 and 3.1,
On Thu, Mar 28, 2019 at 5:29 PM Ryan Sleevi wrote:
>
> On Thu, Mar 28, 2019 at 7:42 PM Wayne Thayer wrote:
>
>> On Thu, Mar 28, 2019 at 4:11 PM Ryan Sleevi wrote:
>>
>>> On Thu, Mar 28, 2019 at 6:45 PM Wayne Thayer via dev-security-policy <
>>> de
Pedro,
Thank you for reporting this issue.
On Tue, Mar 19, 2019 at 2:10 AM Pedro Fuentes via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> In light of the recent discussion related to serial number Entropy, at
> WISeKey we could verify that we were also affected by this
The BRs require EKUs in leaf TLS certs, but there is no equivalent
requirement for S/MIME certificates. This leads to confusion such as [1] in
which certificates that are not intended for TLS or S/MIME fall within the
scope of our policies.
Simply requiring EKUs in S/MIME certificates won't solve
I'd like to remind CAs of Mozilla's disclosure requirement for
unconstrained intermediate CA certificates:
The CA with a certificate included in Mozilla’s root program MUST disclose
> this information within a week of certificate creation, and before any such
> subordinate CA is allowed to issue
We currently expect CAs to deliver incident reports whenever they fail to
comply with our policy, but this is not a requirement of our policy. There
is no obvious place to add this in the existing policy, so I propose
creating a new top-level section that reads as follows:
**Incidents**
> When a
Our current Root Store policy assigns two different meanings to the term
"technically constrained":
* in sections 1.1 and 3.1, it means 'limited by EKU'
* in section 5.3 it means 'limited by EKU and name constraints'
The BRs already define a "Technically Constrained Subordinate CA
Certificate"
he context of TLS certificates. Does that help?
On Thu, Mar 28, 2019 at 4:00 PM Ryan Sleevi wrote:
>
>
> On Thu, Mar 28, 2019 at 4:53 PM Wayne Thayer via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> Our current Root Store policy assig
On Thu, Mar 28, 2019 at 4:11 PM Ryan Sleevi wrote:
>
> On Thu, Mar 28, 2019 at 6:45 PM Wayne Thayer via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> We currently expect CAs to deliver incident reports whenever they fail to
&
Doug: You'll need to connect directly to the certwatch database using a
tool like psql:
psql -h crt.sh -p 5432 -U guest certwatch
Here's Rob's announcement of direct database access:
https://crt.sh/forum?place=msg%2Fcrtsh%2FsUmV0mBz8bQ%2FK-6Vymd_AAAJ
On Tue, Mar 26, 2019 at 11:34 AM Doug Beattie
I've added a few more issues that were recently created to the list for
2.7: https://github.com/mozilla/pkipolicy/labels/2.7
176 - Clarify revocation requirements for S/MIME certs
175 - Forbidden Practices wiki page says email validation cannot be
delegated to 3rd parties
I plan to begin posting
I'm [hopefully] beginning with a simple change that clarifies the language
used for Point-in-Time (PiT) audits used in policy. Section 3.1.3 of our
policy currently references a "point-in-time assessment", and section 8
uses the undefined abbreviation "PITRA", which stands for "point-in-time
I agree with Ryan on this. From a policy perspective, we should be
encouraging [and eventually requiring] EKU constraints, not making it
easier to exclude them.
On Mon, Mar 25, 2019 at 1:03 PM Ryan Hurst via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> While it may be
Scott,
On Tue, Feb 26, 2019 at 3:21 AM Scott Rea via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> G’day folks,
>
> we appreciate the many suggestions made on the list to strengthen the
> entropy of random serialNumbers.
>
> One challenge we face currently is that our
Thank you. I have created a bug and requested a response from T-Systems:
https://bugzilla.mozilla.org/show_bug.cgi?id=1530718
- Wayne
On Tue, Feb 26, 2019 at 8:07 AM michel.lebihan2000--- via
dev-security-policy wrote:
> Hello,
>
> While looking at CT logs, I noticed multiple certificates
Having received no further comments, I am recommending approval of Hongkong
Post's inclusion request.
As Matt suggested earlier in this thread, I would not typically approve a
request for a CA with an open compliance bug, but in this case the bug is
open awaiting implementation of pre-issuance
Thank you for the detailed incident report Scott. I have created
https://bugzilla.mozilla.org/show_bug.cgi?id=1531800 to track this issue,
and attributed it to QuoVadis as the responsible root CA program member.
On Thu, Feb 28, 2019 at 4:43 PM Scott Rea via dev-security-policy <
301 - 400 of 604 matches
Mail list logo
