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 wh

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 th

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 our

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

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

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 sho

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 m

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

ore On Mon, 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

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 discuss

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

ups.google.com/g/mozilla.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&#x

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 dev-security-policy@

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 is p

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

rafting a PR here: 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.

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 6-Oc

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 under

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 con

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 "leade

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 th

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 an

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. This

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 tha

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

ing that the "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-d

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 eq

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-certi

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 l

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 a

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 permits

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 "P

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 certific

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 Cert

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

land Busch, Lisa Davis, Klaus Helmrich, Janina Kugel, Cedrik Neike, Michael Sen, Ralf P. Thomas; Registered offices: Berlin and Munich, Germany; Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322 -Ursprüngliche Nachricht- Von: Dimitris Zac

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 pro

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

on some risk analysis? Regards, Fotis On 30/11/18 6:13 μ.μ., 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-polic

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 ch

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

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 be

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

As pointed out by one of my engineers, there is a simpler way by doing a simple direct query [1] in the read-only database of crt.sh. Using Rufus' example: SELECT get_ca_name_attribute(issuer_ca_id, 'organizationName') issuer_o, ISSUER_CA_ID, FATAL_CERTS, ERROR_CERTS, WARNING_CERTS FROM lint

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 structure

Clarifications on ETSI terminology and scheme

answers in-line. On Wed, Oct 31, 2018 at 7:11 AM Dimitris Zacharopoulos wrote: 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 assessme

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 qualifi

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

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

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 co

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 owned/controlled

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 something

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 Sent: Fri, 11 May 2018 12:53 Subject: RE: Policy 2.6 Proposal: Update Min

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 https://portal.etsi.org/TBSiteMap/ESI/TrustServicePr

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 versio

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 these

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 f

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 wrote: 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

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 un

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 id-kp-emailPr

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 wrote: On 5/4/2018 12:02 πμ, Wayne Thayer via dev-security-policy wrote: In a recent discussion [1] we decided to clarify the audit requirements

Re: Policy 2.6 Proposal: Add prohibition on CA key generation to policy

On 5/4/2018 12:26 πμ, Wayne Thayer via dev-security-policy wrote: CAs MUST not distribute or transfer certificates in PKCS#12 form through insecure electronic channels. If a PKCS#12 file is distributed via a physical data storage device, then: * The storage must be packaged in a way that the ope

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

On 5/4/2018 12:02 πμ, Wayne Thayer via dev-security-policy wrote: In a recent discussion [1] we decided to clarify the audit requirements for new subordinate CA certificates. I’ve drafted a change that requires the new certificate to appear in the next periodic audits and in the CP/CPS prior to

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 t

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" certif

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 you

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 <mailto:dev-security-pol

Re: ETSI Audits Almost Always FAIL to list audit period

On 31/10/2017 8:12 μμ, Kathleen Wilson via dev-security-policy wrote: Thank you, Dimitris, for sharing input from your auditor. This is a very educating discussion that probably should have taken place earlier, in order to get people's attention and bring some clarity in the various proces

Re: ETSI Audits Almost Always FAIL to list audit period

On 31/10/2017 3:14 μμ, Ryan Sleevi via dev-security-policy wrote: On Tue, Oct 31, 2017 at 8:34 AM, Dimitris Zacharopoulos via dev-security-policy wrote: [...] I think you are looking at this from the opposite side. Auditors have their own scheme to follow which is governed under ISO

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 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

Re: ETSI audits not listing audit periods

On 31/10/2017 11:12 πμ, Arno Fiedler via dev-security-policy wrote: Am Montag, 30. Oktober 2017 22:19:31 UTC+1 schrieb Ryan Sleevi: On Mon, Oct 30, 2017 at 3:50 PM, Kathleen Wilson via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: How do we get all auditors to start meetin

Re: ETSI Audits Almost Always FAIL to list audit period

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 historical data to assess the level of conformance, I will communicate this to our audi

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 fair

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 al

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 add

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 unde

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 wrote: 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 wrote: Looking

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 wrote: Looking at https://github.com/mozilla/pkipolicy/issues/69 do you have a proposed language that takes all comments into account? From what I

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 id-kp-emailProt

Re: ENISA Draft technical guidelines on eIDAS implementation

On 4/11/2016 1:39 μμ, Dimitris Zacharopoulos wrote: For those wishing to contribute with comments/feedback, ENISA has updated Draft Guidelines for TSPs implementing eIDAS. https://www.enisa.europa.eu/topics/trust-services/guidelines/ Thank you, Dimitris Zacharopoulos

Re: Criticism of Google Re: Google Trust Services roots

On 30/3/2017 4:01 μμ, Peter Kurrasch via dev-security-policy wrote: By "not new", are you referring to Google being the second(?) instance where a company has purchased an individual root cert from another company? It's fair enough to say that Google isn't the first but I'm not aware of any com

Re: Question about Baseline Requirements section #7.1.4.2

On 25/1/2017 1:40 μμ, Dimitris Zacharopoulos wrote: On 25/1/2017 1:25 μμ, Gervase Markham wrote: On 24/01/17 06:50, Dimitris Zacharopoulos wrote: The CA/B Forum Policy Review WG made some effort <https://cabforum.org/pipermail/policyreview/2016-April/000272.html> to clarify this by m

Re: Question about Baseline Requirements section #7.1.4.2

On 25/1/2017 1:40 μμ, Dimitris Zacharopoulos wrote: On 25/1/2017 1:25 μμ, Gervase Markham wrote: On 24/01/17 06:50, Dimitris Zacharopoulos wrote: The CA/B Forum Policy Review WG made some effort <https://cabforum.org/pipermail/policyreview/2016-April/000272.html> to clarify this by m

Re: Question about Baseline Requirements section #7.1.4.2

On 25/1/2017 1:25 μμ, Gervase Markham wrote: On 24/01/17 06:50, Dimitris Zacharopoulos wrote: The CA/B Forum Policy Review WG made some effort <https://cabforum.org/pipermail/policyreview/2016-April/000272.html> to clarify this by merging information between these sections, but there w

Re: Question about Baseline Requirements section #7.1.4.2

On 24/1/2017 2:01 πμ, Peter Bowen wrote: On Mon, Jan 23, 2017 at 3:32 PM, Kathleen Wilson wrote: Does section 7.1.4.2 of the CA/Browser Forum's Baseline Requirements only apply to end-entity certificates? If yes, where does it specify that in the document? This has come up in a few CA reques

Re: UI Improvement in Certificate details

mit a patch to is https://dxr.mozilla.org/mozilla-central/source/security/manager/ssl/nsNSSCertHelper.cpp#242 On Tue, Nov 15, 2016 at 11:54 PM, Dimitris Zacharopoulos wrote: Li-Chun CHEN from Chunghwa Telecom would like to push for a UI improvement to properly display subject information in certif

UI Improvement in Certificate details

familiar with the structure). Any help would be appreciated. Thank you, Dimitris Zacharopoulos. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy

Re: Proposal to define applicability of BRs and expectations of CAs

(something weird happened in the reply all. Re-sending). On 11/11/2016 3:45 μμ, Gervase Markham wrote: On 11/11/16 13:26, Dimitris Zacharopoulos wrote: Although this is very helpful so that people can better understand the CA/B Forum's expectations and BR scope by introducing fresh lan

Re: Proposal to define applicability of BRs and expectations of CAs

On 11/11/2016 3:42 πμ, Peter Bowen wrote: Given that there is a lack of clarity on when the CABF BRs apply, and that applicability of the BRs is outside the scope of the BRs, I propose the following text to clarify and help CAs understand the expectations of operating a publicly trusted CA. Than

Re: Update on transition of the Verizon roots and issuance of SHA1 certificates

This looks like a very accurate representation of the data protection European regulations. I have the same view. Not so easy to implement but if it is implemented correctly, I think very few people will disagree with the essence of this regulation. Dimitris. -- Sent from my mobile device.

ENISA Draft technical guidelines on eIDAS implementation

For those wishing to contribute with comments/feedback, ENISA has updated Draft Guidelines for TSPs implementing eIDAS. https://www.enisa.europa.eu/topics/trust-services/guidelines/ Thank you, Dimitris Zacharopoulos. ___ dev-security-policy mailing

  1   2   >