FF52 beta send SSL record layer with min=1 and max=3or4

Richard's advice is worth following. m.d.s.policy is not about bugs in web servers on the whole (and that's what you've got here most likely) However, a quick Google suggests that "SSL record layer" is a term one popular tool uses to describe any SSL or TLS Hello message that goes unanswered,

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

On Thursday, 23 February 2017 01:11:54 UTC, Richard Wang wrote: > https://crt.sh/?id=65208905 for google.ligboy.org Without wanting to jump on this pre-existing dogpile: This specific example is illustrative of two important factors that should be considered in examining the threat here: 1.

Re: Intermediates Supporting Many EE Certs

On Monday, 13 February 2017 22:40:45 UTC, Steve Medin wrote: > With de facto use of AIA, there is no issuer installation on the server that > could be improper. Proper is defined at the moment, either by cache or > discovery hints. Much as I should like ubiquitous ambient Internet to be a

Re: Misissued/Suspicious Symantec Certificates

On Sunday, 12 February 2017 15:28:26 UTC, Steve Medin wrote: > A response is now available in Bugzilla 1334377 and directly at: > https://bugzilla.mozilla.org/attachment.cgi?id=8836487 Thanks for these responses Steve, I believe that Symantec's decision to terminate the RA Partner programme was

Re: Misissued/Suspicious Symantec Certificates

On Thursday, 9 February 2017 03:08:14 UTC, Ryan Sleevi wrote: > 19) Can you confirm that Certsuperior, Certisign, CrossCert, and Certisur > are the only Delegated Third Parties utilized by Symantec, across all > Symantec operated CAs that are trusted by Mozilla products? Maybe Ryan has better

Re: Intermediates Supporting Many EE Certs

On Tuesday, 14 February 2017 13:47:51 UTC, Steve Medin wrote: > - PKCS#7 chains are indeed not a requirement, but see point 1. It’s > probably no coincidence that IIS supports it given awareness of the demands > placed on enterprise IT admins. I don't see how PKCS#7 offers any

Re: Intermediates Supporting Many EE Certs

On Tuesday, 14 February 2017 17:55:18 UTC, Jakob Bohm wrote: > Unfortunately, for these not-quite-web-server things (printers, routers > etc.), automating use of the current ACME Let's encrypt protocol with > or without hardcoding the Let's Encrypt URL is a non-starter for anyone > using these

Re: GoDaddy Misissuance Action Items

On Monday, 13 February 2017 15:15:47 UTC, Jürgen Brauckmann wrote: > I'm probably confused regarding BRs pre/post Ballot 181: Aren't there > only 4 methods per Ballot 181? > > Jürgen Ballot 169 identified exactly 10 methods. Although this ballot passed unanimously, meaning that both CA members

Re: Intermediates Supporting Many EE Certs

On Monday, 13 February 2017 16:18:46 UTC, Steve Medin wrote: > Getting all user agents with interest is issuance limits to implement the CA > Issuers form of AIA for dynamic path discovery and educating server operators > to get out of the practice of static chain installation on servers would

Re: SHA-1 serverAuth cert issued by Trustis in November 2016

On Wednesday, 15 February 2017 22:02:50 UTC, Rob Stradling wrote: > This currently unrevoked cert has a SHA-1/RSA signature, the serverAuth > EKU and CN=hmrcset.trustis.com: > https://crt.sh/?id=50773741=cablint > > It lacks the SAN extension, but that doesn't excuse it from the ban on >

Re: Incapsula via GlobalSign issued[ing] a certificate for non-existing domain (testslsslfeb20.me)

On Tuesday, 28 February 2017 12:29:30 UTC, Itzhak Daniel wrote: > I also would like to have an official reply from GlobalSign saying that "on > the date they issue the certificate the domain exists". Doug/ GlobalSign has responded but I'll mention here that lists of recently abandoned domain

Re: Incapsula via GlobalSign issued[ing] a certificate for non-existing domain (testslsslfeb20.me)

On Tuesday, 28 February 2017 16:00:47 UTC, Nick Lamb wrote: > e.g. http://domaingraveyard.com/list/2016-05-10.txt Typical, I posted that and then I checked from another browser and it now gives an access error. Anyway, there are others of the same ilk out there, these names (at least some of

Re: GlobalSign BR violation

On Monday, 27 February 2017 00:53:46 UTC, Itzhak Daniel wrote: > How those lines are parsed? what happens when a client reaches a whitespace? > Will this allow 'vietnamairlines.com' to use 'owa', 'mail' and 'autodiscover' > in their internal infrastructure? Because they're dnsNames a correctly

Researcher Says API Flaw Exposed Symantec Certificates, Including Private Keys

In order for Symantec to reveal anybody's private keys they'd first need to have those keys, which is already, IIRC forbidden in the BRs. So even proof that Symantec routinely had these keys is a big deal. The whole reason things like CSR signing exist is that public CAs have no reason to know

Re: Suspicious test.com Cert Issued By GlobalSign

On Friday, 24 March 2017 10:11:36 UTC, Gervase Markham wrote: > I spoke about this with Doug at the CAB Forum meeting. The system which > collects the data is not integrated with the system to which the domains > are added. The validation specialist concerned, contrary to policy > ("it's just a

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

Doesn't Chrome's behaviour already "penalise" plaintext HTTP? You can't build a login form, or use shiny new features. We aren't where we'd ideally be, everybody is agreed about that. That's not the same thing as agreeing our direction of travel is wrong. I am far from home reduced to using

Re: GlobalSign BR violation

On Tuesday, 4 April 2017 16:31:10 UTC+1, douglas...@gmail.com wrote: > How this happened: Thanks Doug, I have a question: These certificates appear to be not only forbidden by the BRs but also technically unlikely to function as desired by the subscriber. Did any customers report problems

Re: Symantec Response R

On Monday, 10 April 2017 20:28:53 UTC+1, michael...@gmail.com wrote: > A couple points of clarification please: > > 1) Mr. Byrne clarified his post to note that the flaws in the Symantec API > would allow: retrieval of certificates that included private keys, not the > private keys alone. Was

Re: Grace Period for Sub-CA Disclosure

On Tuesday, 4 April 2017 04:18:41 UTC+1, Jakob Bohm wrote: > So why does Mozilla want disclosure and not just a blanket X on a form > stating that all SubCAs are adequately audited, follow BRs etc.? Not speaking for Mozilla of course, but as a fan of disclosure provisions: Mandating disclosure

Re: Criticism of Google Re: Google Trust Services roots

On Monday, 3 April 2017 23:34:44 UTC+1, Peter Kurrasch wrote: > I must be missing something still? The implication here is that a purchaser > who is not yet part of the root program is permitted to take possession of > the root cert private key and possibly the physical space, key personnel, >

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

On Friday, 31 March 2017 17:27:34 UTC+1, tarah.s...@gmail.com wrote: > I'm Tarah. I am the Principal Security Advocate and Senior Director of > Engineering at Symantec Website Security (the certificate authority. Hello Tarah, Regular readers of m.d.s.policy will not be surprised that the news

Re: Symantec Response R

My understanding is that the QuickInvite system doesn't distinguish the reseller from their customer in terms of access to the order. It's not very clear from Symantec's documentation, and Tarah never got back to me in the thread about it, but I think a reseller absolutely can wait for their

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

On Thursday, 20 April 2017 14:03:36 UTC+1, Gervase Markham wrote: > I propose this section be removed from the document. I am not so sure the section ought to be removed. Wildcard DV is potentially problematic. Historically we have seen problems that wouldn't have happened or would be much

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

On Friday, 21 April 2017 11:02:01 UTC+1, Gervase Markham wrote: > This is all a bit inchoate :-) Can you give me any idea at all of what > such a policy would look like? Requiring OV is not an option IMO. Yes, it's inchoate, if I had a fully filled out policy in mind here I'd be proposing that

Re: CloudFlare Issuing SHA-1 SSL Certificates

On Saturday, 15 April 2017 13:59:18 UTC+1, Samuel Pinder wrote: > Quite an interesting workaround to support older > software, it's not exactly encouraging since SHA-1 collisions are now > possible. I would expect that CloudFlare operate this solution on the > condition that their customers are

Re: Certificate issues

Hi Jeremy Given the small number of certificates involved, it might make sense to just convert them to text and mention them inline, or put them somewhere we can all see them - if it's inconvenient to put them into the CT logs. I think this situation will be useful as evidence of the value of

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

On Saturday, 22 April 2017 02:24:50 UTC+1, Matt Palmer wrote: > Can you remind me (and the list) what specific instances you're referring > to? 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

Re: Certificate issues

On Tuesday, 18 April 2017 18:33:29 UTC+1, Jakob Bohm 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 that shall be punished as > harshly as actual misissuance)

Re: DigiCert BR violation

On Monday, 13 March 2017 21:31:46 UTC, Ryan Sleevi wrote: > Are you saying that there are one or more clients that require DigiCert to > support Teletext strings? Can we stop saying Teletext? The X500 series standards are talking about Teletex. One letter shorter. Teletext was invented by the

Re: Incapsula via GlobalSign issued[ing] a certificate for non-existing domain (testslsslfeb20.me)

On Friday, 3 March 2017 07:49:28 UTC, Ryan Sleevi wrote: > It is not acceptable. It's explicitly prohibited multiple ways to allow > more than 24 hours when such situations are brought to the CAs' attention. I'm sympathetic to the idea, here and in all cases where we have no reason to suppose

Re: Grace Period for Sub-CA Disclosure

Further to Ryan's reply, we can once again take lessons from the real world Ordinarily notice in law can be given by sending a letter and waiting a few days. There is no obligation to prove the letter was delivered, let alone read and comprehended, only that it was sent and that it was

Re: Final Decision by Google on Symantec

Other contributors have, I think, summed up the pros and cons of the two ways forward on the specific date very effectively. So I will expend my effort instead on pressing for Mozilla to handle final distrust of the old Symantec CA roots in its usual fashion and explicitly _not_ do as Symantec

RE: StartCom cross-signs disclosed by Certinomis

1. It is well established that logging pre-certs constitutes "issuance" for purposes of policy compliance. If you wouldn't issue it, don't log it. Not difficult. And this isn't new. 2. When a new path comes into existence in the Web PKI you don't need to explicitly "use" it as a CA, the

Re: dNSName containing '/' / low serial number entropy

On top of what Ryan has written, I want to specifically praise the approach of actually checking a sample of certificates as PKIoverheid describes. I think done well this can be a very affordable yet timely and effective way to detect problems in a particular issuance pipeline or with a

Re: 2017.08.10 Let's Encrypt Unicode Normalization Compliance Incident

On Friday, 11 August 2017 16:49:29 UTC+1, Ryan Sleevi wrote: > Could you expand on this? It's not obvious what you mean. I guess I was unclear. My concern was that one obvious way to approach this is to set things up so that after the certificate is signed, Boulder runs cablint, and if it

Re: Certificates with less than 64 bits of entropy

On Thursday, 10 August 2017 16:20:56 UTC+1, Jonathan Rudenberg wrote: - Three intermediates, "TeleSec ServerPass Class 2 CA”, "Go Daddy Secure Certificate Authority - G2”, and "Starfield Secure Certificate Authority - G2”, (which are not in this list) appear to issue certificates with serial

Re: 2017.08.10 Let's Encrypt Unicode Normalization Compliance Incident

On Friday, 11 August 2017 14:19:57 UTC+1, Alex Gaynor wrote: > Given that these were all caught by cablint, has Let's Encrypt considered > integrating it into your issuance pipeline, or automatically monitoring > crt.sh (which runs cablint) for these issues so they don't need to be > caught

Re: Certificates with less than 64 bits of entropy

On Sunday, 13 August 2017 04:04:45 UTC+1, Eric Mill wrote: > While not every issuing CA may take security seriously enough to employ > engineers on staff who can research, author and deploy a production code > fix in a 24 hour period, every issuing CA should be able to muster the > strength to

Re: Symantec Update on SubCA Proposal

One good thing we should be able to hope for from a change in ownership even if the personnel and equipment are the same or a great deal in common: improved management oversight. In my view the most worrying underlying problem at Symantec was the inadequate oversight. Senior management at the

Re: Misissued certificates

On Thursday, 10 August 2017 16:55:22 UTC+1, iden...@gmail.com wrote: > certificates contain the issue. Three (3) of these are real certificates; > however, one has expired. We have revoked the other two certificates. The > remaining two (2) are pre-certificates. To clear this up for anybody who

Re: Certificate with invalid dnsName issued from Baltimore intermediate

On Monday, 17 July 2017 16:22:22 UTC+1, Ben Wilson wrote: > Thank you for bringing this to our attention. We have contacted Intesa > Sanpaolo regarding this error and have asked them to correct it as soon as > possible. "Correcting" the error is surely the smaller of the two tasks ahead.

Re: How long to resolve unaudited unconstrained intermediates?

On Tuesday, 11 July 2017 10:56:43 UTC+1, Kurt Roeckx wrote:> > So at least some of them have been notified more than 3 months ago, and > a bug was filed a month later. I think you already gave them too much > time to at least respond to it, and suggest that you sent a new email > indicating

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

On Tuesday, 18 July 2017 07:45:01 UTC+1, Jakob Bohm wrote: > 1. I believe (though others may know better) that the high general >requirements for the security of CA systems also apply to the >systems performing the validation procedures in question. Yes, however I don't think Matthew's

Re: Certificate with invalid dnsName issued from Baltimore intermediate

On Tuesday, 18 July 2017 20:29:50 UTC+1, Jeremy Rowley wrote: > Some of these certs are really old. Is there a reason people were using > double dot names? Are they all mistakes in the certificate request or is > there some logic behind them? Unless I see good evidence to the contrary I will

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

On Friday, 21 July 2017 01:13:15 UTC+1, Matthew Hardeman wrote: > As easily as that, one could definitely get a certificate issued without > breaking most of the internet, without leaving much of a trace, and without > failing domain validation. One trace this would leave, if done using Let's

Re: Certificate with invalid dnsName issued from Baltimore intermediate

On Sunday, 23 July 2017 20:12:18 UTC+1, Charles Reiss wrote: > This CA also issued a recent certificate for the unqualified dNSName > 'webinterfacestrong': https://crt.sh/?id=177606495 Another name that it shouldn't be possible to issue for, but this time one which can actually exist in local

Re: Symantec Update on SubCA Proposal

On Tuesday, 25 July 2017 21:29:06 UTC+1, Rick Andrews wrote: > The details of this process would probably be best served in a separate > thread. Essentially, such a process would involve a quick assessment by the > community on the context and merits of the request by the customer You want us

Re: DigiCert policy violation - non-disclosure of https://crt.sh/?id=160110886

On Monday, 3 July 2017 23:05:53 UTC+1, Jeremy Rowley wrote: > And it's hardly fair to deride my lack of understanding on what transitive > trust entails in the digital certificate space considering it's outside of > the usual trust paths, not defined in the standard RFCs, and not the same as >

Re: DigiCert policy violation - non-disclosure of https://crt.sh/?id=160110886

On Monday, 3 July 2017 22:00:00 UTC+1, Jeremy Rowley wrote: > Link please to a formal definition? As your email alleges a policy violation > by one a cross-signed CAs, we take the investigation and response very > seriously. I'd like to know the basis for the definition before formulating > an

Re: DigiCert policy violation - non-disclosure of https://crt.sh/?id=160110886

On Tuesday, 4 July 2017 10:50:43 UTC+1, Jeremy Rowley wrote: > I'm an idiot. The discussion wasn't meant to be a red herring. Just a > momentary lapse in intelligence... > > It really looks like this from a validation perspective, right? EE -> > Self-signed -> Issuing CA (as it has the same

Re: Found something I can't understand in these cerificates.

On Tuesday, 1 August 2017 08:39:28 UTC+1, Han Yuwei wrote: > 1. the CN of two cerificates are same. So it is not necessary to issue two > certificates in just 2 minutes. I think the most likely explanation is the difference in signature algorithm, but it is also not uncommon for subscribers to

Re: Certificate with invalid dnsName issued from Baltimore intermediate

On Monday, 24 July 2017 17:34:03 UTC+1, Ben Wilson wrote: > Nick, > We are in discussions with Intesa Sanpaolo about implementing/pursuing > OneCRL or a similar approach (e.g. outright revocation of the CAs). > Thanks, > Ben Is there any progress on this? To be honest I was more meaning that

Re: Certificates issued with HTTPS OCSP responder URL (IdenTrust)

On Monday, 7 August 2017 22:31:34 UTC+1, Jakob Bohm wrote: > Since the CT made it possible, I have seen an increasing obsession with > enforcing every little detail of the BRs, things that would not only > have gone unnoticed, but also been considered unremarkable before CT. Even if I had no

Re: Certificates with common names not present in their SANs

On Sunday, 6 August 2017 14:10:36 UTC+1, alex@gmail.com wrote: > - Using non-IDNA encoded values in the CN, but (correctly!) IDNA encoding the > SAN Note https://bugs.python.org/issue28414 At least one popular implementation of TLS in a non-browser client (the Python SSL implementation)

Re: Certificates with common names not present in their SANs

"simply" how? If it's your belief that the Python code actually does work for IDN SANs I think you're going to need to do better than just asserting that it's "simply" so in the face of subject experts saying it's broken. ___ dev-security-policy

Re: Cert pinning mismatch investigation

On Tuesday, 2 May 2017 14:52:52 UTC+1, Gervase Markham wrote: > Group participants may be interested in David Keeler's analysis of why > Firefox seemed to be seeing cert pinning mismatches for Mozilla properties: > https://people-mozilla.org/~dkeeler/deployment-checker-analysis.html Indeed, that

Re: Changing CCADB domains

Thanks for your notice Kathleen. One thought: Very often several CAs ask for more time to complete the Mozilla survey, either explicitly, or implicitly by just not filling it out in a timely fashion and saying they're very busy and will do it "soon" if they're asked. If you believe there are,

Re: Configuring Graduated Trust for Non-Browser Consumption

Cory, from your point of view is there interest in being able to tell Requests "I want the no-compromises trust store" and accept a reduced compatibility in exchange for knowing that you're a little safer ? Right now, as a programmer I have three choices with Requests: Verify=True: The

Re: [EXT] Mozilla requirements of Symantec

On Monday, 12 June 2017 17:31:58 UTC+1, Steve Medin wrote: > We think it is critically important to distinguish potential removal of > support for current roots in Firefox versus across NSS. Limiting Firefox > trust to a subset of roots while leaving NSS unchanged would avoid > unintentionally

Re: Private key corresponding to public key in trusted Cisco certificate embedded in executable

On Tuesday, 20 June 2017 05:50:06 UTC+1, Matthew Hardeman wrote: > The right balance is probably revoking when misuse is shown. Plus education. Robin has stated that there _are_ suitable CA products for this use case in existence today, but if I didn't know it stands to reason that at least

Re: Mozilla Policy and CCADB Disclosure scope

On Friday, 19 May 2017 20:41:20 UTC+1, Matthew Hardeman wrote: > From a perspective of risk to the broader web PKI, it would appear that a > properly name constrained intermediate with (for example) only the Server > and Client TLS authentication ekus with name constraints limited to >

Re: Google Plan for Symantec posted

On Saturday, 20 May 2017 15:49:44 UTC+1, Michael Casadevall wrote: > Sanity check here, but I thought that OCSP-CT-Stapling required SCTs to > be created at the time of issuance. Not sure if there's a way to > backdate this requirement. If this is only intended for the new roots > then just a

Re: TrustCor root inclusion request

On Thursday, 18 May 2017 04:23:17 UTC+1, Aaron Wu wrote: > - DV SSL Certificates - the domain name registrar must list the applicant as > part of the WHOIS record; or effective control of the domain shall be > demonstrated by the applicant or communication satisfying BR 3.2.2.4 shall be >

Re: Policy 2.5 Proposal: Add definition of "mis-issuance"

I think a broad definition is appropriate here. Mozilla is not obliged to do anything at all, much less anything drastic if it is discovered that mis-issuance has occurred. At most we might think it time to re-evaluate this policy. Fools are endlessly inventive so a too narrow definition runs

Re: Policy 2.5 Proposal: Add definition of "mis-issuance"

On Tuesday, 6 June 2017 21:08:54 UTC+1, Ryan Sleevi wrote: > Standards defining organization. More usually a Standards _Development_ Organization. I wouldn't usually feel the need to offer this correction but in this context we care a good deal about the fact that SDOs are where the actual

Re: Policy 2.5 Proposal: Indicate direction of travel with respect to permitted domain validation methods

On Monday, 1 May 2017 22:02:58 UTC+1, Lee wrote: > Maybe it's because I've worked with some incredibly bad auditors, but > the way I read the proposal, doing anything other than one of those > exact 10 methods is risking an audit failure. > How would you word the policy to make it clear that

RE: CAA Certificate Problem Report

I'm struggling to get my head around what you're asking for. I think you're seriously asking if there's a way to skip all the actual security of DNSSEC and get a secure answer anyway? No. The answer is "No". If you're comfortable with answers that might be lies, you can skip DNSSEC entirely.

Re: CAA Certificate Problem Report

Gerv, rather than start by digging into the specific technical details, let me ask a high level question. Suppose I have deployed DNSSEC for my domain tlrmx.org and I have a CAA record saying to only permit the non-existent Gotham Certificates gotham.example to issue. You say you don't want

Re: FW: StartCom inclusion request: next steps

On Thursday, 14 September 2017 16:00:35 UTC+1, Inigo Barreira wrote: > Well, finally this is a business and I don´t think none on this list is > working for free. At the end everyone has his/her salary, etc. But that was > not the main reason because getting included in the root programs takes

Re: DigiCert-Symantec Announcement

On Friday, 22 September 2017 05:01:03 UTC+1, Peter Bowen wrote: > I realize this is somewhat more complex than what you, Ryan, or Jeremy > proposed, but it the only way I see root pins working across both > "old" and "new" trust stores. I would suggest that a better way to spend the remaining

Re: Efficient test for weak RSA keys generated in Infineon TPMs / smartcards

On Monday, 16 October 2017 23:15:51 UTC+1, Jakob Bohm wrote: > They have also obfuscated their test by providing bitmasks as decimal > bigints instead of using hexadecimal or any other format that makes the > bitmasks human readable. The essential fingerprinting trick comes down to this (I had

Re: Certigna Root Renewal Request

Thanks Kathleen, I have briefly inspected this BR Self Assessment document. Nothing terrifying leaped out at me that would lead me to ask that Mozilla deny the renewal, however I did find things worth mentioning here. The only listed 3.2.2.4 method is 3.2.2.4.5, Domain Authorization Document.

Incident Certificate signed with SHA1 Violation BR 7.3.1

Thanks for writing this incident report. The latter of the two certificates was issued after popular web browsers had ceased accepting SHA-1 as far as I understand it. As a result it seems likely that it would not have functioned as expected if a customer deployed it on a Web server. You

Re: (Mis)-Issuance on CAA Timeout in DNSSEC signed zone

On Tuesday, 12 September 2017 10:38:56 UTC+1, Inigo Barreira wrote: > Futhermore, according to the logs, at the time of checking for a CAA record, > there was none. The lookup was succesful and hence allowed the issuance. Given that this contradicts the facts alleged in Quirin's tests and the

Re: CAA Certificate Problem Report

On Monday, 11 September 2017 18:33:24 UTC+1, Jeremy Rowley wrote: > That's the entire corpus of information related to DNSSEC in the BRs. Under 4 > and 5, we successfully returned a DNS record. The lookup didn’t fail so the > sentence "the domain's zone does not have a DNSSEC validation chain

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

I think that instead Ryan H is suggesting that (some) CAs are taking advantage of multiple geographically distinct nodes to run the tests from one of the Blessed Methods against an applicant's systems from several places on the Internet at once. This mitigates against attacks that are able to

Re: BR compliance of legacy certs at root inclusion time

Actually previous SHA-1 certs might be one of the least objectionable non-compliances assuming that nobody expects Firefox, or other clients in the Web PKI to actually trust these certs, because the difference in signature algorithm contains the risk nicely. Bad guys who have speculatively

BR compliance of legacy certs at root inclusion time

I'll speak up for transparency again. In terms of policy the most vital thing is that a CA tells us about such certs during application. One way to do that would be to CT log them, but especially for small sets there might be other sensible ways. If we can't be shown the certs in question (or

Re: Violations of Baseline Requirements 4.9.10

Kurt, I think both the past experiences of m.d.s.policy with incidents that went undetected by auditors, and my own personal experience (not as part of the Web PKI) with professional audit firms is that they're not strong on the sort of technical requirements that we've seen here. If the rule

Re: Doppelganger/tripleganger intermediate certificates

On Wednesday, 4 October 2017 13:34:17 UTC+1, Adriano Santoni wrote: > Nick, > > I think I have addressed this in my reply to Rob Stradling a few minutes > ago. > > In short: no, the "temporary unconstrained subCA" does never exist as a > signed document, only the final (constrained) subCA is

Re: Question on CAA processing for mixed wildcard and non-wildcard SAN DNS names

On Fri, 24 Nov 2017 12:25:40 + Gervase Markham via dev-security-policy wrote: > Validate example.com -> add "www.example.com": seems fine to me, and a > reasonable accommodation to a common customer desire. > > Validate www.example.com -> add

Re: Question on CAA processing for mixed wildcard and non-wildcard SAN DNS names

On Tue, 28 Nov 2017 04:26:30 +0100 Jakob Bohm via dev-security-policy wrote: > Nick Lamb, in the message I replied to, clearly suggested as much, and > provided a contrived scenario to "prove" that point. That's true, and I apologise if the effect was to

Re: Anomalous Certificate Issuances based on historic CAA records

On Wed, 29 Nov 2017 22:37:08 + Ben Laurie via dev-security-policy wrote: > Presumably only for non-DNSSEC, actually? For DNSSEC, you have a clear > chain of responsibility for keys, and that is relatively easy to > build on. For DNSSEC a CA could (and

Re: On the value of EV

On Thu, 14 Dec 2017 16:33:29 -0800 (PST) Matthew Hardeman via dev-security-policy wrote: > That attack was by hacking the target's domain registrar account. > Others have done that as well, including against a Brazilian bank. > > The right attacker would

Re: On the value of EV

On Wed, 13 Dec 2017 12:29:40 +0100 Jakob Bohm via dev-security-policy wrote: > What is *programmatically* enforced is too little for human safety. > believing that computers can replace human judgement is a big mistake. > Most of the world knows this.

Re: DigiCert/Symantec updates

4.1 Further to Gerv's question in the bug, I see that Digicert have not actually enumerated the set of issued certificates which are affected. Are you confident that if it became necessary you can do this? I recommend doing this and reporting the count even if not asked to actually list all the

Re: .tg Certificates Issued by Let's Encrypt

On Tuesday, 14 November 2017 16:31:34 UTC, Kathleen Wilson wrote: > Based on information from folks that are monitoring their NS Records, we > believe that the .tg Registry problems were fixed on November 1, and > have remained fixed since then. > > I have not looked into how Registries are

Incident report: Certificates with error in subject: postalCode

My understanding is that postal codes written in this form are understood (even if not always specifically permitted) by many postal authorities and so this deviation would not be likely to impact deliverability of a snail mail letter sent (for whatever reason) to the address shown in the

Re: CA generated keys

On Sat, 9 Dec 2017 18:20:56 + Tim Hollebeek via dev-security-policy wrote: > First, third parties who are *not* CAs can run key generation and > escrow services, and then the third party service can apply for a > certificate for the key, and deliver the

Re: Certificate incident: private key leaked for wildcard certificate for *.sandbox.operations.dynamics.com

On Sat, 9 Dec 2017 09:51:59 +0100 Hanno Böck via dev-security-policy wrote: > On Fri, 8 Dec 2017 16:43:48 -0700 > Wayne Thayer via dev-security-policy > wrote: > > > The root CA is ultimately responsible for

Re: On the value of EV

On Mon, 11 Dec 2017 19:08:43 -0500 Adam Caudill via dev-security-policy wrote: > I can say from my own experience, in some states in the US, it's a > trivial matter to create a company online, with no validation of > identity or other information. It takes

RE: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident

As a lowly relying party, I have to say I'd expect better here.In particular, if example.com says their DNSSEC signed CAA forbade Let's Encrypt from issuing, and Let's Encrypt says otherwise, I absolutely would expect Let's Encrypt to produce DNSSEC signed RRs that match up to their story. The

Re: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident

On 21 May 2018 14:59, Ryan Sleevi wrote:Given the TTLs and the key sizes in use on DNSSEC records, why do you believe this?This is a smoking gun because it's extremely strong circumstantial evidence. Why else would these records exist except that in fact the "victim" published

Re: Malformed Certificate Revocation - Godaddy

Hi Daymion, I will summarise briefly my understanding of this report in case it is wrong, if so please correct me, I apologise, and the rest of the email is probably of no further importance: GoDaddy integrated a linter (checking the certificates for sense) in November 2017, and in February this

Re: Serial number length

On Fri, 29 Dec 2017 07:24:31 +0100 Jakob Bohm via dev-security-policy wrote: > 3. Or would the elimination in #2 reduce the entropy of such serial >numbers to slightly less than 64 bits (since there are less than > 2**64 allowed values for all but the

Re: 2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure

On Wed, 10 Jan 2018 15:10:41 +0100 Patrick Figel via dev-security-policy wrote: > A user on Hacker News brought up the possibility that the fairly > popular DirectAdmin control panel might also demonstrate the > problematic behaviour mentioned in your

Re: Possible Issue with Domain Validation Method 9 in a shared hosting environment

On Mon, 15 Jan 2018 18:18:10 + Doug Beattie via dev-security-policy wrote: > - Total number of active OneClick customers: < 10 What constitutes a OneClick customer in this sense? The focus of concern for tls-sni-01 was service providers who

Re: Certificates with 2008 Debian weak key bug

On Fri, 16 Feb 2018 11:28:41 + Arkadiusz Ławniczak via dev-security-policy wrote: > The issue was caused by incorrect calculation of the SHA1 > fingerprint of public key. Public keys hashes stored in Certum's > database was calculated from the

Re: GoDaddy Revocations Due to a Variety of Issues

On Fri, 20 Jul 2018 21:38:45 -0700 Peter Bowen via dev-security-policy wrote: > https://crt.sh/?id=294808610=zlint,cablint is one of the > certificates. It is not clear to me that there is an error here. > The DNS names in the SAN are correctly encoded and the Common Name in > the subject has

Re: Google Trust Services - Minor SCT issue disclosure

On Thu, 23 Aug 2018 05:50:05 -0700 (PDT) Andy Warner via dev-security-policy wrote: > May 21st 2018, a new tool for issuing certificates within Google was > made available to internal customers. Within hours we started to > receive reports that Chrome Canary (v67) with Certificate > Transparency

  1   2   >