On Mon, Sep 23, 2019 at 02:53:26PM -0700, Andy Warner via dev-security-policy
wrote:
>
> 1. The new text added to the Mozilla Recommended and Required Practices for
> this topic states only OCSP status is required for precertificates. Many CAs
> provide both CRLs and OCSP services and it would
On 2019-10-02 02:39, Paul Walsh wrote:
According to Ellis, the goal for a customer survey is to get feedback from people who had
recently experienced "real usage" of the product. The key question in the
survey for these people according to Ellis, is:
"How would you feel if you could no longer
On 2019-10-02 09:20, Kurt Roeckx wrote:
On 2019-10-02 02:39, Paul Walsh wrote:
According to Ellis, the goal for a customer survey is to get feedback
from people who had recently experienced "real usage" of the product.
The key question in the survey for these people according to Ellis, is:
On Wed, Oct 02, 2019 at 02:48:56PM -0700, Paul Walsh wrote:
> On Oct 2, 2019, at 12:52 AM, Kurt Roeckx via dev-security-policy
> wrote:
> >
> > On 2019-10-02 09:20, Kurt Roeckx wrote:
> >> On 2019-10-02 02:39, Paul Walsh wrote:
> >>>
> >>> Ac
On Wed, Oct 02, 2019 at 03:17:31PM -0700, Paul Walsh wrote:
> >> In separate research, CAs have shown data to demonstrate that website
> >> owners want to have their identity verified.
> >
> > They have not. In fact, I would say that most website owners are perfectly
> > happy with DV certificat
On Fri, Nov 01, 2019 at 11:08:23AM +0100, Matthias van de Meent via
dev-security-policy wrote:
> Hi,
>
> I recently noticed that a lot of leaf certificates [0] have
> organizationalUnitName specified without other organizational
> information such as organizationName. Many times this field is use
On Thu, Feb 06, 2020 at 08:54:04PM +, Doug Beattie via dev-security-policy
wrote:
> It's not against Mozilla policy to
> issue certificates with unvalidated email addresses in any field as long as
> the Secure Mail EKU is not included, so the intent should be to validate
> only those that are
On Thu, Feb 06, 2020 at 09:31:40PM +, Doug Beattie via dev-security-policy
wrote:
> I don't agree that the CA MUST validate EVERY field. CAs leverage
> enterprise RAs to validate some information in SMIME certificates, e.g., the
> subscribers name in the CN field because the CA can't readily
On 2020-03-19 07:02, Matt Palmer wrote:
2. If there are not explicit prohibitions already in place, *should* there
be? If so, should it be a BR thing, or a Policy thing?
I think there should be. I expect them to publish a CRL that says the
reason for revocation is a key compromise. I exp
On 2020-04-16 14:56, Neil Dunbar wrote:
I would have thought that an OCSP-stapling implementation which got an
OCSP status code 'successful' (0) with a 'revoked' status for the
certificate would want to pass that on to the client, replacing any
prior OCSP successful/status-good report, whethe
On 2020-05-08 21:03, Wayne Thayer wrote:
It was recently reported [1] that IdenTrust experienced a multi-day OCSP
outage about two weeks ago. Other recent OCSP issues have resulted in
incident reports [3][4], so I am concerned that IdenTrust didn't report
this, and I created a bug [5] to ensure t
On 2020-05-15 08:47, Peter Gutmann wrote:
Hanno Böck writes:
The impact it had was a monitoring system that checked whether the
certificate of a host was okay, using gnutls-cli with ocsp enabled (which
also uncovered a somewhat unexpected inconsistency in how the gnutls cli tool
behaves[1]).
Hi,
Browsing crt.sh, I found this:
https://crt.sh/?id=1902422627
It's a certificate for api.pillowz.kz with the public key of Let's
Encrypt Authority X1 and X3 CAs.
It's revoked since 2020-01-31, but I couldn't find any incident
report related to it.
Kurt
_
On Sat, May 16, 2020 at 10:04:24AM -0400, Andrew Ayer via dev-security-policy
wrote:
> On Sat, 16 May 2020 14:02:42 +0200
> Kurt Roeckx via dev-security-policy
> wrote:
>
> > https://crt.sh/?id=1902422627
> >
> > It's a certificate for api.pillowz.kz with
On Thu, May 21, 2020 at 02:01:49PM -0700, Daniela Hood via dev-security-policy
wrote:
> Hello Sandy,
>
> GoDaddy received an email on Friday, May 7, 2020 12:06 UTC, reporting a key
> compromise, by Sandy. Once received our team started working on making sure
> that the certificate had indeed a
On Fri, May 22, 2020 at 10:38:34AM +0200, Hanno Böck via dev-security-policy
wrote:
> Just reported this to Chunghwa Telecom Co., Ltd.:
>
> --
>
> I'm contacting you about a problem with the certificate for
> *.hinet.net, as it can be found here [1].
>
> The Authority Information Access
On Thu, Aug 13, 2020 at 12:43:01PM -0700, Ronald Crane via dev-security-policy
wrote:
> I'd argue that domain registrars, CAs, and hosting services _should_ have an
> obligation to deny services to obvious phishing domains. [1] (This is
> independent of what (if any) obligations they might current
On Wed, Sep 30, 2020 at 03:58:45PM +, Rob Stradling via dev-security-policy
wrote:
> Starting today, the BRs require a reasonCode in CRLs and OCSP responses for
> revoked CA certificates. Since crt.sh already monitors CRLs and keeps track
> of reasonCodes, I thought I would conduct some ana
On 2021-01-07 01:48, Aaron Gable wrote:
As mentioned in the blog post, and as we'll elaborate on further in an
upcoming post, one of the drawbacks of this arrangement is that there
actually is a class of clients for which chaining to an expired root
doesn't work: versions of OpenSSL prior to 1.1.
On Thu, Jan 07, 2021 at 09:31:17AM -0800, Aaron Gable wrote:
> In cases where we expect OpenSSL to be validating the chain, we expect that
> ISRG Root X1 is also in the trust store (unlike older versions of Android,
> where we know that it hasn't been added). As such, there will be two
> certificat
On 2021-01-19 11:02, Ramiro Muñoz wrote:
El martes, 19 de enero de 2021 a las 0:49:42 UTC+1, Matt Palmer escribió:
On Sun, Jan 17, 2021 at 12:51:29AM -0800, Ramiro Muñoz via dev-security-policy
wrote:
We don’t ask the community to disregard the data, on the contrary we ask
the community to ana
On Mon, Dec 18, 2017 at 03:04:11PM -0800, Ian Carroll via dev-security-policy
wrote:
>
> I do wonder how many users actually make the connection that the country code
> next to the company name is in fact a country code.
And even if you do make the connection, it's not always obvious
even in wh
On Mon, Dec 25, 2017 at 07:59:12AM -0800, Peter Bowen via dev-security-policy
wrote:
> 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
On 2018-01-04 01:36, Kathleen Wilson wrote:
Mozilla: Audit Reminder
Root Certificates:
AC Raíz Certicámara S.A.
Standard Audit: https://cert.webtrust.org/SealFile?seal=2120&file=pdf
Audit Statement Date: 2016-09-15
CA Comments: null
The audit period of that is 2015-07-01 to 2016-04-30. The
On Wed, Jan 10, 2018 at 01:33:20AM -0800, josh--- via dev-security-policy wrote:
> * Users have the ability to upload certificates for arbitrary names without
> proving domain control.
So a user can always take over the domain of an other user on
those providers just by installing a (self-signed
On 5/02/2018 17:08, Hanno Böck wrote:
https://crt.sh/?id=308392091&opt=ocsp
It has:
Subject:
commonName= ftp.gavdi.pl
countryName = PL
This looks like a combination that's not allowed. Either it's domain
validated, in which case it should
On 6/02/2018 12:20, Hanno Böck wrote:
Issuer is "Intesa Sanpaolo CA Servizi Esterni Enhanced", which is
a subca of Baltimore Cybertrust, which belongs to Digicert.
That certificate is revoked, not trusted by Mozilla or chrome.
Kurt
___
dev-security-
On 6/02/2018 16:52, Kurt Roeckx wrote:
On 6/02/2018 12:20, Hanno Böck wrote:
Issuer is "Intesa Sanpaolo CA Servizi Esterni Enhanced", which is
a subca of Baltimore Cybertrust, which belongs to Digicert.
That certificate is revoked, not trusted by Mozilla or chrome.
I should probably more cle
On 6/02/2018 17:10, Ryan Sleevi wrote:
The BRs actually seem to allow this, which at least looks like a bug in
the BRs to me.
It is allowed, and it's not a bug. It's specifically called out in 3.2.2 of
the BRs.
It seems that under 3.2.2.3 (b) they can just copy the ccTLD from the
domain name
I just came across this:
https://www.recordedfuture.com/code-signing-certificates/
I think the most important part of it is: "we confirmed with a high
degree of certainty that the certificates are created for a specific
buyer per request only and are registered using stolen corporate identitie
On Tue, Feb 27, 2018 at 12:09:01AM +0100, Jakob Bohm via dev-security-policy
wrote:
>
> Hence why an investigation is needed by the 3 CAs named in the paper
> (Comodo, Digicert and Apple). They will probably have to do some deep
> log inspection to figure out patterns, besides reaching out to th
On 2018-02-27 17:23, Alex Gaynor wrote:
A reasonable compromise that jumps out to me is allowing extensions to make
an otherwise-secure connection fail, but not allow them to rehabilitate an
insecure connection. This would allow experimenting with stricter controls
while avoiding some of the real
On Tue, Mar 20, 2018 at 12:07:54PM -0700, Kathleen Wilson via
dev-security-policy wrote:
> Mozilla: Audit Reminder
> Root Certificates:
>Class 2 Primary CA
> Standard Audit:
> https://bug1297034.bmoattachments.org/attachment.cgi?id=8849236
> Audit Statement Date: 2017-01-14
> BR Audit: https:/
On Sat, Mar 31, 2018 at 10:14:27PM +, Tim Smith via dev-security-policy
wrote:
> Hi MDSP,
>
> I went looking for corpuses of certificates that may not have been
> previously logged to CT and found some in the Rapid7 "More SSL" dataset,
> which captures certificates from their scans of non-HTT
On Tue, Apr 03, 2018 at 02:11:07AM +0200, Jakob Bohm via dev-security-policy
wrote:
> seems
> to be mostly justified as a poor workaround for the browsers and
> certificate libraries not properly implementing reliable revocation
> checks.
The problem is not in the libraries, or even the applicati
On 2018-05-04 12:10, Tim Hollebeek wrote:
It has generally been understood that a string still "contains at least 112
bits of output from a CSPRNG" if that string has been fed through an
encoding mechanism like Base64 or Base32.
Furthermore, explicit requirements about including mixed case or sp
On Tue, Jun 19, 2018 at 01:59:26PM -0700, Kathleen Wilson via
dev-security-policy wrote:
>
> Mozilla: Audit Reminder
> Root Certificates:
>SwissSign Platinum CA - G2
>SwissSign Silver CA - G2
> Standard Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8861552
> Audit Statement Date:
On Fri, Jul 06, 2018 at 02:43:45PM -0700, Peter Bowen via dev-security-policy
wrote:
> 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
On Sat, Jul 07, 2018 at 01:23:24AM +, Peter Gutmann via dev-security-policy
wrote:
>
> So for certlint I'd always warn for T61String with anything other than ASCII
> (which century are they living in? Point them at UTF8 and tell them to come
> back when they've implemented it), treat it as a
On Sat, Jul 07, 2018 at 10:43:26AM +0200, Kurt Roeckx via dev-security-policy
wrote:
> On Sat, Jul 07, 2018 at 01:23:24AM +, Peter Gutmann via
> dev-security-policy wrote:
> >
> > So for certlint I'd always warn for T61String with anything other than ASCII
> > (
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 yet to see a certificate
that doesn't just put latin1 in it, wh
On Mon, Jul 09, 2018 at 01:40:17AM +, Peter Gutmann wrote:
>
> Just out of interest, which country did the T61String-containing cert come
> from? With which interpretation of T61String did the resulting strings
> display correctly? Were they in fact latin-1?
As I understand it, it was the S
On 2018-07-13 12:02, lcchen.ci...@gmail.com wrote:
We suggest that CA "in principle" must comply with the string length limit
of RFC 5280 for organizationalUnitName or organizationName filed in Subject of a
certificate. But if it is necessary after verification to express an organization’s
On Thu, Aug 02, 2018 at 06:19:42AM -0700, Juan Angel Martin via
dev-security-policy wrote:
>
> 6) Explanation about how and why the mistakes were made or bugs introduced,
> and how they avoided detection until now.
>
> The procedure established to publish the CAs into CCADB wasn't correct caus
On 2018-08-21 21:03, Kathleen Wilson wrote:
Mozilla: Overdue Audit Statements
Root Certificates:
SwissSign Platinum CA - G2**
** Audit Case in the Common CA Database is under review for this root
certificate.
Standard Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8861552
Audit Sta
Probably because no Russian CA has applied to be in the root store.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
On Tue, Oct 16, 2018 at 12:49:41PM -0700, Kathleen Wilson via
dev-security-policy wrote:
> Forwarded Message
> Subject: Summary of October 2018 Audit Reminder Emails
> Date: Tue, 16 Oct 2018 19:00:37 + (GMT)
>
> Mozilla: Audit Reminder
> Root Certificates:
>AC Raíz Certi
On 2018-10-30 16:20, Ryan Sleevi wrote:
Given that the Supervisory Body and National Accreditation bodies exist to
protect the legal value of this scheme, the failure by TUVIT to uphold the
safety and security of the eIDAS regime represents an ongoing threat to the
ecosystem.
Do we have a way o
On 2018-10-31 16:42, Wiedenhorst, Matthias wrote:
In several emails, we answered to his complaint, explained our procedures and
justified the classification of the encoding error as minor (non-critical)
non-conformity.
I think we never consider encoding errors as a minor error.
Kurt
___
On Tue, Oct 23, 2018 at 02:35:37PM -0700, Kathleen Wilson via
dev-security-policy wrote:
> > > Mozilla: Audit Reminder
> > > Root Certificates:
> > > Certinomis - Root CA
> > > Standard Audit:
> > > https://bug937589.bmoattachments.org/attachment.cgi?id=8898169
> > > Audit Statement Date: 2017
On 2018-12-04 7:24, Wojciech Trapczyński wrote:
Question 1: Was there a period during which this issuing CA had no
validly signed non-expired CRL due to this incident?
Between 10.11.2018 01:05 (UTC±00:00) and 14.11.2018 07:35 (UTC±00:00) we
were serving one CRL with corrupted signature.
On 2018-12-04 10:25, Wojciech Trapczyński wrote:
On 04.12.2018 10:01, Kurt Roeckx via dev-security-policy wrote:
On 2018-12-04 7:24, Wojciech Trapczyński wrote:
Question 1: Was there a period during which this issuing CA had no
validly signed non-expired CRL due to this incident?
Between
On Tue, Dec 04, 2018 at 01:14:44PM -0500, Ryan Sleevi via dev-security-policy
wrote:
>
> > All issued certificates were unusable due to corrupted signature.
> >
>
> Could you speak to more about how you assessed this? An incorrect signature
> on the CRL would not necessarily prevent the certific
On 2018-12-18 11:44, Matt Palmer wrote:
It's currently loaded with great piles of Debian weak keys (from multiple
architectures, etc), as well as some keys I've picked up at various times.
I'm also developing scrapers for various sites where keys routinely get
dropped.
You might for instance al
On 2018-12-19 10:55, Matt Palmer wrote:
On Wed, Dec 19, 2018 at 10:08:51AM +0100, Kurt Roeckx via dev-security-policy
wrote:
On 2018-12-18 11:44, Matt Palmer wrote:
It's currently loaded with great piles of Debian weak keys (from multiple
architectures, etc), as well as some keys I'
On Wed, Dec 19, 2018 at 10:08:51AM +0100, Kurt Roeckx via dev-security-policy
wrote:
> On 2018-12-18 11:44, Matt Palmer wrote:
> > It's currently loaded with great piles of Debian weak keys (from multiple
> > architectures, etc), as well as some keys I've picked up at va
On 2019-01-03 16:25, Jakob Bohm wrote:
There is the date fields in the SubCA certificate itself, as well as any
embedded CT data (assuming the parent CA is correctly CT-logged).
Do you expect precertificates for CA certificates?
I currently don't know if there are any requirements for logging
On 2019-01-24 9:47, Buschart, Rufus wrote:
Good morning!
I would like to sharpen my argument from below a little bit: If a CA gets a
request to issue a certificate for the domain xn--gau-7ka.siemens.de, how can
the CA tell, that xn--gau-7ka is a punycode string in IDNA2008 and not only a
very
On 2019-01-24 12:08, Rob Stradling wrote:
Hi Kurt.
BRs 7.1.4.2.2 says that the subject:commonName "MUST contain a single IP
address or Fully-Qualified Domain Name that is one of the values
contained in the Certificate’s subjectAltName extension (see Section
7.1.4.2.1)."
Fitting the U-label int
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 back then as Comodo
CA, before we switched to always putting the A-label in the CN):
https://crt.sh/?id=213062481&opt=cablint,x
On 2019-01-24 20:19, Tim Hollebeek wrote:
I think the assertion that the commonName has anything to do with what the
user would type and expect to see is unsupported by any of the relevant
standards, and as Rob noted, having it be different from the SAN strings is
not in compliance with the Basel
On 2019-01-29 1:29, Wayne Thayer 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
I guess this part is not very clear to me:
> We identified and removed from system the registration policy that
>
On Fri, Feb 01, 2019 at 03:02:17PM -0700, Wayne Thayer wrote:
> 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
On 2019-02-04 21:33, Kathleen Wilson 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 for determining when the email
gets sent, so that rather than keying off of the A
On 2019-02-08 1:04, identr...@gmail.com wrote:
On Thursday, February 7, 2019 at 6:47:03 PM UTC-5, iden...@gmail.com wrote:
On 04/04/2018 we found a discrepancy in the address values for some SSL
certificates. A formal incident Report was just posted:
https://bugzilla.mozilla.org/show_bug.cgi?id
On Fri, Feb 22, 2019 at 03:45:39PM -0800, cooperq--- via dev-security-policy
wrote:
> On Friday, February 22, 2019 at 2:37:20 PM UTC-8, Jonathan Rudenberg wrote:
> > With regards to the broader question, I believe that DarkMatter's alleged
> > involvement with hacking campaigns is incompatible wi
On Sat, Feb 23, 2019 at 02:07:38PM +0400, Scott Rea via dev-security-policy
wrote:
> G’day Wayne et al,
>
> In response to your post overnight (included below), I want to assure you
> that DarkMatter’s work is solely focused on defensive cyber security, secure
> communications and digital trans
On Wed, Mar 13, 2019 at 05:56:55AM +0900, Hector Martin 'marcan' via
dev-security-policy wrote:
> On 13/03/2019 05.38, Ryan Sleevi via dev-security-policy wrote:
> > Note that even 7 bytes or less may still be valid - for example, if the
> > randomly generated integer was 4 [1], you might only hav
On Thu, Mar 14, 2019 at 04:09:10PM -0700, Jaime Hablutzel via
dev-security-policy wrote:
> > In accordance with our conversations to date, prior to 3/7 6:30pm AZ we
> > utilized raw 64 bit output from CSPRING, with uniqueness and non zero
> > checks. This new understanding of the rules calls for
On Mon, Mar 18, 2019 at 03:30:37PM +, Rob Stradling via dev-security-policy
wrote:
>
> When a value in column E is 100%, this is pretty solid evidence of
> noncompliance with BR 7.1.
> When the values in column E and G are both approximately 50%, this
> suggests (but does not prove) that th
On Tue, Jul 16, 2019 at 12:12:57PM -0700, Kathleen Wilson via
dev-security-policy wrote:
> Mozilla: Overdue Audit Statements
> CA Owner: LuxTrust
> Root Certificates:
>LuxTrust Global Root 2
> Standard Audit:
> https://www.lsti-certification.fr/images/LSTI--11085-57-AL-V1.0_LUXTRUST.pdf
> Stan
On 2019-08-13 05:27, Peter Gutmann wrote:
Wayne Thayer via dev-security-policy
writes:
Mozilla has announced that we plan to relocate the EV UI in Firefox 70, which
is expected to be released on 22-October. Details below.
Just out of interest, how are the CAs taking this? If there's no mor
On Wed, Aug 14, 2019 at 11:52:46PM -0700, Daniel Marschall via
dev-security-policy wrote:
> In old Firefox, I get a green bar if I visit google.com and paypal.com,
> telling me that this is a well-known company that got the EV certificate.
> The other fake domains goog1e.com and paypa1.com only h
On Fri, Aug 16, 2019 at 12:42:35PM -0700, tim--- via dev-security-policy wrote:
>
> By way of background, until recently almost all phishing and malware was on
> unencrypted http sites. They received a neutral UI, and the bad guys didn’t
> have to spend time and money getting a certificate, even
On 2019-08-30 12:14, Jakob Bohm wrote:
On 30/08/2019 01:36, Jacob Hoffman-Andrews wrote:
Also filed at https://bugzilla.mozilla.org/show_bug.cgi?id=1577652
On 2019.08.28 we read Apple’s bug report at
https://bugzilla.mozilla.org/show_bug.cgi?id=1577014 about DigiCert’s OCSP
responder returnin
On 2019-09-04 14:14, Matt Palmer wrote:
If EV information is of use in anti-phishing efforts, then it would be best
for the providers of anti-phishing services to team up with CAs to describe
the advantages of continuing to provide an EV certificate. If site owners,
who are presumably smart peo
On 2019-09-16 14:02, Rob Stradling wrote:
ISTM that this "certificate presumed to exist" concept doesn't play
nicely with the current wording of BR 4.9.10:
'If the OCSP responder receives a request for status of a certificate
that has not been issued, then the responder SHOULD NOT respo
So after reading this, the following auditors aren't trusted by Symantec
anymore:
- E&Y Korea
- E&Y Brazil
The following isn't trusted by Mozilla anymore:
- E&Y Hong Kong
This seems to be a worrying trend to me.
Kurt
On 2017-02-12 20:25, Eric Mill wrote:
Also relevant are Symantec's stateme
On 2017-03-09 02:08, Ryan Sleevi wrote:
It appears that DigiCert has violated the Baseline Requirements, as recently
notified to the CA/Browser Forum.
The certificate at https://crt.sh/?id=98120546 does not comply with RFC 5280.
RFC 5280 defines the upper-bound of the commonName field as 64 ch
On 2017-03-09 05:21, Ryan Sleevi wrote:
Well, you still said the same thing, and I understood what you said, but
not why you said it or why you believe it. That's why I was asking for new
details.
Certificate Policy OIDs don't say who the certificate belongs to or who
issued the certificate. The
On Thu, Mar 09, 2017 at 06:29:57PM -0500, Ryan Sleevi via dev-security-policy
wrote:
> > However, I think this discussion raises some very interesting points about
> > real world scenarios and RFC 5280 that should be addressed. DigiCert
> > actually has three items that routinely show up on CABLi
On 2017-03-14 02:19, Peter Bowen wrote:
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 sayin
On 2017-03-17 16: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=a050S00G3K2
Action 6 says:
However, a point-in-time audit statement only valid
On 2017-03-21 12:51, Jakob Bohm wrote:
On 21/03/2017 10:09, Kurt Roeckx wrote:
On 2017-03-17 16: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=a05
On 2017-03-23 16:39, Ryan Sleevi wrote:
On Thu, Mar 23, 2017 at 8:37 AM, Peter Kurrasch via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
I would be interested in knowing why Google felt it necessary to purchase
an existing root instead of, for example, pursuing a "new ro
On Mon, Mar 27, 2017 at 09:02:48PM +0100, Gervase Markham via
dev-security-policy wrote:
> On 27/03/17 16:08, Martin Heaps wrote:
> > The next level is now that any business or high valued entity should
> > over the course of the next few years implement EV certificates (many
> > already have) and
On 2017-04-10 17:52, Ryan Sleevi wrote:
Hi Steve,
Quick question:
1) You identified that the root cause was related to a deprecated, but not
removed, interface. Your remediation was to remove that interface.
a) How many deprecated, but unremoved, interfaces does Symantec have, as
of 2017-04-1
On 2017-04-10 16:57, Steve Medin wrote:
Because our customers are our top priority, we attempted to minimize business
disruption
I think you have your top priority wrong, and this seems to be a
reoccurring reason why you do things.
Kurt
___
dev-
On 2017-04-11 11:15, Kurt Roeckx wrote:
On 2017-04-10 17:52, Ryan Sleevi wrote:
Hi Steve,
Quick question:
1) You identified that the root cause was related to a deprecated, but
not
removed, interface. Your remediation was to remove that interface.
a) How many deprecated, but unremoved, inter
On 2017-04-11 17:20, Ryan Sleevi wrote:
On Tue, Apr 11, 2017 at 6:02 AM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
Hi Ryan,
On 10/04/17 16:38, Ryan Sleevi wrote:
1) You're arguing that "the issuance of this cert didn't impose risk on
anyone but th
On 2017-04-11 17:54, Ryan Sleevi wrote:
On Tue, Apr 11, 2017 at 11:44 AM, Kurt Roeckx via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
The reply indicated that it was a non-browser application. So I understand
that a browser should never see that certificate.
T
On 2017-04-12 11:47, Gervase Markham wrote:
"If the certificate includes the id-kp-emailProtection extended key
usage, it MUST include the Name Constraints X.509v3 extension with
constraints on rfc822Name, with at least one name in permittedSubtrees."
I think this change itself makes sense
On 2017-04-12 11:47, Gervase Markham wrote:
There are some items that it would be very helpful for auditors to state
in their public-facing audit documentation so that we can be clear about
what was covered and what was not. The policy already has some
requirements here, in section 3.1.3, mostly
On 2017-04-12 14:19, Jakob Bohm wrote:
On 12/04/2017 12:44, Kurt Roeckx wrote:
On 2017-04-12 11:47, Gervase Markham wrote:
There are some items that it would be very helpful for auditors to state
in their public-facing audit documentation so that we can be clear about
what was covered and what
On 2017-04-12 13:42, braddockmews...@gmail.com wrote:
If browsers did policy validation would it have been a problem? I
can't answer that.
So I guess that would be something like require one of the CAB policy
IDs for which validation that happened? (2.23.140.1.2.1 for DV,
2.23.140.1.2.2 for
On 2017-04-12 16:15, Peter Bowen wrote:
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 aud
On Wed, Apr 19, 2017 at 12:28:16PM -0700, Ryan Sleevi via dev-security-policy
wrote:
> > https://portal.mobilitymixx.nl
>
> I'm not sure I understand enough to know what the issues are here. Could you
> explain?
Both the localityName and stateOrProvinceName are Almere, while
the province is Fle
On Wed, Apr 19, 2017 at 10:41:33PM +, Peter Gutmann via dev-security-policy
wrote:
> Kurt Roeckx via dev-security-policy
> writes:
>
> >Both the localityName and stateOrProvinceName are Almere, while the province
> >is Flevoland.
>
> How much checking is a CA e
On Wed, Apr 19, 2017 at 11:58:28PM +, Jeremy Rowley wrote:
> That was changed in ballot 127.
Which is adopted in july 2014. This was somewhere in 2016.
As I understood it, they didn't ask for the HR department, just
someone else. That might of course be a misunderstanding of what
was asked, w
On Wed, Apr 19, 2017 at 09:00:22PM -0400, Ryan Sleevi wrote:
> On Wed, Apr 19, 2017 at 7:53 PM, Kurt Roeckx via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> >
> > (It was a code sign certificate, but I expect if it's labeled EV
&
1 - 100 of 152 matches
Mail list logo
