Re: Action on Camerfirma Root CAs
I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1692094 to turn off the Websites trust bit for the 2008 root certs, and to set the "Distrust for S/MIME After Date" for the older root certs. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.7.1: MRSP Issue #186: Requirement to Disclose Self-signed Certificates
In the Github document, which I'm using to track proposed language, I've added "This applies to all non-technically constrained CA certificates, including those that share the same key pair whether they are self-signed, doppelgänger, reissued, cross-signed, or other roots." https://github.com/BenWilson-Mozilla/pkipolicy/commit/5a3dd2e9d92ec689e08bf1cfa279121e2bb0478b . On Sun, Jan 24, 2021 at 3:12 PM Ben Wilson wrote: > As an alternative for this addition to MRSP section 5.3, please consider > and comment on: > > Thus, the operator of a CA certificate trusted in Mozilla’s CA Certificate > Program MUST disclose in the CCADB all non-technically constrained CA > certificates they issue that chain up to that CA certificate trusted in > Mozilla’s CA Certificate Program. This applies to all non-technically > constrained CA certificates, including those that are self-signed, > doppelgänger, reissued, or cross-signed. > > > On Thu, Nov 12, 2020 at 11:54 AM Ben Wilson wrote: > >> Jakob, >> >> On Thu, Nov 12, 2020 at 10:39 AM Jakob Bohm via dev-security-policy < >> dev-security-policy@lists.mozilla.org> wrote: >> >>> >>> How would that phrasing cover doppelgangers of intermediary SubCAs under >>> an included root CA? >>> >>> >>> To clarify, the title of section 5.3 is "Intermediate Certificates". >> Also, both subsection (1) and (2) under the proposed amendment reference >> "intermediate certificates" - "(1) ...the Subject Distinguished Name in a >> CA certificate or *intermediate certificate* that is in scope according >> to section 1.1 of this Policy" and "(2)... corresponding Public Key is >> encoded in the SubjectPublicKeyInfo of that CA certificate or *intermediate >> certificate*." And finally, additional >> language would try and make this clear by saying, "Thus, these >> requirements also apply to so-called reissued/doppelganger CA certificates >> (roots *and intermediates*) and to cross-certificates." >> >> I hope this answers your question. >> >> Sincerely, >> >> Ben >> > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: The CAA DNS Operator Exception Is Problematic
On Wed, Feb 10, 2021 at 02:21:53AM +, Nick Lamb via dev-security-policy wrote: > On Mon, 8 Feb 2021 13:40:05 -0500 > Andrew Ayer via dev-security-policy > wrote: > > > The BRs permit CAs to bypass CAA checking for a domain if "the CA or > > an Affiliate of the CA is the DNS Operator (as defined in RFC 7719) > > of the domain's DNS." > > Hmm. Would this exemption be less dangerous for a CA which is the > Registry for the TLD ? I understand this would remove one way to shoot yourself in the foot. > [...], but it seems like it's pretty clear > that either you are the registry for some TLD or you aren't, and so > that confusion ought not to arise in this case. The argument is that theoretically this could work, but in practice people get this wrong. Examples were given that confusion in fact happens. -- pozdrawiam / best regards Wojtek Porczyk Graphene / Invisible Things Lab I do not fear computers, I fear lack of them. -- Isaac Asimov signature.asc Description: PGP signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: The CAA DNS Operator Exception Is Problematic
On Tue, Feb 9, 2021 at 9:22 PM Nick Lamb via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Mon, 8 Feb 2021 13:40:05 -0500 > Andrew Ayer via dev-security-policy > wrote: > > > The BRs permit CAs to bypass CAA checking for a domain if "the CA or > > an Affiliate of the CA is the DNS Operator (as defined in RFC 7719) > > of the domain's DNS." > > Hmm. Would this exemption be less dangerous for a CA which is the > Registry for the TLD ? Potentially, but that’s not the use case for why this exists. Recall that Registry != Registrar here, and even then, the Operator may be distinct from either of those two. The use case argued was not limited to “just” gTLDs. > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
