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 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 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 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, 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 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
>>
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 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
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
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
ice Operations - Infrastructure Operations
>
> VA Office of Information and Technology, IT Operations and Services
>
> Mobile (571) 235-5277
>
>
>
>
>
>
>
> *From:* Eric Mill
> *Sent:* Tuesday, November 26, 2019 4:28 PM
> *To:* Peter Bowen
> *Cc:* Bowen,
a trusted CA, then the certificate is trusted.
If you provide the full issuer name for the certificate you are referring
to, then it might be possible to determine if you are actually on a
government-only certificate or if you have some other issue.
Thanks,
Peter
>
>
>
>
> *Fr
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 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 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
(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 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
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 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.
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 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
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 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
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 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 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 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 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 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, 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 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, 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, 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 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 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 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
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 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
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 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
> > >
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 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
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
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
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
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
e?
>
> On Fri, Mar 23, 2018 at 6:18 PM, Peter Bowen wrote:
>>
>> 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 iss
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
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 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 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 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 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 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 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 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 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 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 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 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 Sat, Dec 9, 2017 at 11:42 AM, Lewis Resmond via dev-security-policy
wrote:
> I was researching about some older routers by Telekom, and I found out that
> some of them had SSL certificates for their (LAN) configuration interface,
> issued by Verisign for the fake-domain "speedport.ip".
>
> Th
This has been discussed previously and my recollection is that
multiple CNs are allowed as long as each one has a single entry from
the subjectAlternativeName extension.
On Sun, Oct 29, 2017 at 11:42 AM, Hanno Böck via dev-security-policy
wrote:
> Hi,
>
> This certificate has a duplicate commonna
are roots currently listed at
https://ccadb-public.secure.force.com/mozilla/IncludedCACertificateReport)
Thanks,
Peter
> -Original Message-
> From: dev-security-policy
> [mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
> .org] On Behalf Of Peter Bo
On Tue, Oct 17, 2017 at 2:06 AM, Gervase Markham wrote:
> On 16/10/17 20:22, Peter Bowen wrote:
>> Will the new managed CAs, which will operated by DigiCert under
>> CP/CPS/Audit independent from the current Symantec ones, also be
>> included on the list of subCAs that will
On Mon, Oct 16, 2017 at 10:32 AM, Gervase Markham via
dev-security-policy wrote:
> As per previous discussions and
> https://wiki.mozilla.org/CA:Symantec_Issues, a consensus proposal[0] was
> reached among multiple browser makers for a graduated distrust of
> Symantec roots.
>
> Here is Mozilla’s
On Thu, Oct 12, 2017 at 3:54 PM, Andrew R. Whalley via
dev-security-policy wrote:
> I have reviewed SSLcom_CP_CPS_Version_1_2_1 and made the following notes:
>
> 1.3.2.1
>
> "may contractually authorize the Subject of a specified Valid EV
> Certificate to perform the RA function and authorize SSL.
On Tue, Sep 12, 2017 at 5:59 AM, Dmitry Belyavsky via
dev-security-policy wrote:
> Here is the new version of the draft updated according to the discussion on
> mozilla-dev-security list.
Given that RFC 5914 already defines a TrustAnchorList and
TrustAnchorInfo object and that the Trust Anchor Li
On Sat, Oct 7, 2017 at 12:23 PM, David E. Ross via dev-security-policy
wrote:
> Somehow, I recall there had been a problem with the SecureTrust
> Corporation certification authority. It was either a problem with one
> or more of the root certificates or with the way the certification
> authority
On Sat, Sep 23, 2017 at 6:28 PM, Ryan Sleevi wrote:
>
>
> On Fri, Sep 22, 2017 at 1:00 PM, Peter Bowen via dev-security-policy
> wrote:
>>
>> Ryan,
>>
>> As an existing Symantec customer, I'm not clear that this really
>> addresses the challen
On Fri, Sep 22, 2017 at 6:22 AM, Nick Lamb via dev-security-policy
wrote:
> On Friday, 22 September 2017 05:01:03 UTC+1, Peter Bowen wrote:
>> I realize this is somewhat more complex than what you, Ryan, or Jeremy
>> proposed, but it the only way I see root pins working across bo
On Thu, Sep 21, 2017 at 7:17 PM, Ryan Sleevi via dev-security-policy
wrote:
> I think we can divide the discussion into two parts, similar to the
> previous mail: How to effectively transition Symantec customers with
> minimum disruption, whether acting as the Managed CA or as the future
> operato
On Tue, Sep 19, 2017 at 8:39 PM, Jeremy Rowley via dev-security-policy
wrote:
>
> The current end-state plan for root cross-signing is provided at
> https://bugzilla.mozilla.org/show_bug.cgi?id=1401384. The diagrams there show
> all of the existing sub CAs along with the new Sub CAs and root sig
On Wed, Sep 20, 2017 at 12:37 AM, Martin Rublik via
dev-security-policy wrote:
> On Tue, Sep 19, 2017 at 5:22 PM, Alex Gaynor via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> https://crt.sh/mozilla-certvalidations?group=version&id=896972 is a very
>> informative graph
On Tue, Sep 19, 2017 at 8:12 AM, Gervase Markham via
dev-security-policy wrote:
> In https://bugzilla.mozilla.org/show_bug.cgi?id=1391087 , as part of
> their comments on a report of BR-non-compliant certificate issuance, a
> representative of VISA said the following:
>
> "Visa has been operating
On Sat, Sep 9, 2017 at 1:59 PM, Andrew Ayer wrote:
> On Sat, 9 Sep 2017 13:53:52 -0700
> Peter Bowen via dev-security-policy
> wrote:
>
>> On Sat, Sep 9, 2017 at 1:50 PM, Andrew Ayer
>> wrote:
>> >
>> > drill is buggy and insecure. Obviously, such imp
On Sat, Sep 9, 2017 at 1:50 PM, Andrew Ayer wrote:
>
> drill is buggy and insecure. Obviously, such implementations can
> be found. Note that drill is just a "debugging/query" tool, not a
> resolver you would actually use in production. You'll find that the
> production-grade resolver from that
On Sat, Sep 9, 2017 at 11:50 AM, Andrew Ayer wrote:
> On Sat, 9 Sep 2017 08:49:01 -0700
> Peter Bowen via dev-security-policy
> wrote:
>
>> On Sat, Sep 9, 2017 at 3:57 AM, Jonathan Rudenberg
>> wrote:
>> >
>> >> On Sep 9, 2017, at 06:19, Pet
On Sat, Sep 9, 2017 at 3:57 AM, Jonathan Rudenberg
wrote:
>
>> On Sep 9, 2017, at 06:19, Peter Bowen via dev-security-policy
>> wrote:
>>
>> In all three of these cases, the "domain's zone does not have a DNSSEC
>> validation chain to the ICANN root&
> Certificate 3 contains a single DNS identifier for
> refused.caatestsuite-dnssec.com
> Attempts to query the CAA record for this DNS name result in a REFUSED DNS
> response. Since there is a DNSSEC validation chain from this zone to the
> ICANN root, CAs are not permitted to treat the lookup fai
On Fri, Sep 8, 2017 at 12:24 PM, Andrew Ayer via dev-security-policy
wrote:
> The BRs state:
>
> "Effective as of 8 September 2017, section 4.2 of a CA's Certificate
> Policy and/or Certification Practice Statement (section 4.1 for CAs
> still conforming to RFC 2527) SHALL state the CA's policy or
On Fri, Aug 18, 2017 at 8:47 AM, Ryan Sleevi via dev-security-policy
wrote:
> On Fri, Aug 18, 2017 at 11:02 AM, Gervase Markham via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> Sometimes, CAs apply for inclusion with new, clean roots. Other times,
>> CAs apply to incl
On Tue, Aug 15, 2017 at 8:01 AM, Jeremy Rowley
wrote:
> I realize use of underscore characters was been debated and explained at the
> CAB Forum, but I think it's pretty evident (based on the certs issued and
> responses to Ballot 202) that not all CAs believe certs for SRVNames are
> prohibited.
On Tue, Aug 15, 2017 at 4:20 AM, Gervase Markham via
dev-security-policy wrote:
> On 06/07/17 16:56, Ryan Sleevi wrote:
>> Relevant to this group, id-kp-serverAuth (and perhaps id-kp-clientAuth)
>
> So what do we do? There are loads of "name-constrained" certs out there
> with id-kp-serverAuth but
On Sun, Aug 13, 2017 at 5:59 PM, Matt Palmer via dev-security-policy
wrote:
> On Fri, Aug 11, 2017 at 06:32:11PM +0200, Kurt Roeckx via dev-security-policy
> wrote:
>> On Fri, Aug 11, 2017 at 11:48:50AM -0400, Ryan Sleevi via
>> dev-security-policy wrote:
>> >
>> > Could you expand on what you m
Congratulations on finding something not caught by certlint. It turns
out that cabtlint does zero checks for reserved IPs. Something else
for my TODO list.
On Sat, Aug 12, 2017 at 6:52 PM, Jonathan Rudenberg via
dev-security-policy wrote:
> Baseline Requirements section 7.1.4.2.1 prohibits ipAd
On Thu, Aug 10, 2017 at 1:22 PM, Jonathan Rudenberg via
dev-security-policy wrote:
> RFC 5280 section 7.2 and the associated IDNA RFC requires that
> Internationalized Domain Names are normalized before encoding to punycode.
>
> Let’s Encrypt appears to have issued at least three certificates tha
On Thu, Aug 10, 2017 at 2:31 PM, Jakob Bohm via dev-security-policy
wrote:
> On 10/08/2017 22:22, Jonathan Rudenberg wrote:
>>
>> RFC 5280 section 7.2 and the associated IDNA RFC requires that
>> Internationalized Domain Names are normalized before encoding to punycode.
>>
>> Let’s Encrypt appears
The point of certlint was to help identify issues. While I appreciate
it getting broad usage, I don't think pushing for revocation of every
certificate that trips any of the Error level checks is productive.
This reminds of me of people trawling a database of known
vulnerabilities then reporting t
(inserted missed word; off to get coffee now)
On Mon, Aug 7, 2017 at 7:54 AM, Peter Bowen wrote:
> On Mon, Aug 7, 2017 at 12:53 AM, Franck Leroy via dev-security-policy
> wrote:
>> Hello
>>
>> I checked only one but I think they are all the same.
>>
>> The i
On Mon, Aug 7, 2017 at 12:53 AM, Franck Leroy via dev-security-policy
wrote:
> Hello
>
> I checked only one but I think they are all the same.
>
> The integer value of the serial number is 20 octets, but when encoded into
> DER a starting 00 may be necessary to mark the integer as a positive valu
On Wed, Aug 2, 2017 at 8:10 PM, Peter Gutmann via dev-security-policy
wrote:
> Jeremy Rowley via dev-security-policy
> writes:
>
>>Today, DigiCert and Symantec announced that DigiCert is acquiring the
>>Symantec CA assets, including the infrastructure, personnel, roots, and
>>platforms.
>
> I re
On Wed, Aug 2, 2017 at 2:12 PM, Jeremy Rowley via dev-security-policy
wrote:
> Today, DigiCert and Symantec announced that DigiCert is acquiring the
> Symantec CA assets, including the infrastructure, personnel, roots, and
> platforms. At the same time, DigiCert signed a Sub CA agreement wherein
On Mon, Jul 31, 2017 at 7:17 AM, Jakob Bohm via dev-security-policy
wrote:
> On 31/07/2017 16:06, Gervase Markham wrote:
>>
>> On 31/07/17 15:00, Jakob Bohm wrote:
>>>
>>> - Due to current Mozilla implementation bugs,
>>
>>
>> Reference, please?
>>
>
> I am referring to the fact that EV-trust is c
On Thu, Jul 27, 2017 at 11:14 PM, Gervase Markham via
dev-security-policy wrote:
> Google have made a final decision on the various dates they plan to
> implement as part of the consensus plan in the Symantec matter. The
> message from blink-dev is included below.
>
[...]
>
> We now have two choic
Steve,
I think this level of public detail is very helpful when it comes to
understanding the proposal.
On Thu, Jul 20, 2017 at 8:00 AM, Steve Medin via dev-security-policy
wrote:
> 1) December 1, 2017 is the earliest credible date that any RFP
> respondent can provide the Managed CA solut
Richard,
I can only guess what Ryan is talking about as the report wasn't sent
to this group, but it is possible that the system described could not
meet the Baseline Requirements, as the BRs do require certain system
designs. For example, two requirements are:
"Require that each individual in a
> On Jul 5, 2017, at 4:23 AM, Gervase Markham via dev-security-policy
> wrote:
>
> On 03/07/17 17:44, Peter Bowen wrote:
>> We still need to get the policy changed, even with the ballot. As
>> written right now, all name constrained certificates are no longer
&
it'll be
> passed by the time the Mozilla policy is updated.
>
> -Original Message-
> From: dev-security-policy
> [mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
> .org] On Behalf Of Peter Bowen via dev-security-policy
> Sent: Monday, July
In reviewing the Mozilla CA policy, I noticed one bug that is probably
my fault. It says:
"name constraints which do not allow Subject Alternative Names (SANs)
of any of the following types: dNSName, iPAddress, SRVName,
rfc822Name"
SRVName is not yet allowed by the CA/Browser Forum Baseline
Requ
On Fri, Jun 23, 2017 at 6:17 AM, Rob Stradling via dev-security-policy
wrote:
> On 23/06/17 14:10, Kurt Roeckx via dev-security-policy wrote:
>>
>> On 2017-06-23 14:59, Rob Stradling wrote:
>>>
>>> Reasons:
>>>- Some are only trusted by the old Adobe CDS program.
>>>- Some are only trusted
1 - 100 of 402 matches
Mail list logo
