On Fri, Aug 23, 2019 at 2:00 PM Jeremy Rowley
wrote:
>
>
>- Could you highlight a bit more your proposal here? My understanding
>is that, despite the Handelsregister ("Commercial Register") being
>available at a country level, it's further subdivided into a list of
>couunty or
On Thu, Aug 22, 2019 at 10:29 PM Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> I posted this tonight:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1576013. It's sort of an
> extension of the "some-state" issue, but with the incorporation information
>
On Thu, Aug 22, 2019 at 12:46 AM Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Hey all,
>
> An interesting issue came up recently with audits. Because the Mozilla
> policy includes some requirements that diverge from the BRs, the audit
> criteria don't
I've recently shared some choice words with several CAs over their Incident
Reporting process, highlighting to them how their approach is seriously
undermining trust in their CA and the operations.
While https://wiki.mozilla.org/CA/Responding_To_An_Incident provides
Guidance on the minimum
(Apologies if this triple or quadruple posts. There appears to be some
hiccups somewhere along the line between my mail server and the m.d.s.p.
mail server)
I've recently shared some choice words with several CAs over their Incident
Reporting process, highlighting to them how their approach is
(Apologies if this double posts; (my || the) e-mail gateway seems to be having
some trouble so I'm trying this through the Google Groups interface)
I've recently shared some choice words with several CAs over their Incident
Reporting process, highlighting to them how their approach is seriously
(Apologies if this triple or quadruple posts. There appears to be some
hiccups somewhere along the line between my mail server and the m.d.s.p.
mail server and the Google Groups reflector)
I've recently shared some choice words with several CAs over their Incident
Reporting process, highlighting
On Mon, Aug 19, 2019 at 10:26 AM Mathew Hodson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> If these situations were common, it could create a chilling effect on
> problem reporting that would hurt the WebPKI ecosystem. Are specific
> procedures and handling of
On Tue, Aug 13, 2019 at 11:12 AM Nuno Ponte via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Dear m.d.s.p.,
>
> I would like to bring into discussion the use of certificate/public key
> pinning and the impacts on the 5-days period for certificate revocation
> according to
On Wed, Aug 14, 2019 at 1:16 PM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> EV was originally an initiative to make the CAs properly vet OV
> certificates, and to mark those CAs that had done a proper job.
> EV issuing CAs were permitted to still sell the
On Wed, Aug 7, 2019 at 6:28 PM Kathleen Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> I have been working towards extending Audit Letter Validation (ALV) to
> intermediate certificate records in the CCADB. This is involving some
> changes.
>
> I added a field to
on the BR definition, so there could be
> advantages to creating multiple intermediate signed CAs which I haven’t
> considered yet. What definition/approach were you assuming?
>
>
>
> See responses in-line below
>
>
>
> From: Doug Beattie
> Sent: Monday, August 5, 2019 7:
t;
>
>
> See responses in-line below
>
>
>
> From: Doug Beattie
> Sent: Monday, August 5, 2019 7:29 AM
> To: Doug Beattie
> Subject: Re: FW: Entrust Root Certification Authority - G4 Inclusion
> Request
>
>
>
>
>
> On Mon, Aug 5, 2019 at 7:12 AM Do
On Fri, Aug 2, 2019 at 9:59 AM Doug Beattie
wrote:
> Ryan,
>
> GlobalSign has been thinking along these lines, but it's not clear how
> browsers build their path when a cross certificate is presented to them in
> the TLS handshake.
>
Excellent! Happy to help in any way to make that possible and
On Fri, Jul 26, 2019 at 4:29 PM Bruce via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Friday, July 26, 2019 at 1:45:06 PM UTC-4, Ryan Sleevi wrote:
> > (In a personal capacity, as normally noted but making sure to extra-note
> it
> >
(In a personal capacity, as normally noted but making sure to extra-note it
here)
Hi Wayne,
It wasn't clear to me from the inclusion request, did Entrust give a reason
for the requested addition? For example, do they plan to stop issuing from
one of the included roots and have it removed?
In
On Wed, Jul 17, 2019 at 8:09 PM Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Just FYI, there is an upcoming change in control event that will happen at
> DigiCert where TA and Clearlake will take equity ownership of the company.
> TA is currently a
For the easiest one first: with respect to the GoDaddy disclosure [1 (your
#2)], I can't see either certificate being disclosed in the audit report.
That definitely sounds like a clear and obvious incorrect disclosure - but
perhaps I'm missing something?
With respect to the Sectigo disclosure [2
On Sun, Jul 14, 2019 at 8:32 PM Vincent Lours via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Monday, 15 July 2019 04:41:12 UTC+10, Ryan Sleevi wrote:
> > Thanks for mentioning this here.
> >
> > Could you explain why you see it as an issu
Thanks for mentioning this here.
Could you explain why you see it as an issue? RFC 5280 defines a trust
anchor as a subject and a public key. Everything else is optional, and the
delivery of a trust anchor as a certificate does not necessarily imply the
constraints of that certificate, including
> remote issuance)..
>
> I think this is section you are citing as prohibiting issuance correct? So
> as long as the CA can show that this is not true, then issuance is
> permitted under the current policy.
>
>
>
> -Original Message-
> From: dev-security-policy
Alternatively:
There is zero reason these should be included in publicly trusted certs
used for TLS, and ample harm. It is not necessary nor essential to securing
TLS, and that should remain the utmost priority.
CAs that wish to issue such certificates can do so from alternate
hierarchies. There
On Wed, Jul 10, 2019 at 3:17 PM Nadim Kobeissi
wrote:
> Many times in this discussion, we have all been offered a choice between
> two paths. The first path would be to examine difficult problems and
> shortcomings together and attempting to present incremental--often
> onerous--improvements.
On Wed, Jul 10, 2019 at 2:41 PM housley--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> People find logos very helpful. That is why many browsers display a tiny
> logo in the toolbar.
>
Are you talking the favicon? An attacker controlled resource which should
not be
On Wed, Jul 10, 2019 at 2:15 PM Nadim Kobeissi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Indeed I would much rather focus on the rest of the elements in the Mozilla
> Root Store Policy (
>
>
On Wed, Jul 10, 2019 at 1:07 PM Nadim Kobeissi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> I would like to support the statements made by both Fabio and Scott to the
> extent that if Mozilla is to go forward with this decision, then I fully
> expect them to review
On Wed, Jul 10, 2019 at 12:29 PM fabio.pietrosanti--- via
dev-security-policy wrote:
> Said that, given the approach that has been following with DarkMatter
> about "credible evidence" and "people safety" principles, i would strongly
> argue that Mozilla should take action against the subject
On Tue, Jul 9, 2019 at 5:50 PM Kathleen Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> All,
>
> There is some confusion about disclosure of new intermediate certs that
> are issued to subordinate CAs with currently valid audit statements.
>
> Section 5.3.2 of
roups.google.com/d/msg/mozilla.dev.security.policy/nZoK5akw2c8/ZtF0WZY8AgAJ
>
> On Tue, Jun 18, 2019 at 6:47 AM Jakob Bohm via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > On 14/06/2019 18:54, Ryan Sleevi wrote:
> > > On F
On Fri, Jun 14, 2019 at 4:12 PM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> In such a case, there are two obvious solutions:
>
> A. Trademark owner (prompted by applicant) provides CA with an official
>permission letter stating that Applicant is
On Thu, Jun 13, 2019 at 2:04 AM kirkhalloregon--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Jeremy is correct - including strongly verified registered trademarks via
> extensions in EV certs is permitted (i.e., not forbidden) by BR Section
> 7.1.2.4.
It's unclear
I agree with Corey.
On Wed, Jun 12, 2019 at 4:28 AM Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> That argument applies to every extension not expressly permitted by the
> BRs.
Yup. It definitely puts the onus on the CA to demonstrate how they're not
On Tue, May 28, 2019 at 1:03 PM Nick Lamb via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> If they shove an valid but nonsensical policy OID into a cert I don't know
> what Mozilla policy about that would be, but certainly the browser and
> common TLS clients will just
On Monday, May 27, 2019, Matt Palmer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Mon, May 27, 2019 at 06:06:42AM +0300, Ryan Sleevi wrote:
> > On Mon, May 27, 2019 at 4:34 AM Matt Palmer via dev-security-policy <
> > dev-security-policy@
On Mon, May 27, 2019 at 4:34 AM Matt Palmer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Hi everyone,
>
> In pondering ways of getting yet more keys for pwnedkeys.com, my mind
> turned
> to everyone's favourite bug, Heartbleed. Whilst hitting all the vulnerable
>
On Wed, May 22, 2019 at 7:43 PM Brian Smith wrote:
> Ryan Sleevi wrote:
>
>>
>>
>>> It would be easier to understand if this is true if the proposed text
>>> cited the RFCs, like RFC 4055, that actually impose the requirements that
>>> result in the
On Tue, May 21, 2019 at 3:32 PM Daniel McCarney wrote:
>
>> Of the 8 unrevoked, they're all issued by a single CA - GlobalSign - and
>> are all RSA keys that lack the explicit NULL parameter, and thus violate
>> the requirements of https://tools.ietf.org/html/rfc3279#section-2.3.1
>
>
>> These
On Thu, May 9, 2019 at 4:48 PM Brian Smith wrote:
> On Fri, Apr 26, 2019 at 11:39 AM Wayne Thayer wrote:
>
>> On Wed, Apr 24, 2019 at 10:02 AM Ryan Sleevi wrote:
>>
>>> Thank you David and Ryan! This appears to me to be a reasonable
>>> improvement to our
On Fri, May 17, 2019 at 1:21 AM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 17/05/2019 01:39, Wayne Thayer wrote:
> > On Thu, May 16, 2019 at 4:23 PM Wayne Thayer
> wrote:
> >
> > I will soon file a bug requesting removal of the “Certinomis - Root CA”
On Wed, May 15, 2019 at 2:10 PM Ryan Hurst via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> > Thanks. I think this is desirable to forbid, as it is insecure, and I
> > believe it's already forbidden, because the process of step (4) is
> relying
> > on GMAIL to act as a
On Wed, May 15, 2019 at 1:18 PM Ryan Hurst via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> > I think this bears expansion because I don't think it's been clearly
> > documented what flow you believe is currently permitted today that will
> be
> > prevented tomorrow
On Wed, May 15, 2019 at 11:52 AM Ryan Hurst via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> I believe the case where Google requests a certificate from the CA is
> accommodated but not the case where SAAS requests a certificate from the CA
> based on the authentication
On Wed, May 15, 2019 at 9:28 AM Ryan Hurst via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Pedro,
>
> That scenario is addressed by Wayne proposed change.
>
> That same change does not allow for applications that use GMail or there
> federated authentication providers to
On Mon, May 13, 2019 at 1:25 PM Wayne Thayer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> The BRs forbid delegation of domain and IP address validation to third
> parties. However, the BRs don't forbid delegation of email address
> validation nor do they apply to
On Fri, May 10, 2019 at 3:55 PM Jeremy Rowley
wrote:
> The analysis was basically that all the verification documents are still
> good, which means if we issued the cert today, the issuance would pass
> without further checks (since the data itself is good for 825 days).
> Because of this,
On Thu, May 9, 2019 at 10:05 PM Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> We checked all the applicable CAA records and found 16 where the CAA record
> would not permit us to issue if we were issuing a new cert today. What we
> are proposing is to
On Thu, May 9, 2019 at 10:44 PM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 09/05/2019 16:35, Ryan Sleevi wrote:
> > Given that the remark is that such a desire is common, perhaps you can
> > provide some external references documen
On Thu, May 9, 2019 at 8:59 AM Han Yuwei via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Hi m.d.s.p
> I have reported a key compromise incident to digicert by contacting
> support(at)digicert.com at Apr.13, 2019 and get replied at same day. But
> it seems like this
On Wed, May 8, 2019 at 10:36 PM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> [ Note, I am arguing a neutral position on the specific proposal ]
>
> The common purpose of having an internally secured (managed or on-site)
> CA in a public hierarchy is to have
On Tue, May 7, 2019 at 7:48 PM Wayne Thayer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> To continue to participate in the Mozilla CA program, I recommend that we
> require Certinomis to create a new hierarchy and demonstrate their ability
> to competently operate
On Wed, May 8, 2019 at 6:42 AM Fotis Loukos wrote:
> I agree with you that technically verifiable controls are always better
> than procedural controls, however we are already relying on procedural
> controls for many of the requirements, such as CAA. In addition, this
> specific change can be
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
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
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 that can be used right now, but I do not see any
> additional risks by having a
On Tue, Apr 30, 2019 at 11:49 AM Fotis Loukos wrote:
> On 30/4/19 6:34 μ.μ., Ryan Sleevi via dev-security-policy wrote:
> > On Tue, Apr 30, 2019 at 8:51 AM Fotis Loukos wrote:
> >
> >> Hello Ryan,
> >>
> >> On 29/4/19 5:20 μ.μ., Ryan Sleevi via dev-s
On Tue, Apr 30, 2019 at 8:51 AM Fotis Loukos wrote:
> Hello Ryan,
>
> On 29/4/19 5:20 μ.μ., Ryan Sleevi via dev-security-policy wrote:
> > On Fri, Apr 26, 2019 at 7:02 PM Wayne Thayer via dev-security-policy <
> > dev-security-policy@lists.mozilla.org> wrote:
> >
On Fri, Apr 26, 2019 at 5:39 PM Wayne Thayer wrote:
> This does not, however, address the last part of what Brian proposes -
>> which is examining if, how many, and which CAs would fail to meet these
>> encoding requirements today, either in their roots, subordinates, or leaf
>> certificates.
>>
On Fri, Apr 26, 2019 at 7:02 PM Wayne Thayer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> In version 2.6 of our Root Store Policy, we added the requirement to
> section 5.3 that intermediate certificates contain an EKU and separate
> serverAuth and emailProtection
On Wed, Apr 17, 2019 at 5:22 PM Wayne Thayer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Yesterday, Andrew Ayer filed a bug [1] identifying 14 pre-certificates
> issued by Certinomis in February 2019 containing an unregistered domain
> name. Since the cause described
On Mon, Apr 22, 2019 at 6:20 PM Brian Smith wrote:
> There are three (that I can think of) sources of confusion:
>
> 1. Is there any requirement that the signature algorithm that is used to
> sign a certificate be correlated in any way to the algorithm of the public
> key of the signed
On Thu, Apr 18, 2019 at 9:56 AM Sándor dr. Szőke via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Thank you for the valuable information.
>
>
> I try to summarize the possibilities to issue PSD2 QWAC certificates.
>
> - If a CA issues PSD2 QWAC certificate now, it SHALL
On Wed, Apr 17, 2019 at 2:23 PM Doug Beattie
wrote:
>
> The ETSI requirements for QWAC are complicated and not all that clear to
> me, but is it possible to use OV certificate and Policy OIDs as the base
> instead of EV? Since OV permits additional Subject Attributes, then that
> approach would
On Wed, Apr 17, 2019 at 11:20 AM Sándor dr. Szőke via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Extended Validation (EV) certificates and EU Qualified certificates for
> website authentication (QWAC).
>
>
> European Union introduced the QWAC certificates in the eIDAS
On Tue, Apr 16, 2019 at 12:41 PM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 16/04/2019 08:56, Tadahiko Ito wrote:
> > On Tuesday, April 2, 2019 at 9:36:06 AM UTC+9, Brian Smith wrote:
> >
> >> I agree the requirements are already clear. The problem is
On Wed, Apr 10, 2019 at 12:23 PM Wayne Thayer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> I'm either confused, or I disagree. We're talking about a certificate that
> deviates from a "SHOULD" in RFC 5280, correct? Our guidance on incidents
> [1] defines misissuance,
On Tue, Apr 9, 2019 at 11:25 AM Nick Lamb via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Mozilla's wiki has a page about the subCAs
>
> https://wiki.mozilla.org/CA/Intermediate_Certificates
>
> On that page I see a link labelled:
>
> "Non-revoked, non-expired
On Tue, Apr 9, 2019 at 10:39 AM Lijun Liao wrote:
> Just makes it clear: The extension KeyUsage is optional in subscriber's
> certificate. But what happens if it is present and is NOT critical?
>
RFC 5280 says SHOULD, not MUST. RFC 2119 defines SHOULD as:
3. SHOULD This word, or the
1. Open
https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.6.4.pdf
2. Search for "KeyUsage"
- 11 occurrences
#1
7.1.2.1 Root CA Certificate
b. keyUsage
This extension MUST be present and MUST be marked critical ...
#3
7.1.2.2 Subordinate CA Certificate
e. keyUsage
This
Thanks for raising this, Wayne.
As mentioned on the issue, this heavily overlaps with the RSA combinations
- and, of course, Mozilla policy being more strict than the BRs in
forbidding DSA.
Given that CAs have struggled with the relevant encodings, both for the
signatureAlgorithm and the
On Thu, Mar 28, 2019 at 7:14 PM Wayne Thayer wrote:
> The confusion that motivated the proposal was with the inconsistent
> definition of the term "technically constrained" in sections 1.1 and 5.3.
> It was not directly related to the BRs. My proposed changes take into
> account the definition
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 <
>> dev-security-policy@lists.mozilla.org> wrote:
>>
>>> **Incidents**
&
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
> comply with our policy, but this is not a requirement of our policy. There
> is no obvious place to
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 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
I'm not sure whether it's necessary to indicate support, but since silence
can sometimes be ambiguously interpreted: I support these changes and
believe they achieve the desired outcome.
___
dev-security-policy mailing list
On Mon, Mar 25, 2019 at 5:30 PM Matthew Hardeman via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> My ultimate intent was to try to formulate a way in which GRCA could
> provide certificates for the applications that they're having to support
> for their clients today
On Fri, Mar 22, 2019 at 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 issuance
> > apply to
On Sat, Mar 16, 2019 at 12:49 PM Wayne Thayer wrote:
> Ryan - Thank you for the feedback.
>
> On Fri, Mar 15, 2019 at 6:14 PM Ryan Sleevi wrote:
>
>> While I realize the thinking is with regards to the recent serial number
>> issue, a few questions emerge:
>>
>
While I realize the thinking is with regards to the recent serial number
issue, a few questions emerge:
1) Based on the software vendor reporting, they don’t view this as a
software defect, but a CA misconfiguration. Do you believe the current
policy, as worded, addresses that ambiguity?
2)
To echo Tim's remarks, this is really two issues:
1) A failure of controls (the current incident report)
2) A failure to revoke
I'm rather concerned about #2 and the lack of detail presently provided
regarding it, as well as the one week wait to filing the incident report
for #1.
On Fri, Mar 15, 2019 at 4:40 PM Jan Schaumann via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Ryan Sleevi via dev-security-policy
> wrote:
>
> > I don't think we here will really be able to do anything for this; as you
> > note, this
On Fri, Mar 15, 2019 at 12:31 PM Jan Schaumann via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> I also think that's reasonable, since any number of services might host
> their apps on the provider's platform, so they likely have a large
> number of CNAME records pointing
On Fri, Mar 15, 2019 at 3:35 PM Daymion Reynolds via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> > On Wednesday, March 13, 2019 at 8:17:00 PM UTC-4, Daymion Reynolds wrote:
> >
> > > In accordance with our conversations to date, prior to 3/7 6:30pm AZ
> we utilized raw
I’m not sure I follow - when you go someapp.example.com to
someapp.thirdparty.example, and they point to somewhere.somecdn.example,
why is the assumption that somewhere.somecdn.example WOULDN’T place a CAA
record?
Given that somewhere.somecdn.example has the business relationship with the
CA to
On Fri, Mar 15, 2019 at 12:36 AM Jaime Hablutzel via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Could you please provide me a link to a previous discussion where the
> negative was stated, maybe by the module owner?. But note that I'm not
> asking for a bespoke or
On Thu, Mar 14, 2019 at 11:16 PM Jaime Hablutzel via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> So I would like to ask again if there is any possibility to implement some
> type of exceptions handling as asked in [2].
>
This has been repeatedly and unambiguously
On Thu, Mar 14, 2019 at 6:54 PM James Burton via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Let's Encrypt CA software 'Boulder' is open source for everyone to browse
> and check for issues. All other CAs should follow the Let's Encrypt lead
> and open source their own
On Wed, Mar 13, 2019 at 6:09 PM Peter Gutmann via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Richard Moore via dev-security-policy <
> dev-security-policy@lists.mozilla.org> writes:
>
> >If any other CA wants to check theirs before someone else does, then now
> is
>
On Tue, Mar 12, 2019 at 11:18 PM bif via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> FWIW, the easiest would've been to remove "positive" aspect of serials.
> Who really cares? A random number is a random number.
>
RFC 5280 cares, as it's been a long-standing source of
On Tue, Mar 12, 2019 at 4:57 PM Hector Martin 'marcan'
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 have a on
On Tue, Mar 12, 2019 at 4:38 PM Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> I think the primary change I’m proposing is that the initial report
> shouldn’t be an incident report. Instead, the initial report can be short
> blurb posted to Mozilla along
On Tue, Mar 12, 2019 at 4:23 PM Daymion Reynolds via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Tuesday, March 12, 2019 at 11:32:38 AM UTC-7, Ryan Sleevi wrote:
> > On Tue, Mar 12, 2019 at 2:22 PM Daymion Reynolds via dev-security-policy
> <
&g
On Tue, Mar 12, 2019 at 4:17 PM Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> A new flow that includes the community more fully could be:
> 1) Post to Mozilla, the post must include an initial proposed plan of
> action
> 2) Create an incident report (to
On Tue, Mar 12, 2019 at 2:49 PM Hector Martin 'marcan' via
dev-security-policy wrote:
> What I'm saying is that merely sticking to the most convenient
> interpretation for you and deflecting all responsibility for how we
> ended up here is not productive, and does not scream trustworthiness.
>
On Tue, Mar 12, 2019 at 2:22 PM Daymion Reynolds via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> The crux of the difference is in the DER format interpretation. The fact
> prefix (0)s do count for entropy, provided none of the bits are fixed and
> you have a minimum of 8
On Tue, Mar 12, 2019 at 12:08 PM Thomas-Louis Laforest via
dev-security-policy wrote:
> Good day,
>
> I want to share what is happening right now with the insistance of a
> certificat for my domain.
>
> I have setup my CAA record and request a certificat form a new CA, but
> forgot to correct my
On Tue, Mar 12, 2019 at 12:07 PM Mike Kushner via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Unless you're going under the presumption that the MSB doesn't count as a
> part of the serial number (and I've never seen an RFC or requirement
> pointing to that being the
On Tue, Mar 12, 2019 at 7:14 AM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> 5. As a special exception, systems that require signing certificates
>with the same serial-number more than once (such as CT and CA
>validity adjustments) are not required
On Mon, Mar 11, 2019 at 5:35 PM Buschart, Rufus via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Since choice 1 is a logical consequence of "containing 64 bits of random
> data", I was always under the impression, that choice 2 was meant by the
> BRGs. If choice 1 is
On Mon, Mar 11, 2019 at 1:18 PM Buschart, Rufus via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Dear mdsp!
>
> I really like reading this discussion about 64 vs. 63 bits and how to read
> the BRGs as it shows a lot of passion by all of us in the PKI community.
> Never
I don’t think there’s anything inherently wrong with an approach that uses
a fixed prefix, whether of one bit or more, provided that there is at least
64 bits of entropy included in the serial prior to encoding to DER.
This means a scheme with guarantees a positive INTEGER will generate
*encoded*
301 - 400 of 1282 matches
Mail list logo
