Re: Policy 2.7 Proposal: Forbid Delegation of Email Validation for S/MIME Certificates

Jeremy: Could you describe a bit more who the actors are? Basically, it seems that the actual issuance is going to fall into one of several buckets: 1) Root CA controls Issuing CAs key 2) Issuing CA controls its own key, but is technically constrained 3) Issuing CA controls its own key, and is

RE: Policy 2.7 Proposal:Extend Section 8 to Encompass Subordinate CAs

I did flag that part as wearing my personal hat . The Trust Italia Sub CA is an example of where confusion may arise in the policy and where the complexity arises in these relationships. This was not necessarily a “new” CA from what I understood. This is also why I qualified the shut down in

RE: Policy 2.7 Proposal: Forbid Delegation of Email Validation for S/MIME Certificates

Will this permit either verification of the email address or the domain part? For example, some organizations may verify their entire domain space and then confirm contractors using a random value sent to the email address itself. They don't need the entire domain space in those cases, but

Re: Policy 2.7 Proposal: Incident Reporting Updates

Jeremy Rowley posted the following comments in a separate thread: One suggestion on incident reports is to define "regularly update" as some > period of time as non-responses can result in additional incident reports. > Maybe something along the lines of "the greater of every 7 days, the time >

Policy 2.7 Proposal: Update Appeal Process

The last sentence of section 1.2 Policy Ownership states: CAs or others objecting to a particular decision by either team MAY appeal > to the Mozilla governance module owner > who will make a > final decision. > Last year [1], Mozilla

Re: Policy 2.7 Proposal: Forbid Delegation of Email Validation for S/MIME Certificates

On Fri, Oct 4, 2019 at 4:37 PM Wayne Thayer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > One thing that might help to resolve this is a more detailed description of > the weaknesses that are present in the process described by Ryan Hurst. If > we can all agree that

Re: [FORGED] Re: Website owner survey data on identity, browser UIs, and the EV UI

On 10/3/2019 8:44 PM, Matt Palmer via dev-security-policy wrote: On Thu, Oct 03, 2019 at 05:36:50PM -0700, Ronald Crane via dev-security-policy wrote: On 10/3/2019 2:09 PM, Ryan Sleevi via dev-security-policy wrote: [snip] I guess I wasn't specific enough. I am looking for a good study that

Re: Policy 2.7 Proposal: Forbid Delegation of Email Validation for S/MIME Certificates

I'd like to revive this discussion. So far we've established that the existing "required practice" [1] is too stringent for email address validation and needs to be changed. We can do that by removing email addresses from the scope of the requirement as Kathleen proposed, or by exempting the local

Re: Policy 2.7 Proposal:Extend Section 8 to Encompass Subordinate CAs

Thanks Jeremy. On Thu, Oct 3, 2019 at 5:06 PM Jeremy Rowley wrote: > Hey Wayne, > > I think there might be confusion on how the notification is supposed to > happen. Is notification through CCADB sufficient? We've uploaded all of the > Sub CAs to CCADB including the technically constrained

RE: OCSP responder support for SHA256 issuer identifier info

(And, for the record, none of that legacy infrastructure that would Ryan mentions taking years to update exists anymore. Yay for shutting down legacy systems!) -Original Message- From: dev-security-policy On Behalf Of Jeremy Rowley via dev-security-policy Sent: Friday, October 4, 2019

RE: OCSP responder support for SHA256 issuer identifier info

The CAB forum specifies that OCSP responses MUST conform to RFC5019 or RFC 6960. The requirements do not specific which RFC to follow when processing requests, but I think you can imply that either one is required, right? Section 2.1.1. specifies that: Clients MUST use SHA1 as the hashing

Re: Policy 2.7 Proposal:Extend Section 8 to Encompass Subordinate CAs

On 2019-10-04 12:56 μ.μ., Rob Stradling wrote: Dimitris, Since CAs should already be disclosing that an intermediate certificate is "externally-operated" by populating the "Subordinate CA Owner" field in the CCADB record, what's the benefit of duplicating this information in the

Re: Policy 2.7 Proposal:Extend Section 8 to Encompass Subordinate CAs

Dimitris, Since CAs should already be disclosing that an intermediate certificate is "externally-operated" by populating the "Subordinate CA Owner" field in the CCADB record, what's the benefit of duplicating this information in the intermediate certificate itself? What happens if an

Re: OCSP responder support for SHA256 issuer identifier info

I was pointed to this interesting discussion. We were forced to support requests with SHA256 in CertID back in 2014. Not for any relevant security reasons, just because some stubborn auditors saw a red flag on the mentioning of SHA-1. We've implemented it by having both hashes in the lookup