Re: Policy 2.7.1:MRSP Issue #205: Require CAs to publish accepted methods for proving key compromise

On 15/11/2020 9:44 μ.μ., Ryan Sleevi wrote: Thanks for chiming-in Peter, I have always considered this revocation reason as the absolutely "last resort" for CAs when it comes to revocation of Certificates. Especially for the revocation of end-entity Certificates for

Re: Policy 2.7.1:MRSP Issue #205: Require CAs to publish accepted methods for proving key compromise

On 2020-11-15 1:04 π.μ., Peter Bowen via dev-security-policy wrote: 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

Re: Policy 2.7.1:MRSP Issue #205: Require CAs to publish accepted methods for proving key compromise

On 2020-11-14 5:01 π.μ., Ryan Sleevi wrote: I believe it's possible to do, with the original language, but this requires the CA to proactively take steps to address that in their CP/CPS. That is, I think it'd be reasonable for an auditor to conclude that, if a CA stated "We do X, Y, Z" in

Re: Policy 2.7.1:MRSP Issue #205: Require CAs to publish accepted methods for proving key compromise

On 2020-11-13 7:17 μ.μ., Ryan Sleevi wrote: On Fri, Nov 13, 2020 at 2:55 AM Dimitris Zacharopoulos mailto:ji...@it.auth.gr>> wrote: There is transparency that the CA has evaluated some reporting mechanisms and these will be documented in the CPS. However, on an issue like

Re: Policy 2.7.1:MRSP Issue #205: Require CAs to publish accepted methods for proving key compromise

On 12/11/2020 10:51 μ.μ., Ryan Sleevi via dev-security-policy wrote: On Thu, Nov 12, 2020 at 1:39 PM Ben Wilson via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: On Thu, Nov 12, 2020 at 2:57 AM Dimitris Zacharopoulos wrote: I believe this information should be the

Re: Policy 2.7.1:MRSP Issue #205: Require CAs to publish accepted methods for proving key compromise

On 2020-11-12 8:38 μ.μ., Ben Wilson wrote: On Thu, Nov 12, 2020 at 2:57 AM Dimitris Zacharopoulos mailto:ji...@it.auth.gr>> wrote: I believe this information should be the "minimum" accepted methods of proving that a Private Key is compromised. We should allow CAs to

Re: Policy 2.7.1:MRSP Issue #205: Require CAs to publish accepted methods for proving key compromise

On 5/11/2020 10:33 μ.μ., Ben Wilson via dev-security-policy wrote: This email begins discussion of a potential change to section 6 of the Mozilla Root Store Policy . The method by which a person

Re: MRSP Issue #147 - Require EV audits for certificates capable of issuing EV certificates

On 12/11/2020 10:41 π.μ., Dimitris Zacharopoulos via dev-security-policy wrote: Finally, I would like to highlight that policy OID chaining is not currently supported in the webPKI by Browsers, so even if a CA adds a particular non-EV policyOID in an Intermediate CA Certificate, this SubCA

Re: MRSP Issue #147 - Require EV audits for certificates capable of issuing EV certificates

On 6/10/2020 11:38 μ.μ., Ben Wilson via dev-security-policy wrote: #147 - Require EV audits for certificates capable of issuing EV certificates – Clarify that EV audits are required for all intermediate certificates that are technically capable

Re: Policy 2.7.1: MRSP Issue #192: Require information about auditor qualifications in the audit report

on, Nov 9, 2020 at 2:45 AM Dimitris Zacharopoulos via dev-security-policy wrote: On 7/11/2020 3:12 μ.μ., Ryan Sleevi wrote: On Sat, Nov 7, 2020 at 4:52 AM Dimitris Zacharopoulos mailto:ji...@it.auth.gr>> wrote: I will try to further explain my thoughts on this. As we all know,

Re: Policy 2.7.1: MRSP Issue #192: Require information about auditor qualifications in the audit report

On 7/11/2020 3:12 μ.μ., Ryan Sleevi wrote: On Sat, Nov 7, 2020 at 4:52 AM Dimitris Zacharopoulos mailto:ji...@it.auth.gr>> wrote: I will try to further explain my thoughts on this. As we all know, according to Mozilla Policy "CAs MUST follow and be aware of discussions in the

Re: Policy 2.7.1: MRSP Issue #192: Require information about auditor qualifications in the audit report

illa.dev.security.policy/c/xk3BanrcljY/m/8dFyM-5pAQAJ On 2020-11-07 1:40 π.μ., Ryan Sleevi via dev-security-policy wrote: On Fri, Nov 6, 2020 at 6:08 PM Dimitris Zacharopoulos via dev-security-policy wrote: Can other people, except Ryan, follow this thread? I certainly can't. Too much informatio

Re: Policy 2.7.1: MRSP Issue #192: Require information about auditor qualifications in the audit report

Can other people, except Ryan, follow this thread? I certainly can't. Too much information, too much text, too many assumptions, makes it impossible to meaningfully participate in the discussion. ___ dev-security-policy mailing list

Re: Policy 2.7.1: MRSP Issue #152: Add EV Audit exception for Policy Constraints

On 2020-10-16 3:21 μ.μ., Ryan Sleevi wrote: On Fri, Oct 16, 2020 at 7:31 AM Dimitris Zacharopoulos via dev-security-policy <mailto:dev-security-policy@lists.mozilla.org>> wrote: On 2020-10-15 11:36 μ.μ., Ben Wilson via dev-security-policy wrote: >   This issue

Re: Policy 2.7.1: MRSP Issue #152: Add EV Audit exception for Policy Constraints

re: https://github.com/robstradling/pkipolicy/pull/1 ---- *From:* dev-security-policy on behalf of Dimitris Zacharopoulos via dev-security-policy *Sent:* 16 October 2020 12:31 *To:* Ben Wilson ; mozilla-dev-security-policy *Subject:* Re: Policy 2.7.1: MRSP Issue

Re: Policy 2.7.1: MRSP Issue #152: Add EV Audit exception for Policy Constraints

On 2020-10-15 11:36 μ.μ., Ben Wilson via dev-security-policy wrote: This issue is presented for resolution in the next version of the Mozilla Root Store Policy. It is related to Issue #147 (previously posted for discussion on this list on

Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

On 6/7/2020 11:39 π.μ., Paul van Brouwershaven via dev-security-policy wrote: As follow up to Dimitris comments I tested the scenario where a sibling issuing CA [ICA 2] with the OCSP signing EKU (but without digitalSignature KU) under [ROOT] would sign a revoked OCSP response for [ICA] also

Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

On 6/7/2020 11:03 π.μ., Ryan Sleevi via dev-security-policy wrote: Yep. You have dismissed it but others may have not. If no other voices are raised, then your argument prevails:) I mean, it’s not a popularity contest:) As others have highlighted already, there are times where people get

Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

On 6/7/2020 9:47 π.μ., Ryan Sleevi wrote: I can understand wanting to wait to see what others do first, but that’s not leadership. This is a security community, and it is expected to see and learn from others, which is equally good of proposing new things. I'm not sure what you mean by

Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

I'd like to chime-in on this particular topic because I had similar thoughs with Pedro and Peter. I would like to echo Pedro's, Peter's and other's argument that it is unreasonable for Relying Parties and Browsers to say "I trust the CA (the Root Operator) to do the right thing and manage

Re: When to accept/require revised audits for missing cert fingerprints

For what it's worth, I think that there should be two distinct cases: a) Self-signed Certificates that have the same SPKI and name, but only one was ever requested to be included as a Trust Anchor in the Mozilla Root Program, b) Variations of Issuing CA Certificates that have the same SPKI

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

On 2019-10-22 7:28 μ.μ., Wayne Thayer wrote: The CA SHALL NOT delegate validation of the domain part of an e-mail address. This is https://github.com/mozilla/pkipolicy/commit/85ae5a1b37ca8e5138d56296963195c3c7dec85a Sounds good.

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

Jeremy, As I'm sure you know, there are several federated services, at least in the Education and Research area, where schemes like https://edugain.org/ are used. In that scenario, Identity Providers under a certain policy (https://technical.edugain.org/documents) provide signed assertions

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

quot;Subordinate CA Owner" operates/manages the CA keys. Dimitris. ---- *From:* dev-security-policy on behalf of Dimitris Zacharopoulos via dev-security-policy *Sent:* 04 October 2019 05:43 *To:* mozilla-dev-security-

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

Adding to Jeremy's post, I believe we need to also define a normative requirement to mark an unconstrained Intermediate CA Certificate not operated by the entity that controls the Root Key. Section 7.1.6.3 of the Baseline Requirements requires an explicit policy identifier for these subCAs. The

Re: DigiCert OCSP services returns 1 byte

On 2019-09-23 5:00 μ.μ., Ryan Sleevi via dev-security-policy wrote: No. That’s the more dangerous approach which I’ve tried repeatedly to dissuade. You should produce, and distribute, the Good response with the pre-certificate. Understood. Thank you for the clear guidance. Dimitris.

Re: DigiCert OCSP services returns 1 byte

On 2019-09-23 3:02 μ.μ., Ryan Sleevi wrote: On Mon, Sep 23, 2019 at 12:50 PM Dimitris Zacharopoulos mailto:ji...@it.auth.gr>> wrote: [...] Doesn't this break compatibility with older clients? It is older clients that need to see "revoked" which is equivalent to "not good"

Re: DigiCert OCSP services returns 1 byte

On 2019-09-23 1:37 μ.μ., Ryan Sleevi via dev-security-policy wrote: On Mon, Sep 23, 2019 at 9:31 AM Dimitris Zacharopoulos via dev-security-policy wrote: On 20/9/2019 11:00 μ.μ., Wayne Thayer wrote: On Fri, Sep 20, 2019 at 4:56 AM Dimitris Zacharopoulos mailto:ji...@it.auth.gr>>

Re: DigiCert OCSP services returns 1 byte

On 20/9/2019 11:00 μ.μ., Wayne Thayer wrote: On Fri, Sep 20, 2019 at 4:56 AM Dimitris Zacharopoulos mailto:ji...@it.auth.gr>> wrote: Using the following practice as described in RFC 6960 should not be a violation of the BRs. That is, answering revoked where a pre-certificate

Re: DigiCert OCSP services returns 1 byte

Dear Wayne, According to section 2.2 of RFC 6960, an OCSP responder may respond "revoked" for a "non-issued" Certificate. It even allows this response for "unknown" Certificates in order to support backwards compatibility with implementations of RFC 2560. In addition to that, section 4.4.8

Re: Policy 2.7 Proposal: Clarify Revocation Requirements for S/MIME Certificates

Dear Wayne, Please consider the fact that S/MIME is focused on "signature" Certificates which has different considerations than "authentication" Certificates. The baseline requirements (and their revocation requirements) are focused on "authentication" Certificates. I believe the revocation

Re: Policy 2.7 Proposal: Require EKUs in End-Entity Certificates

On 24/4/2019 10:18 π.μ., Matt Palmer via dev-security-policy wrote: On Wed, Apr 24, 2019 at 09:13:31AM +0300, Dimitris Zacharopoulos via dev-security-policy wrote: I support this update but I am not sure if this is somehow linked with the scope of the Mozilla Policy. Does this change mean

Re: Policy 2.7 Proposal: Require EKUs in End-Entity Certificates

On 24/4/2019 2:09 π.μ., Wayne Thayer via dev-security-policy wrote: On Fri, Apr 19, 2019 at 7:12 PM Matt Palmer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: On Fri, Apr 19, 2019 at 01:22:59PM -0700, Wayne Thayer via dev-security-policy wrote: Okay, then I propose

Re: Organization Identifier field in the Extended Validation certificates accordinf to the EVG ver. 1.6.9

I agree with Doug's interpretation. Dimitris. On 17/4/2019 9:23 μ.μ., Doug Beattie via dev-security-policy 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

Re: GRCA Incident: BR Compliance and Document Signing Certificates

On 25/3/2019 10:48 μ.μ., Wayne Thayer via dev-security-policy wrote: I agree with Ryan on this. From a policy perspective, we should be encouraging [and eventually requiring] EKU constraints, not making it easier to exclude them. I was merely copying parts of the existing policy related to

Re: GRCA Incident: BR Compliance and Document Signing Certificates

On 17/3/2019 1:54 π.μ., Matthew Hardeman via dev-security-policy wrote: While sending a message that non-compliance could result in policy change is generally a bad idea, I did notice something about the profile of the non-compliant certificate which gave me pause: None of the example

Re: EJBCA defaulting to 63 bit serial numbers

Dimitris Zacharopoulos via dev-security-policy <mailto:dev-security-policy@lists.mozilla.org>> wrote: I am personally shocked that a large part of this community considers that now is the time for CAs to demonstrate "agility to replace certificates", as light

Re: EJBCA defaulting to 63 bit serial numbers

Adding to this discussion, and to support that there were -in fact- different interpretations (all in good faith) please check the issue I had created in Dec 2017 https://github.com/awslabs/certlint/issues/56. My simple interpretation of the updated requirement in 7.1 at the time was that "no

Re: Odp.: Odp.: Odp.: 46 Certificates issued with BR violations (KIR)

+1. Of course there must be consistency between CRLs and OCSP. Dimitris. -Original Message- From: Eric Mill via dev-security-policy To: "Buschart, Rufus" Cc: mozilla-dev-security-policy , Kurt Roeckx , Wayne Thayer Sent: Sat, 02 Feb 2019 16:17 Subject: Re: Odp.: Odp.: Odp.: 46

Re: AW: AW: Incident Report DFN-PKI: Non-IDNA2003 encoded international domain names

I referred to your comment that "you perform a successful domain validation". My point, which you seem to understand and agree, is that there are additional rules than just DNS validation. Dimitris. On 24/1/2019 12:21 μ.μ., Buschart, Rufus wrote: Hello Dimitris, of course not, because the

Re: AW: Incident Report DFN-PKI: Non-IDNA2003 encoded international domain names

On 24/1/2019 10:47 π.μ., Buschart, Rufus via dev-security-policy wrote: Good morning! I would like to sharpen my argument from below a little bit: If a CA gets a request to issue a certificate for the domain xn--gau-7ka.siemens.de, how can the CA tell, that xn--gau-7ka is a punycode string in

Re: CA disclosure of revocations that exceed 5 days [Was: Re: Incident report D-TRUST: syntax error in one tls certificate]

On 5/12/2018 10:02 π.μ., Fotis Loukos wrote: On 4/12/18 8:29 μ.μ., Dimitris Zacharopoulos via dev-security-policy wrote: Fotis, You have quoted only one part of my message which doesn't capture the entire concept. I would appreciate it if you mentioned how exactly did I distort your proposal

Re: CA disclosure of revocations that exceed 5 days [Was: Re: Incident report D-TRUST: syntax error in one tls certificate]

Ryan Sleevi via dev-security-policy wrote: On Fri, Nov 30, 2018 at 4:24 AM Dimitris Zacharopoulos wrote: On 30/11/2018 1:49 π.μ., Ryan Sleevi wrote: On Thu, Nov 29, 2018 at 4:03 PM Dimitris Zacharopoulos via dev-security-policy wrote: I didn't want to hijack the thread so here's a new

Re: CA disclosure of revocations that exceed 5 days [Was: Re: Incident report D-TRUST: syntax error in one tls certificate]

On 30/11/2018 1:49 π.μ., Ryan Sleevi wrote: On Thu, Nov 29, 2018 at 4:03 PM Dimitris Zacharopoulos via dev-security-policy <mailto:dev-security-policy@lists.mozilla.org>> wrote: I didn't want to hijack the thread so here's a new one. Times and circumstances change.

CA disclosure of revocations that exceed 5 days [Was: Re: Incident report D-TRUST: syntax error in one tls certificate]

I didn't want to hijack the thread so here's a new one. On 29/11/2018 6:39 μ.μ., Ryan Sleevi wrote: On Thu, Nov 29, 2018 at 2:16 AM Dimitris Zacharopoulos mailto:ji...@it.auth.gr>> wrote: Mandating that CAs disclose revocation situations that exceed the 5-day requirement with

Re: Incident report D-TRUST: syntax error in one tls certificate

On 29/11/2018 12:14 π.μ., Wayne Thayer via dev-security-policy wrote: The way that we currently handle these types of issues is about as good as we're going to get. We have a [recently relaxed but still] fairly stringent set of rules around revocation in the BRs. This is necessary and proper

Re: Clarifications on ETSI terminology and scheme

On 31/10/2018 8:00 μμ, Ryan Sleevi via dev-security-policy wrote: [...] Dimitris, I'm sorry, but I don't believe this is a correct correction. EN 319 403 incorporates ISO/IEC 17065; much like the discussion about EN 319 411-2 incorporating, but being separate from, EN 319 411-1, the

Clarifications on ETSI terminology and scheme

On 31/10/2018 4:47 μμ, Ryan Sleevi via dev-security-policy wrote: There's a lot of nitpicking in this, and I feel that if you want to continue this discussion, it would be better off in a separate thread on terminology. I disagree with some of the claims you've made, so have corrected them for

Re: Questions regarding the qualifications and competency of TUVIT

On 30/10/2018 6:28 μμ, Ryan Sleevi via dev-security-policy wrote: This establishes who the CAB is and who the NAB is. As the scheme used in eIDAS for CABs is ETSI EN 319 403, the CAB must perform their assessments in concordance with this scheme, and the NAB is tasked with assessing their

Re: Concerns with Dun & Bradstreet as a QIIS

On 2/10/2018 5:21 μμ, Ryan Sleevi via dev-security-policy wrote: On Tue, Oct 2, 2018 at 10:02 AM Dimitris Zacharopoulos wrote: But this inaccurate data is not used in the validation process nor included in the certificates. Perhaps I didn't describe my thoughts accurately. Let me have

Re: Concerns with Dun & Bradstreet as a QIIS

On 1/10/2018 8:15 μμ, Ryan Sleevi via dev-security-policy wrote: On Mon, Oct 1, 2018 at 9:21 AM Dimitris Zacharopoulos wrote: [...] I am certainly not suggesting that CAs should put inaccurate and misleading information in certificates :-) I merely said that if the Subscriber introduces

Re: Concerns with Dun & Bradstreet as a QIIS

On 1/10/2018 1:06 μμ, Ryan Sleevi via dev-security-policy wrote: On Mon, Oct 1, 2018 at 2:55 AM Dimitris Zacharopoulos wrote: Perhaps I am confusing different past discussions. If I recall correctly, in previous discussions we described the case where an attacker tries to get a certificate

Re: Concerns with Dun & Bradstreet as a QIIS

On 28/9/2018 9:59 μμ, Ian Carroll via dev-security-policy wrote: On Thursday, September 27, 2018 at 10:22:05 PM UTC-7, Dimitris Zacharopoulos wrote: Forgive my ignorance, but could you please explain what was your ultimate goal, as "an attacker", what were you hoping to gain and how could you

Re: Concerns with Dun & Bradstreet as a QIIS

On 28/9/2018 8:04 μμ, Ryan Sleevi via dev-security-policy wrote: On Fri, Sep 28, 2018 at 1:22 AM Dimitris Zacharopoulos via dev-security-policy wrote: Forgive my ignorance, but could you please explain what was your ultimate goal, as "an attacker", what were you hoping to gain and

Re: Concerns with Dun & Bradstreet as a QIIS

Forgive my ignorance, but could you please explain what was your ultimate goal, as "an attacker", what were you hoping to gain and how could you use this against Relying Parties? I read your email several times but I could not easily find a case where your fake address creates any serious

Re: Telia CA - problem in E validation

Dear Pekka, "verified by the CA" seems to be the weak point here. What does "verified by the CA" mean? The community seems to interpret this as actions by the CA to verify that the information requested to be included in the certificate by the Applicant, is actually real and

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

On 15/5/2018 6:51 μμ, Wayne Thayer via dev-security-policy wrote: Did you consider any changes based on Jakob’s comments? If the PKCS#12 is distributed via secure channels, how strong does the password need to be? I think this depends on our threat model, which to be fair is not

RE: Policy 2.6 Proposal: Update Minimum Audit Versions

Thanks Peter, I think we are in agreement. Dimitris. -Original Message- From: "Peter Miškovič via dev-security-policy" To: Dimitris Zacharopoulos , Wayne Thayer , mozilla-dev-security-policy

Re: Policy 2.6 Proposal: Update Minimum Audit Versions

Hello Peter, These were very recently published however not everyone is tracking down ETSI updates by registering to the mailing lists. The main question is where can you find the authoritative document *list*? I though the official list is

Re: Policy 2.6 Proposal: Update Minimum Audit Versions

Dimitris. On 10/5/2018 11:24 μμ, Dimitris Zacharopoulos via dev-security-policy wrote: For ETSI EN 319 411-1, it seems that v1.1.1 is still listed as the official version. The list of ESI activities is https://portal.etsi.org//TBSiteMap/ESI/ESIActivities.aspx. There is an update for v

Re: Policy 2.6 Proposal: Update Minimum Audit Versions

For ETSI EN 319 411-1, it seems that v1.1.1 is still listed as the official version. The list of ESI activities is https://portal.etsi.org//TBSiteMap/ESI/ESIActivities.aspx. There is an update for version 1.2.1 that is "on vote until 23 April". Perhaps there is a more official page for

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

As I was reading this very interesting thread, I kept asking myself "what are we trying to protect". Are we trying to protect a "Private Key" or a "PKCS#12" file? I suppose the consensus of the community, based mainly on compatibility issues, is that we can't avoid the solution of a PKCS#12

Re: Policy 2.6 Proposal: Require CAs to support problem reports via email

On 18/4/2018 9:50 μμ, Wayne Thayer via dev-security-policy wrote: On Wed, Apr 18, 2018 at 12:14 AM, Dimitris Zacharopoulos via dev-security-policy <dev-security-policy@lists.mozilla.org> wrote: On 18/4/2018 12:04 πμ, Jeremy Rowley via dev-security-policy wrote: Having to go t

Re: Policy 2.6 Proposal: Require CAs to support problem reports via email

On 18/4/2018 12:04 πμ, Jeremy Rowley via dev-security-policy wrote: Having to go through captchas to even get the email sent is just another obstacle in getting the CA a timely certificate problem report Nowadays, people deal with captchas all the time in various popular web sites. I don't

Re: Policy 2.6 Proposal: Require separate intermediates for different usages (e.g. server auth, S/MIME)

On 17/4/2018 9:24 μμ, Wayne Thayer via dev-security-policy wrote: This proposal is to require intermediate certificates to be dedicated to specific purposes by EKU. Beginning at some future date, all newly created intermediate certificates containing either the id-kp-serverAuth or

Re: Policy 2.6 Proposal: Audit requirements for new subCA certificates

On 5/4/2018 9:00 μμ, Ryan Sleevi via dev-security-policy wrote: On Thu, Apr 5, 2018 at 5:20 AM, Dimitris Zacharopoulos via dev-security-policy <dev-security-policy@lists.mozilla.org> wrote: On 5/4/2018 12:02 πμ, Wayne Thayer via dev-security-policy wrote: In a recent discussion

Re: FW: Complying with Mozilla policy on email validation

On 5/4/2018 3:08 πμ, Wayne Thayer via dev-security-policy wrote: I think the existing language in section 2.2(2) also supports the federated authentication system use case you described. It says that the CA "takes reasonable measures to verify that the entity submitting the request controls the

Re: TURKTRUST Non-compliance

On 23/3/2018 9:44 μμ, Wayne Thayer via dev-security-policy wrote: > Therefore, the only action I plan to take on this is > to ask the WebTrust Task Force for their opinion on "wind-down" audits, and > also to ask them if it is possible for a CA to obtain a period-of-time > audit for a hierarchy

Re: Allowing WebExtensions to Override Certificate Trust Decisions

On 28/2/2018 1:52 πμ, Ryan Sleevi via dev-security-policy wrote: On Tue, Feb 27, 2018 at 6:15 PM, Wayne Thayer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: In the bug I referenced as [2], people said that they specifically need to be able to override "negative"

Re: Taiwan GRCA Root Renewal Request

On 26/1/2018 11:54 μμ, Ryan Sleevi via dev-security-policy wrote: > Has any consideration been given to adopt a similar policy as discussed > with the Government of Korea application - > https://bugzilla.mozilla.org/show_bug.cgi?id=1226100#c38 Just to avoid any possible mis-reading of: "If

Re: ETSI Audits Almost Always FAIL to list audit period

This is a long thread but the topic is very critical so I hope people are patient enough to read through this long discussion. On 1/11/2017 12:37 πμ, Ryan Sleevi wrote: On Tue, Oct 31, 2017 at 5:29 PM, Dimitris Zacharopoulos via dev-security-policy <dev-security-policy@lists.mozilla.

Re: ETSI Audits Almost Always FAIL to list audit period

On 31/10/2017 11:21 πμ, Dimitris Zacharopoulos via dev-security-policy wrote: It is not the first time this issue is brought up. While I have a very firm opinion that ETSI auditors under the ISO 17065 (focused on the quality of products/services) and ETSI EN 319 403 definitely check

Re: ETSI Audits Almost Always FAIL to list audit period

On 31/10/2017 1:37 μμ, Ryan Sleevi via dev-security-policy wrote: On Tue, Oct 31, 2017 at 5:21 AM Dimitris Zacharopoulos via dev-security-policy <dev-security-policy@lists.mozilla.org> wrote: It is not the first time this issue is brought up. While I have a very firm opinion that ETSI au

Re: Regarding CA requirements as to technical infrastructure utilized in automated domain validations, etc. (if any)

On 25/8/2017 9:42 μμ, Ryan Hurst via dev-security-policy wrote: Dimitris, I think it is not accurate to characterize this as being outside of the CAs controls. Several CAs utilize multiple network perspectives and consensus to mitigate these risks. While this is not a total solution it is

Re: Regarding CA requirements as to technical infrastructure utilized in automated domain validations, etc. (if any)

On 26/7/2017 3:38 πμ, Matthew Hardeman via dev-security-policy wrote: On Tuesday, July 25, 2017 at 1:00:39 PM UTC-5,birg...@princeton.edu wrote: We have been considering research in this direction. PEERING controls several ASNs and may let us use them more liberally with some convincing. We

Re: Policy 2.5 Proposal: Fix definition of constraints for id-kp-emailProtection

On 19/5/2017 6:04 μμ, Jakob Bohm via dev-security-policy wrote: On 19/05/2017 16:15, Gervase Markham wrote: On 19/05/17 14:58, Jakob Bohm wrote: Because the O and other dirname attributes may be shown in an e-mail client (current or future) as a stronger identity than the technical e-mail

Re: Policy 2.5 Proposal: Fix definition of constraints for id-kp-emailProtection

On 8/5/2017 1:18 μμ, Gervase Markham wrote: On 05/05/17 19:44, Dimitris Zacharopoulos wrote: * MUST include an EKU that has the id-kp-emailProtection value AND * MUST include a nameConstraints extension with o a permittedSubtrees with + rfc822Name entries scoped in the

Re: Policy 2.5 Proposal: Fix definition of constraints for id-kp-emailProtection

On 6/5/2017 1:19 πμ, Peter Bowen via dev-security-policy wrote: One other question: Does your proposal allow a TCSC that covers both ServerAuth and EmailProtection for the domains of the same organization? Or put another way, would your proposed language force an organization wanting to run

Re: Policy 2.5 Proposal: Fix definition of constraints for id-kp-emailProtection

On 5/5/2017 10:58 μμ, Peter Bowen wrote: On Fri, May 5, 2017 at 11:58 AM, Dimitris Zacharopoulos via dev-security-policy <dev-security-policy@lists.mozilla.org> wrote: On 5/5/2017 9:49 μμ, Peter Bowen via dev-security-policy wrote: On Fri, May 5, 2017 at 11:44 AM, Dimitris Zacharopoul

Re: Policy 2.5 Proposal: Fix definition of constraints for id-kp-emailProtection

On 5/5/2017 9:49 μμ, Peter Bowen via dev-security-policy wrote: On Fri, May 5, 2017 at 11:44 AM, Dimitris Zacharopoulos via dev-security-policy <dev-security-policy@lists.mozilla.org> wrote: Looking at https://github.com/mozilla/pkipolicy/issues/69 do you have a proposed language that

Re: Policy 2.5 Proposal: Fix definition of constraints for id-kp-emailProtection

Looking at https://github.com/mozilla/pkipolicy/issues/69 do you have a proposed language that takes all comments into account? From what I understand, the Subordinate CA Certificate to be considered Technically Constrained only for S/MIME: * MUST include an EKU that has the