Re: Misissued/Suspicious Symantec Certificates

Hi Steve, Two more question to add to the list which is already pending: In [1], in response to question 5, Symantec indicated that Certisign was a WebTrust audited partner RA, with [2] provided as evidence to this fact. While we discussed the concerns with respect to the audit letter,

Re: Misissued/Suspicious Symantec Certificates

On Fri, Feb 17, 2017 at 5:17 PM, urijah--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Friday, February 17, 2017 at 7:50:31 PM UTC-5, uri...@gmail.com wrote: > > On Friday, February 17, 2017 at 7:23:54 PM UTC-5, Ryan Sleevi wrote: > > > I have confirmed with CPA >

Re: SHA-1 collision

On Thu, Feb 23, 2017 at 5:16 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > For example, in a certificate request, while the attacker can "choose" > such a bunch of bits in the public key, the value also has to be a valid > public key for which the

Re: Misissued/Suspicious Symantec Certificates

On Wed, Feb 22, 2017 at 8:32 PM, Ryan Sleevi wrote: > Hi Steve, > > Thanks for your continued attention to this matter. Your responses open > many new and important questions and which give serious question as to > whether the proposed remediations are sufficient. To keep this

Re: Let's Encrypt appears to issue a certificate for a domain that doesn't exist

There is no definition or requirement for what a high risk domain is. That's the point/problem. WoSign may determine "apple", "google", "microsoft", and "github" as High Risk. Amazon may determine certificates issued on the first of the month are more likely to be High Risk (because it may be

Re: Misissued/Suspicious Symantec Certificates

Hi Steve, Thanks for your continued attention to this matter. Your responses open many new and important questions and which give serious question as to whether the proposed remediations are sufficient. To keep this short, and thereby allow Symantec a more rapid response: 1) Please provide the

Re: Let's Encrypt appears to issue a certificate for a domain that doesn't exist

Hi Richard, There's no policies in the Baseline Requirements or Mozilla Requirements that normalize or define high risk domain, which I believe your suggestion presupposes. Perhaps you (or Qihoo 360, as the voting member of the Forum of the Qihoo/WoSign/StartCom collection) would consider

Re: Let's Encrypt appears to issue a certificate for a domain that doesn't exist

Hi Richard, My point was that policy requirement simply states that there needs to be a procedure, but does not establish any normative requirements. For example, a CA could develop, maintain, and implement procedures which states that any certificate that is qualified as High Risk requires Gerv

Re: Misissued/Suspicious Symantec Certificates

On Wed, Feb 22, 2017 at 8:36 PM, Jeremy Rowley wrote: > Webtrust doesn't have audit criteria for RAs so the audit request may > produce interesting results. Or are you asking for the audit statement > covering the root that the RA used to issue from? That should all

Re: Intermediates Supporting Many EE Certs

On Tue, Feb 14, 2017 at 5:47 AM, Steve Medin via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > - The caching I’m talking about is not header directives, I mean > how CAPI and NSS retain discovered path for the life of the intermediate. > One fetch, per person,

Re: Intermediates Supporting Many EE Certs

On Mon, Feb 13, 2017 at 11:56 AM, Steve Medin via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Patrick, thanks, it appears my attempt at brevity produced density. > > - No amount of mantra, training, email notification, blinking text and > certificate installation

Re: Misissued/Suspicious Symantec Certificates

On Mon, Feb 13, 2017 at 4:48 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Hi Steve, > > On 12/02/17 15:27, Steve Medin wrote: > > A response is now available in Bugzilla 1334377 and directly at: > >

Re: Google Trust Services roots

On Fri, Feb 10, 2017 at 8:00 AM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > I am trying to say that I use the word "issue" as the weakest category, > orders of magnitude less serious than an absolute cause for rejection. And I'm trying to suggest that

Re: Google Trust Services roots

On Thu, Feb 9, 2017 at 3:39 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > Additional issue #2: The information at https://pki.goog/ about how to > report misissuance directs visitors to a generic reporting page for > code vulnerabilities, which (by

Re: Intermediates Supporting Many EE Certs

On Tue, Feb 14, 2017 at 10:13 AM, Steve Medin via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > I mention P7 because IIS inhales them in one click and ensures that the > intermediate gets installed. Yes, but that's not because of PKCS#7, as I tried to explain and

Re: Google Trust Services roots

On Thu, Feb 9, 2017 at 11:40 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > For clarity, I was pointing out that GTS seems to have chosen a method > likely to fail if an when actually needed, due to the typical dynamics > of large human organizations.

Re: Misissued/Suspicious Symantec Certificates

On Fri, Feb 24, 2017 at 4:51 PM, Ryan Sleevi wrote: > > > On Wed, Feb 22, 2017 at 8:32 PM, Ryan Sleevi wrote: > >> Hi Steve, >> >> Thanks for your continued attention to this matter. Your responses open >> many new and important questions and which give serious

Re: GlobalSign BR violation

On Tue, Feb 28, 2017 at 8:53 AM, douglas.beattie--- via dev-security-policy wrote: > > Yes, we're working to do just this now. While that's good and well, I do hope GlobalSign will produce an incident report regarding this matter, as to how the situation

Re: GlobalSign BR violation

On Tue, Feb 28, 2017 at 12:02 PM, douglas.beattie--- via dev-security-policy wrote: > Ryan, > > GlobalSign certificate issuance has been referenced in several different > threads recently and I think most of them are closed; however, if you feel >

Re: (Possible) DigiCert EV Violation

On Mon, Feb 27, 2017 at 2:19 PM, Jeremy Rowley via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > The requirements don't specify what to do with this information. I know > our product team interpreted this as part of the validation methods and > exchange of key information,

(Possible) DigiCert EV Violation

The EV Guidelines require certificates issued for .onion include the cabf-TorServiceDescriptor extension, defined in the EV Guidelines, as part of these certificates. This is required by Section 11.7.1 (1) of the EV Guidelines, reading: "For a Certificate issued to a Domain Name with .onion in

Re: Notice of Intent to Deprecate and Remove: Trust in Symantec-issued Certificates

(Posting in an official capacity) Jakob, As the initial message said: "You can participate in this discussion at https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/eUAKwjihhBs " I've removed the cross-post, to ensure that threads do not fork due to members being subscribed to one

Re: Symantec: Next Steps

(Wearing an individual hat) On Fri, Mar 24, 2017 at 10:35 AM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > One common scenario that a new wording should allow is a "fully > outsourced CA", where all the technical activities, including CA > private key

Re: Symantec: Next Steps

On Fri, Mar 24, 2017 at 1:30 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Examples discussed in the past year in this group include the Taiwan > GRCA roots and several of the SubCAs hosted by Verizon prior to the > DigiCert transition. Apologies for

Re: Next CA Communication

On Tue, Mar 28, 2017 at 10:00 AM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > In principle any source of information could change just one minute > later. A domain could be sold, a company could declare bankruptcy, a > personal domain owner could die. >

Re: EKU in Google sub CAs in violation of RFC5280?

On Mon, Mar 27, 2017 at 9:45 AM, tpg0007--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On https://pki.goog, all 5 of Google's newer subCAs have Extended Key > Usage extension of serverAuth and clientAuth, unusual for CAs but not > forbidden I guess. Their Key Usage

Re: Notice of Intent to Deprecate and Remove: Trust in Symantec-issued Certificates

On Thu, Mar 23, 2017 at 12:54 PM, tarah.symantec--- via dev-security-policy wrote: > What will be the process for critical infrastructure such as medical > devices and payment systems when they're affected by this? To avoid fragmentation of discussion,

Re: Google Trust Services roots

On Thu, Mar 23, 2017 at 8:37 AM, Peter Kurrasch via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > ‎I would be interested in knowing why Google felt it necessary to purchase > an existing root instead of, for example, pursuing a "new root" path along > the lines of what

Notice of Intent to Deprecate and Remove: Trust in Symantec-issued Certificates

(Posting in a Google Capacity) I just wanted to notify the members of this Forum that we have started an Intent to Deprecate and Remove, consistent with our Blink process, related to certain certificates issued by Symantec Corporation. This is a proposed plan, not a final commitment, and we

Re: Over 14K 'Let's Encrypt' SSL Certificates Issued To PayPal Phishing Sites

On Wed, Mar 29, 2017 at 7:30 AM, Hector Martin via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > We actually have *five* levels of trust here: > > 1. HTTP > 2. HTTPS with no validation (self-signed or anonymous ciphersuite) > 3. HTTPS with DV > 4. HTTPS with OV > 5. HTTPS

Re: Researcher Says API Flaw Exposed Symantec Certificates, Including Private Keys

https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.4.2.pdf Section 6.1.2 On Wed, Mar 29, 2017 at 3:22 AM, okaphone.elektronika--- via dev-security-policy wrote: > Weird. > > I expect there are no requirements for a CA to keep other people's

Re: Question: Transfering the private key of an EV-approved CA

On Mon, Mar 27, 2017 at 3:09 PM, Kai Engert via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Are there existing rules, in the CABForum BRs, or in the Mozilla CA > policy, that > define under which circumstances the private key of an actively used EV > approved > root CA

Re: Google Trust Services roots

Clarified on the new thread you started, but I don't believe there's any inconsistency. Further details on the new thread you started. On Mon, Mar 27, 2017 at 10:02 AM, Roland Fantasia via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Anyone care to comment on the fact

Re: Next CA Communication

Gerv, I'm curious whether you would consider 18 months an appropriate target for a deprecation to 1 year certificates. That is, do you believe a transition to 1 year certificates requires 24 months or 18 months, or was it chosen simply for its appeal as a staggered number (1 year -> 2 year certs,

Re: Next CA Communication

On Mon, Mar 27, 2017 at 10:18 AM, Ryan Sleevi wrote: > Gerv, > > I'm curious whether you would consider 18 months an appropriate target for > a deprecation to 1 year certificates. That is, do you believe a transition > to 1 year certificates requires 24 months or 18 months, or

Re: Notice of Intent to Deprecate and Remove: Trust in Symantec-issued Certificates

On Thu, Mar 23, 2017 at 1:38 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 23/03/2017 17:09, Ryan Sleevi wrote: > >> (Posting in a Google Capacity) >> >> I just wanted to notify the members of this Forum that we have started an >> Intent to Deprecate

Re: Symantec: Next Steps

On Thu, Mar 16, 2017 at 6:01 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 09/03/17 13:32, Ryan Sleevi wrote: > > (Wearing Google hat only for this statement) > > Have you considered having this discussion in the CA/Browser Forum? > Google > >

Re: Symantec: Next Steps

On Fri, Mar 17, 2017 at 5:33 AM Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 16/03/17 13:15, Ryan Sleevi wrote: > > Or, put differently, it sounds as if you suggest the only obligation a CA > > has to ensure their DTP auditors are qualified for the

Re: Include Renewed Kamu SM root certificate

On Tue, Mar 14, 2017 at 5:10 PM, tugba onder via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Upon your request, we re-examined the current version of CAB BR (v.1.4.2) > with our CPS document that describes our way of doing business. We did this > work under these main

Re: Grace Period for Sub-CA Disclosure

On Mon, Apr 3, 2017 at 11:18 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 04/04/2017 05:03, Ryan Sleevi wrote: > >> On Mon, Apr 3, 2017 at 7:18 PM, Jakob Bohm via dev-security-policy < >> dev-security-policy@lists.mozilla.org> wrote: >> >> I see it

Re: Grace Period for Sub-CA Disclosure

On Mon, Apr 3, 2017 at 7:18 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > I see it as part of the underlying reasoning. Mozilla et al wants > disclosure in order to take action if the disclosed facts are deemed > unacceptable (under policy or

Re: Symantec Response D

On Mon, Apr 10, 2017 at 10:55 AM, Steve Medin via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Issue D: Test Certificate Misissuance (April 2009 - September 2015) > > Symantec has provided complete investigation results for this issue. They > can be found at

Re: Symantec Response P

Hi Steve, Quick questions: 1) Why was Symantec unable to operate the CRL service for Unicredit? 2) Pursuant to Section 5.7.1 of the Baseline Requirements, Symantec, and all of its sub-CAs, are required to document business continuity and disaster recovery procedures. Had Unicredit been operating

Re: Symantec Response J

Hi Steve, Quick question: 1) You identified that the root cause was related to a deprecated, but not removed, interface. Your remediation was to remove that interface. a) How many deprecated, but unremoved, interfaces does Symantec have, as of 2017-04-10?

Re: Symantec Response B

Hi Steve, Some quick follow-ups: 1) You're arguing that "the issuance of this cert didn't impose risk on anyone but this specific customer" a) What factors lead you to that decision? b) What process does Symantec have in place to make such determination? c) Does such process continue to

Re: Symantec Response E

Hi Steve, Quick questions: 1) To confirm, your response states nothing about any improved procedures or testing put into place regarding this. a) Can you describe what, if anything, Symantec did, beside "fix the bug"? b) What assurances should the community have regarding Symantec's

Re: Symantec Response L

Hi Steve, Quick questions: 1) You identified that Symantec believed that it was a responsibility to ensure your customers' businesses remain interrupted. a) What is Symantec's process for determining which of these concerns (Baseline Requirements vs customer business) has priority? b) Has

Re: Symantec Response Q

Hi Steve, Quick questions: 1) What does Symantec believe is a reasonable timeframe to remedy these issues? 2) You stated 18 months, but the issues were present from the 2013/2014 audits, the 2014/2015 audits, and the 2015/2016 audits, all as noted in Issue V. In total, this period spans 30

Re: Symantec Response F

Hi Steve, Quick follow-up. 1) Your audit reports failed to identify what steps Symantec was taking to proactively resolve these issues. As further demonstrated by Issue Q, Symantec failed to remedy these issues. a) What steps, if any, did Symantec take upon receiving a qualified audit? b)

Re: Symantec Response N

Hi Steve, Quick questions: 1) What steps, specifically, has Symantec taken to ensure such clarity is provided in the future? 2) What steps, specifically, has Symantec taken to ensure appropriate review prior to the execution of such processes? These questions apply to any process involving CA

Re: Symantec Response B

On Tue, Apr 11, 2017 at 6:02 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Hi Ryan, > > On 10/04/17 16:38, Ryan Sleevi wrote: > > 1) You're arguing that "the issuance of this cert didn't impose risk on > > anyone but this specific customer" > > a)

Re: Symantec Response L

On Tue, Apr 11, 2017 at 6:31 AM, Gervase Markham wrote: > Hi Ryan, > > On 10/04/17 17:03, Ryan Sleevi wrote: > > 2) You stated that "browsers didn't process certificate policy extensions > > content during path building". This fails to clarify whether you believe > it > > was a

Re: Symantec Response X

On Tue, Apr 11, 2017 at 6:21 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Hi Ryan, > > On 10/04/17 17:20, Ryan Sleevi wrote: > > 1) You stated that this partner program applies to non-TLS certificates. > > The audit for both STN and for the RAs

Re: Symantec Response T

On Tue, Apr 11, 2017 at 12:42 PM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > In various rounds of questioning at the time we were focussing purely on > this incident, I asked Symantec what processes they had in place for > checking that the RAs were

Re: Symantec Issues doc updated

On Tue, Apr 11, 2017 at 6:49 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > I have attempted to integrate the information provided by Symantec into: > https://wiki.mozilla.org/CA:Symantec_Issues > and started to draw some conclusions where that is

Re: Symantec Response T

On Mon, Apr 10, 2017 at 10:57 AM, Steve Medin via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Issue T: RA Program Misissuances (January 2010 - January 2017) > > Program Background: > > Symantec has operated an RA program designed to deliver a superior > customer

Re: Symantec Response V

> > > Hi Steve, Some follow-up questions: 1) Symantec stated "This information was in their management assertions, and repeated in the audit findings. So the poor audit situation was ongoing and known." a) Symantec did not meaningfully provide any explanation, now, or in the past, as to why it

Re: Symantec Response B

On Tue, Apr 11, 2017 at 11:44 AM, Kurt Roeckx via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > The reply indicated that it was a non-browser application. So I understand > that a browser should never see that certificate. > There's no way to objectively quantify or

Re: Symantec Response X

On Tue, Apr 11, 2017 at 12:33 PM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > E-Sign's CPS URL is given in its audit statement as: > https://www.e-sign.cl/uploads/cps_esign_388.pdf > > Grepping that document for "TLS" gives no hits. Can you help me

Re: Symantec Issues doc updated

On Tue, Apr 11, 2017 at 12:53 PM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > "to specifically address the > > GeoRoot audit status and remediation plan" - this was not reflected > within > > https://www.symantec.com/content/en/us/about/media/ >

Re: Grace Period for Sub-CA Disclosure

On Mon, Apr 3, 2017 at 12:58 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > taking a holiday and not being able to process a disclosure of a new > SubCA. > Considering that the CCADB does not require any of these parties to process a disclosure, can you

Re: Symantec Issues List

On Mon, Apr 3, 2017 at 12:46 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > How about this simple explanation (purely a guess, not at all checked): > I think we should focus on objective facts and statements. While there are a number of possible ways to

Re: Symantec Issues List

On Fri, Mar 31, 2017 at 2:39 PM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > As we continue to consider how best to react to the most recent incident > involving Symantec, and given that there is a question of whether it is > part of a pattern of

Re: Grace Period for Sub-CA Disclosure

On Fri, Mar 31, 2017 at 12:24 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > As previously stated, I think this will be too short if the issuance > happens at a time when a non-CCADB root program (or the CCADB > infrastructure) is closed for holidays,

Re: Symantec Issues List

On Sat, Apr 1, 2017 at 12:57 AM, Peter Bowen wrote: > (Wearing my personal hat) > > Ryan, > > I haven't reviewed the audit reports myself, but I'll assume all you > wrote is true. However, I think it is important to consider it in the > appropriate context. > The GeoRoot

Re: Policy 2.5 Proposal: Expand requirements about what an Audit Statement must include

On Wed, Apr 12, 2017 at 10:15 AM, Peter Bowen <pzbo...@gmail.com> wrote: > On Wed, Apr 12, 2017 at 5:57 AM, Ryan Sleevi via dev-security-policy > <dev-security-policy@lists.mozilla.org> wrote: > > > > A certificate hash does provide distinct value. > > > &g

Re: Symantec Response B

On Wed, Apr 12, 2017 at 4:24 AM, Kurt Roeckx via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > I don't think 2) applies. It's only their software, that obviously can't > be updated yet, and so won't enforce such limit. That doesn't prevent the > rest of us to set such

Re: Criticism of Google Re: Google Trust Services roots

On Thu, Apr 6, 2017 at 1:42 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > Here are some ideas for reasonable new/enhanced policies (rough > sketches to be discussed and honed before insertion into a future > Mozilla policy version): > Are you

Re: Policy 2.5 Proposal: Remove BR duplication: reasons for revocation

Gerv, I must admit, I'm not sure I understand what you consider irrelevant reasons for 4.9.1 in the context of e-mail addresses. The only one I can think of is "7. The CA is made aware that a Wildcard Certificate has been used to authenticate a fraudulently misleading subordinate Fully-Qualified

Re: Policy 2.5 Proposal: Remove BR duplication: reasons for revocation

On Thu, Apr 20, 2017 at 6:15 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > Technically, the part after the @ could also be a bang!path, though > this is rare these days. > No, technically, it could not. RFC 5280, Section 4.2.1.6. Subject Alternative

Re: Symantec Conclusions and Next Steps

On Fri, Apr 21, 2017 at 6:16 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > I've updated the Issues list: > https://wiki.mozilla.org/CA:Symantec_Issues > with the latest information. 3 issues have been marked as STRUCK due to > lack of evidence of

Re: CA Validation quality is failing

On Wed, Apr 19, 2017 at 3:47 PM, Mike vd Ent via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Ryan, > > My answers on the particular issues are stated inline. > But the thing I want to address is how could (in this case Digicert) > validate such data and issues

Re: Policy 2.5 Proposal: Remove the bullet about "fraudulent use"

+1 to what sounds like a perfectly reasonable position ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy

Re: CA Validation quality is failing

On Thu, Apr 20, 2017 at 6:42 AM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > One thing: > > Could this be a result of the common (among CAs) bug of requiring entry > of a US/Canada State/Province regardless of country, forcing applicants > to fill in

Re: Email sub-CAs

On Thu, Apr 13, 2017 at 10:48 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > > Section 3.1.2.1 specifies that any CA capable of issuing secure email > > certificates must have a "WebTrust for CAs" audit (or corresponding > > ETSI audit). This is a

Re: Certificate issues

On Tue, Apr 18, 2017 at 12:09 PM, Jeremy Rowley via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Hi everyone, > > > > On Friday at 1:00 pm, we accidently introduced a bug into our issuance > system that resulted in five serverAuth-code signing certificates that did > not

Re: Certificate issues

On Tue, Apr 18, 2017 at 1:32 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > I believe the point was to check the prospective contents of the > TBSCertificate *before* CT logging (noting that Ryan Sleevi has been > violently insisting that failing to do

Re: CA Validation quality is failing

On Wed, Apr 19, 2017 at 6:41 PM, Peter Gutmann via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Kurt Roeckx via dev-security-policy > writes: > > >Both the localityName and stateOrProvinceName are Almere, while the > province > >is

Re: CA Validation quality is failing

On Wed, Apr 19, 2017 at 7:53 PM, Kurt Roeckx via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > (It was a code sign certificate, but I expect if it's labeled EV > that the same things apply.) > Not necessarily. A separate set of guidelines cover those -

Re: Removing "Wildcard DV Certs" from Potentially Problematic Practices list

On Sun, Apr 23, 2017 at 7:41 AM, Nick Lamb via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > I was thinking of things like the GoDaddy incident reported in January > where they had mistakenly been accepting HTTP 404s to validate a domain or > the 2016 Comodo "re-dressing"

Re: Include Renewed Kamu SM root certificate

On Thu, Mar 9, 2017 at 12:26 PM, tugba onder via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Here, the part that needs to be taken care is "validate using at least one > of the methods listed". Although we mentioned it in our previous response, > I guess you missed it;

Re: Symantec: Next Steps

On Thu, Mar 9, 2017 at 1:34 PM, Steve Medin via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > In the case of CrossCert, where we have evidence of failure to properly > document their work, we are NOT relying on their previous work and have > begun fully revalidating all

Re: DigiCert BR violation

(Wearing an individual hat) On Thu, Mar 9, 2017 at 4:18 PM, Jeremy Rowley via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Although we have a policy > against using live certificates for testing, the policy was not followed in > this case. Can you share why? Can you

Re: Symantec: Next Steps

On Wed, Mar 8, 2017 at 10:30 AM, Gervase Markham wrote: > On 07/03/17 20:37, Ryan Sleevi wrote: > > To make it simpler, wouldn't be a Policy Proposal be to prohibit > Delegated > > Third Parties from participating in the issuance process? This would be > > effectively the same,

Re: Symantec: Next Steps

On Wed, Mar 8, 2017 at 8:46 AM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Yes, I agree they should be functionally equivalent, in the sense that > all aspects of the operation and issuance are validated, and that one > entity is ultimately responsible

Re: Symantec: Next Steps

On Wed, Mar 8, 2017 at 9:23 AM, Peter Bowen via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > This is why I'm suggesting, from an audit scope, they're functionally > > equivalent approach, except one avoids the whole complexity of > identifying > > where or not a DTP is

DigiCert BR violation

It appears that DigiCert has violated the Baseline Requirements, as recently notified to the CA/Browser Forum. The certificate at https://crt.sh/?id=98120546 does not comply with RFC 5280. RFC 5280 defines the upper-bound of the commonName field as 64 characters, specifically ub-common-name

Re: Google Trust Services roots

Hi Richard, That's not how Certificate Policy OIDs work - either in the specifications or in the Baseline Requirements. I'm also not aware of any program requiring what you describe. Because of this, it's unclear to me, and I suspect many other readers, why you believe this is the case, or if

Re: Google Trust Services roots

Well, you still said the same thing, and I understood what you said, but not why you said it or why you believe it. That's why I was asking for new details. Certificate Policy OIDs don't say who the certificate belongs to or who issued the certificate. They describe the policies relative to how

Re: Google Trust Services roots

On Wed, Mar 8, 2017 at 1:02 PM, Ryan Hurst via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > There are some limitations relative to where this domain information is > used, for example > in the case of an EV certificate, if Google were to request Microsoft > use this

Re: Symantec: Next Steps

On Tue, Mar 7, 2017 at 6:37 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Policy Proposal 1: require all CAs to arrange it so that certs validated > by an RA are issued from one or more intermediates dedicated solely to > that RA, with such

Re: Google Trust Services roots

Yes, it means the two companies used the same policy for issuance - as identified by that policy. Did you read the ETSI materials I suggested you do? Perhaps this would make it easier for you. I don't think encouraging a CA to misissue - which if you read other people's replies, you would see

Re: Symantec: Next Steps

On Thu, Mar 9, 2017 at 6:48 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > That seems to make sense to me. Given that the BRs have the concept of a > DTP, how can we best align the two in practice? Does requiring every RA > to have its own subCA do

Re: Include Renewed Kamu SM root certificate

On Wed, Mar 8, 2017 at 9:56 AM, tugba onder via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > 3.2.2.4.6: Applicant representative is requested to change a web page > hosted in certificate requested domain. That change is done by serving the > file which we sent for this

Re: Symantec: Next Steps

On Wed, Mar 8, 2017 at 12:57 AM, Peter Bowen via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > If the DTP is only performing the functions that Jakob lists, then > they only need an auditor's opinion covering those functions. In fact > there is no way for an auditor to

Re: Symantec: Next Steps

On Wed, Mar 8, 2017 at 1:29 AM, Santhan Raj via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > Ryan, > > Section 8.4 (cited below), as worded today, does not mandate a DTP to go > through an audit. Rather, it requires the CA to perform additional > out-of-band checks or

Re: DigiCert BR violation

On Monday, March 13, 2017 at 5:12:39 PM UTC-4, Jeremy Rowley wrote: > I don't disagree that teletext shouldn't be used, and we no longer include > it in new certificate requests or renewals. However, we do include teletext > in certificates that originally had teletext strings but are being

Re: Mozilla Root Store Policy 2.4.1

Hi Gerv, I'm assuming as with previous discussions, you'd like to keep the discussion on the list. Overall: I would suggest every "should" be replaced with either a "must" or a "shall" RFC2119 style, to avoid any "best practice" vs "required mandate" confusion. 1.1 Scope Item 2: Bullet 1:

Re: Mozilla Root Store Policy 2.4.1

On Tue, Mar 7, 2017 at 5:09 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > 1.1 Scope > > Item 2: > > Bullet 1: This would allow the anyEKU to be considered 'out of > scope'. > > Is that intentional? (notwithstanding Section 5.3.1) > >

Re: Maximum validity of pre-BR certificates

On Sat, Mar 4, 2017 at 4:20 PM, Daniel Cater via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Saturday, 4 March 2017 21:21:41 UTC, Jeremy Rowley wrote: > > Common practice amongst certain cas. There were several cas that have > always opposed cert validity periods

  1   2   3   4   5   6   7   8   9   10   >