On Thu, May 2, 2019 at 3:45 PM Nick Lamb wrote:
> Alex, you say you "came across" these certificates, do you think it is
> likely that there are many more, or was that in practice a fairly
> thorough search?
I've been adding certificates found in Censys scans to CT logs, and
happened to spot
On Thu, 2 May 2019 18:53:39 -0700 (PDT)
Corey Bonnell via dev-security-policy
wrote:
> As an aside, I noticed that several URLs listed in CCADB are “Legal
> Repository” web page URLs that contain a list of many CP/CPS
> documents. My recommendation is to slightly amend CCADB Policy to
> require
Hello,
Section 4 of Mozilla Root Store Policy states that CAs are bound by the latest
Common CCADB Policy (http://ccadb.org/policy). Section 5 of the Common CCADB
Policy specifies the requirements for CAs regarding providing URLs to various
documents, such as the CP, CPS, and audit reports. In
On Thu, May 2, 2019 at 6:57 PM Daniel Marschall via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Hello,
>
> I have two improvement suggestions for the page crt.sh.
>
> I often stumble across extentions or other kind of OIDs which are not
> known/named by the system. For
Thank you for the report Alex. The following compliance bugs have been
created:
Sectigo: https://bugzilla.mozilla.org/show_bug.cgi?id=1548713
SECOM: https://bugzilla.mozilla.org/show_bug.cgi?id=1548714
DigiCert: https://bugzilla.mozilla.org/show_bug.cgi?id=1548716
- Wayne
On Thu, May 2, 2019 at
Hello,
I have two improvement suggestions for the page crt.sh.
I often stumble across extentions or other kind of OIDs which are not
known/named by the system. For example the extention 1.3.6.1.5.5.7.1.24
(1) It would be great if all OIDs could automatically get a hyperlink pointing
to
> But does EN 319 401, as it existed in 2016/2017 incorporate a clause to
> apply all "future" updates to the CAB/F regulations or otherwise cover
> all BRs applicable to the 2016/2017 timespan?
Interesting question. Would it have to explicitly claim to incorporate any
future updates? Or would
On Thu, 2 May 2019 12:15:33 -0500
Alex Cohn via dev-security-policy
wrote:
> I came across a number of certificates issued by Sectigo, SECOM, and
> DigiCert that list "Default City" as the subject's locality. Unless
> there are actually localities named "Default City" that I'm unaware
> of, it
On Thursday, May 2, 2019 at 1:11:20 AM UTC+2, Wayne Thayer wrote:
> Correct - 319 411 was (and still is) the Mozilla audit requirement.
>
> [1] https://bug937589.bmoattachments.org/attachment.cgi?id=8898169
Thanks for the clarification Wayne.
___
Hi all,
I came across a number of certificates issued by Sectigo, SECOM, and
DigiCert that list "Default City" as the subject's locality. Unless there
are actually localities named "Default City" that I'm unaware of, it seems
to me this is a violation of the BRs, sections 3.2.2.1 and 7.1.4.2.2.e.
Just want to make it very clear to everyone, that the proposal, to add
the following text to section 6 of Mozilla's Root Store Policy would
mean that certs constrained to id-kp-emailProtection (end-entity and
intermediate), i.e. S/MIME certs, would be subject to the same BR rules
and
On Thu, May 2, 2019 at 9:14 AM Fotis Loukos wrote:
> The PCA (I am calling it PCA even if it does not follow all the design
> and architecture of RFC5288 PCAs for simplicity's sake) has the
> technical ability to issue both TLS and S/MIME end-entity certs but is
> constrained to issue only
Hello,
On 30/4/19 8:26 μ.μ., Ryan Sleevi via dev-security-policy wrote:
> On Tue, Apr 30, 2019 at 1:10 PM Fotis Loukos wrote:
>
>> I am just arguing that there is no risk involved in having a single
>> certificate. I do agree that the model you proposed with the two
>> certificates is a model
13 matches
Mail list logo