Re: FW: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

I think we have settled on the following resolution to this issue: Add the following to section 5.2 (Forbidden and Required Practices): CAs MUST NOT generate the key pairs for end-entity certificates that have > an EKU extension containing the KeyPurposeIds id-kp-serverAuth or >

FW: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

>From: Wayne Thayer [mailto:wtha...@mozilla.com] >Sent: Monday, May 7, 2018 8:43 PM >To: Doug Beattie >Cc: Ryan Hurst ; mozilla-dev-security-policy >pol...@lists.mozilla.org> >Subject: Re: Bit encoding (AW: Policy 2.6 Proposal: Add

Re: question about DNS CAA and S/MIME certificates

On Wed, May 9, 2018 at 11:47 AM, Adrian R. via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Hello, > this question is somewhat outside the current Baseline Requirements, but... > > wouldn't it be normal for the same CAA rules for server certificates to > also apply to

question about DNS CAA and S/MIME certificates

Hello, this question is somewhat outside the current Baseline Requirements, but... wouldn't it be normal for the same CAA rules for server certificates to also apply to client certificates when the email address is for a domain that already has a valid CAA policy published in DNS? RFC 6844

Re: Mis-issuance of certificate with https in CN/SAN

On 16/03/18 10:27, Rob Stradling via dev-security-policy wrote: On 16/03/18 05:17, Jakob Bohm via dev-security-policy wrote: Please see https://crt.sh/?id=353098570=cablint Note: This is the CT precertificate. Note 2: According to crt.sh, the OCSP response for this precertificate is not