I've created https://bugzilla.mozilla.org/show_bug.cgi?id=1532429 to track
this incident.
On Fri, Mar 1, 2019 at 1:55 PM David E. Ross via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 2/28/2019 7:45 PM, 孙圣男 wrote:
> > Dear Mozilla：
> > This problem had been
Neil,
On Sat, Mar 2, 2019 at 8:52 AM Neil Dunbar via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> All,
>
> Included is an incident report, formatted per the Mozilla recommendations,
> with timelines and resolutions.
>
> Thank you for completing an excellent incident
On Mon, Mar 4, 2019 at 9:04 AM Matthew Hardeman via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Sun, Mar 3, 2019 at 6:13 PM Ryan Sleevi wrote:
>
> >
> > It is not clear how this follows. As my previous messages tried to
> > capture, the program is, and has always
On Mon, Mar 4, 2019 at 3:29 AM Buschart, Rufus via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Writing with my personal hat on:
>
>
> > -Ursprüngliche Nachricht-
> > Von: dev-security-policy
> Im Auftrag von Matthew Hardeman via dev-security-policy
> > On Sun,
https://bugzilla.mozilla.org/show_bug.cgi?id=1531817 has been created to
track this issue.
On Wed, Feb 27, 2019 at 10:52 PM Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Hi Cynthia,
>
> We've figured out what happened with your certificate but are still
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 <
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. 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
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
The recent Reuters report on DarkMatter [1] has prompted numerous questions
about their root inclusion request [2]. The questions that are being raised
are equally applicable to their current status as a subordinate CA under
QuoVadis (recently acquired by DigiCert [3]), so it seems appropriate to
I have replaced some outdated information on Mozilla's wiki about
revocation checking [1] [2] with a new page on the wiki describing how
Firefox currently performs revocation checking on TLS certificates:
https://wiki.mozilla.org/CA/Revocation_Checking_in_Firefox
It also includes a brief
Thank you George, this is indeed interesting. As you and Ryan have noted,
there is a lot of human interaction required, but I would like to find ways
to better automate some of the work involved in managing incident bugs,
especially since there seems to be no end of them in sight.
Meanwhile, I
On Tue, Feb 19, 2019 at 10:51 AM Ryan Sleevi wrote:
>
>
> On Tue, Feb 19, 2019 at 9:56 PM Wayne Thayer wrote:
>
>> Ryan,
>>
>> On Mon, Feb 18, 2019 at 4:58 PM Ryan Sleevi via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>>
>>> On Mon, Feb 18, 2019 at 2:49 PM Jakob Bohm
Ryan,
On Mon, Feb 18, 2019 at 4:58 PM Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Mon, Feb 18, 2019 at 2:49 PM Jakob Bohm via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > On 15/02/2019 19:33, Ryan Sleevi wrote:
> > > On
Izenpe posted the following response to the bug [1]:
My apologies for the delayed follow up response. First we must say that we
don't see any benefit for the community of publishing the name and version
of our PKI software, regardless of security issues.
As previously stated, we have two filters
"Pre-production" CPS
> will be version 5, replacing the current CPS.
>
> If any member has other comments, you're welcome to bring it out.
>
>
> On 16-Jan-19 5:30 AM, Wayne Thayer via dev-security-policy wrote:
>
>
> I think you and David are also suggesting that
Thank you for the incident report. I have created a bug for tracking:
https://bugzilla.mozilla.org/show_bug.cgi?id=1528290
- Wayne
On Fri, Feb 15, 2019 at 7:21 AM Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> (Sending from the right e-mail)
>
> On Fri,
This may be of interest:
https://blog.mozilla.org/security/2019/02/14/why-does-mozilla-maintain-our-own-root-certificate-store/
- Wayne
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
Mozilla's guidance for incident response lives at
https://wiki.mozilla.org/CA/Responding_To_An_Incident
I just made some significant changes to the Revocation section that reflect
the approach we took with the recent underscore sunset.
Most notably, the following paragraph:
However, it is not
Thanks Corey and Jakob, I opened a bug for this:
https://bugzilla.mozilla.org/show_bug.cgi?id=1527423
Corey, did you report this via DigiCert's problem reporting mechanism?
Thanks,
Wayne
On Mon, Feb 11, 2019 at 8:01 PM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org>
Perhaps more concerning, this sounds a lot like bug #1462844 in which
misissued certificates were reported that had not been found and revoked
despite GoDaddy having previously scanned their database for the issue.
GoDaddy never identified or described how they would remediate the cause of
that
I just noticed that my response to David's question was only sent to his
(nobody@nowhere.invalid) reply address and not to the list.
On Wed, Sep 26, 2018 at 4:41 PM David E. Ross via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 9/26/2018 3:21 PM, Wayne Thayer wrote:
>
Telia has supplied the point-in-time audit reports required to verify
remediation of the audit issues that were described in this thread and in
https://bugzilla.mozilla.org/show_bug.cgi?id=1475115
Links to the PiT reports:
On Tue, Feb 5, 2019 at 11:55 AM Matthias van de Meent via
dev-security-policy wrote:
> On Tue, 5 Feb 2019 at 16:58, Ryan Sleevi wrote:
>
> > CAs are not presently required to disclose those profiles in that
> detail, but it sounds as if the issue is that Sectigo did not update the
> CP/CPS
On Tue, Feb 5, 2019 at 4:37 AM Matthias van de Meent via
dev-security-policy wrote:
> On Mon, 4 Feb 2019 at 18:06, Ryan Sleevi wrote:
> >
> > On Mon, Feb 4, 2019 at 10:46 AM Matthias van de Meent via
> dev-security-policy wrote:
> >>
> >> Hi,
> >>
> >> Today we've bought a wildcard certificate
Thanks everyone for your input on this topic.
As a result of this discussion, I have concluded that this is not a clear
violation of Mozilla policy. I've closed the DFN bug as INVALID, and I am
planning to propose a ballot to the CAB Forum to clarify this requirement.
- Wayne
On Wed, Jan 30,
On Mon, Feb 4, 2019 at 1:33 PM Kathleen Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> All,
>
> As you know, CCADB sends audit reminder emails regarding root certs in
> Mozilla's program on the 3rd Tuesday of each month.
>
> We are going to update the date checks
While a certain amount of latency in OCSP updates is expected when a
certificate is first issued or revoked, KIR intended this to be a permanent
"unknown" status for a revoked certificate. My conclusion from this
discussion is that such a policy is not permitted, and the existing
requirements are
The BRs define Repository as:
Repository: An online database containing publicly-disclosed PKI governance
documents (such as Certificate Policies and Certification Practice
Statements) and Certificate status information, either in the form of a CRL
or an OCSP response.
I see no evidence to
It was pointed out to me that the OCSP status of the misissued certificate
that is valid for over 5 years is still "unknown" despite having been
revoked a week ago. I asked KIR about this in the bug [1] and am surprised
by their response:
This certificate is revoked on CRL. Because the
Thanks Corey and Ben. This issue does appear to have been resolved. I've
created a bug requesting an incident report:
https://bugzilla.mozilla.org/show_bug.cgi?id=1523676
- Wayne
On Sun, Jan 27, 2019 at 5:48 PM Ben Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
Piotr just filed an incident report on the misissuance that was reported on
18-January: https://bugzilla.mozilla.org/show_bug.cgi?id=1523186
The report discloses another misissuance that occurred during testing,
resulting in a serverAuth certificate with a duration of over 5 years.
On Sun, Jan
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
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
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
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.
>
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
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
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 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
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 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
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
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
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
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
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 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
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 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
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 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
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 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 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
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
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
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 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
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-
&
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
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
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 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
>
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 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 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
>
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
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
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
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
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 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
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
It should come as no big surprise that I have documented this issue as our
first auditor compliance bug[1]:
https://bugzilla.mozilla.org/show_bug.cgi?id=1507376
I only included a brief summary of this discussion (and a link to it).
Others are welcome to comment if you feel that I have omitted
I agree with Tim on the interpretation and can confirm that my intent was
as Tim described.
Perhaps the confusion is over the purpose of the <30 day exception. It
wasn't to exempt legacy certificates near the end of their lifetime from
being revoked. It was to allow subscribers to begin using
y
requiring them to replace their certificates while still allowing some time
to transition away from them via 30-day duration certificates, the hope is
that we will avoid the urgent calls for exceptions we've seen with past
sunset periods.
Thanks,
>
> Vincent
>
> On Mon, Nov 12, 2018 a
The recent auditor discussions on this list have highlighted the fact that
we haven't done a good job of tracking auditor concerns. Easily searchable
records of past CA issues in Bugzilla help us to identify patterns of CA
behavior, and we should have the same for auditors. with that in mind, I
;
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1486838
>
> On Thu, Sep 20, 2018 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
&g
Since there haven't been any further comments regarding my recommendation
to deny this request, I would like to ask for feedback on next steps that
Identrust can take in the event of a denial. I believe that Identrust would
still like to pursue EV recognition in Firefox, but I think it's unlikely
of
the relevant compliance dates in the email are correct, so I'm not planning
to resend the CA communication.
- Wayne
On 11/13/2018 7:18 AM, Wayne Thayer via dev-security-policy wrote:
>> > As you may be aware, the CA/Browser Forum recently passed ballot SC12
>> [1]
>> >
uirement.
- Man Ho
>
> On 11/13/2018 7:18 AM, Wayne Thayer via dev-security-policy wrote:
> > As you may be aware, the CA/Browser Forum recently passed ballot SC12 [1]
> > creating a sunset period for TLS certificates containing an underscore
> > ("_") character in
As you may be aware, the CA/Browser Forum recently passed ballot SC12 [1]
creating a sunset period for TLS certificates containing an underscore
("_") character in the SAN. This practice was widespread until a year ago
when it was pointed out that underscore characters are not permitted in
dNSName
I'm not convinced there is an answer here. It seems that most would agree
with the premise that we should consider the circumstances and context for
an issue and make a balanced assessment. That leaves the matter of what
this means in practice up for debate. Often, it appears to be a debate
It might be helpful for me to provide a better explanation of the thinking
that went into my recommendation:
The timeline of the Internal Name incident is as follows:
* Identrust appears to have stopped issuing certificates containing .INT
names prior to the BR deadline.
* They then failed to
In addition, I take exception to the statement that open criticism is a bad
approach and the implication that private discussions are the best way to
make improvements. This is clearly not Mozilla's philosophy.
I do believe that we all need to be careful to follow Mozilla forum
etiquette [1] and
I am particularly disturbed by three points made by TUVIT during this
discussion:
1. A malformed qcStatement extension is a minor non-conformity because
there is no known security risk - This argument is incredibly dangerous and
harmful. It implies that all sorts of well-defined requirements can
I am recommending denial of this request.
It was not uncommon for CAs to treat the .int TLD as an Internal Name, so
I'm not going to argue this point and claim that these certificates were
misissued because 'identrust.int' and 'identrus.int' were not registered
domain names.
Under the assumption
Having received no further comments, I am recommending approval of
Certigna's inclusion request.
I would first like to thank Certigna for their patience as this request
spent a long time waiting on Mozilla.
The disregard for CAB Forum requirements shown by Certigna's CAA exception
process is a
.com or through the website
> http://webcrm.camerfirma.com/incidencias/incidencias.php
>
>
> -Mensaje original-
> De: dev-security-policy
> [mailto:dev-security-policy-boun...@lists.mozilla.org] En nombre de Wayne
> Thayer via dev-security-policy
> Enviado el: jueves, 27 de septiem
On Thu, Oct 25, 2018 at 10:11 PM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 26/10/2018 01:13, Ryan Sleevi wrote:
> > On Thu, Oct 25, 2018 at 5:47 PM Jakob Bohm via dev-security-policy <
> > dev-security-policy@lists.mozilla.org> wrote:
> >
> >> On
On Thu, Oct 25, 2018 at 11:17 AM Joanna Fox via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Questions about blank sections, thinking of a potential future
> requirement. Sections such as 1.INTRODUCTION would remain blank as they are
> more titles than components,
On Wed, Oct 24, 2018 at 3:02 PM David E. Ross via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 10/24/2018 1:07 PM, Wayne Thayer wrote:
> > On Tue, Oct 23, 2018 at 1:46 PM David E. Ross via dev-security-policy <
> > dev-security-policy@lists.mozilla.org> wrote:
> >
> >>
On Tue, Oct 23, 2018 at 1:46 PM David E. Ross via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 10/23/2018 11:45 AM, Wayne Thayer wrote:
> > I believe that the discussion over Certigna's reported CAA misissuance
> > [1][2] has reached an end, even though some questions
2018 to comply with
> > new BRs, and again in May 2019 due to annual review, they need not comply
> > until May 2019.
> >
> > >
> > >> -Original Message-
> > >> From: dev-security-policy
> > >> On Behalf Of Wayne
I believe that the discussion over Certigna's reported CAA misissuance
[1][2] has reached an end, even though some questions remain unanswered. If
anyone has additional comments or concerns about this inclusion request,
please respond by Friday 26-October. This request [3] has been in
discussion
Having given this some more thought, I suggest the following changes:
* Forbid "no stipulation" altogether. While there are a few sections where
it would be convenient to use "No stipulation" (e.g. 4.2.3 Time to Process
Certificate Applications), I don't see a requirement for more descriptive
201 - 300 of 604 matches
Mail list logo
