RE: DigiCert OCSP services returns 1 byte

Why would a user agent view a pre-certificate as "evidence that an equivalent certificate exists"? It's evidence that it might exist.. That the CA had the intent to make it exist at the time they signed the precertificate.. But I can't find anything in RFC 6962 that suggests to me that if

RE: DigiCert OCSP services returns 1 byte

Certainly we (as a CA who uses such precertificate-signing CAs) never interpreted RFC 6962 or the other requirements as mandating or even suggesting that, for either of the possible interpretations of Alex's question. As soon as you hit the precertificate-signing CA in the validation path

Re: CAA record checking issue

Jeremy, Thanks for sharing this. After reading your description, I'm curious how your system was previously (or is now) satisfying the third criteria needed to issue in the face of a record lookup failure: confirming that the domain's zone does not have a DNSSEC validation chain to the ICANN

RE: Entropy of certificate serial number

If it were possible to do what you're suggesting, there's no reason you'd need to use the serial number for it. You could just as easily add that randomness in an additional SAN, or a certificate extension that the browser didn't care about. In fact, since the BRs require SHA-256 as a minimum

RE: CA-issued certificates for publicly-available private keys VU#553544

[Somehow the list got dropped on this when I did reply-all] It would probably be a good idea to submit the keys to https://pwnedkeys.com/submit.html as well, as a centralized way for CAs to verify that the keys are in fact compromised. We received one of these reports in the form of a

Re: DarkMatter Concerns

There are other ways to achieve a guarantee of non-collision besides re-generating. For example, we incorporate the timestamp of issuance into the serial number alongside the random bits. You could also incorporate a sequential value into your serial number. Both methods serve to guarantee

Re: CA Communication: Underscores in dNSNames

Validity period is a defined term in the BRs and refers to the time between issuance and expiry. Since the new language uses that term without any modifiers like "remaining", it seems clear to me that both of those example certificates would need to be revoked.

Re: Clarification about Ballot 193 and validity of a certificate issued on March 1st

First of all, it's important to distinguish between the BR requirement, which is defined in terms of certificate *issuance* dates, and the value in the "Not Before" field. I'm guessing the "Not Before" value in this certificate is not the actual issuance timestamp, since it's unlikely it was

Re: Submission to ct-logs of the final certificate when there is already a pre-certificate

That may well be the conclusion, that the benefits of total disclosure outweigh the costs in this type of scenario. I just wanted to point out that there IS a cost to at least consider. Yes, the certificate might have been seen in transmission between the CA and the customer, yes the customer

Re: Submission to ct-logs of the final certificate when there is already a pre-certificate

#2 seems like an obvious "no" to me as, at that point, you're only compounding a mistake and making that mistake actually usable in the public PKI if you proceed to issue the certificate. In practice I can't imagine this scenario coming up much, but the policy shouldn't mandate doing this. I

Re: Trustico code injection

That's jumping the gun a bit. First of all they'd have to be made aware of the suspected compromise before the 24 hour clock would start. And then they'd need to be convinced that it actually was compromised. Since the server has apparently been taken down, they wouldn't be able to verify

Re: On the value of EV

I’m saying “can” be spoofed is different than “is” being spoofed. From: Ryan Sleevi Reply-To: "r...@sleevi.com" Date: Friday, December 15, 2017 at 5:23 PM To: Tim Shirley Cc: "r...@sleevi.com" , Matthew Hardeman

Re: On the value of EV

Absolutely.. The lack of EV when I expect it doesn’t automatically mean to me that something is bad. It just puts me on high alert that something *might* be wrong. And I have never logged into a bank website from a mobile device, but my motivations for that go far beyond EV. ( On 12/15/17,

Re: On the value of EV

Yeah we’re definitely talking past each other. I’m not claiming the extra signal CAN’T be spoofed, nor am I claiming that EV prevents phishing or that the UI is providing me a guarantee. I’m saying it’s giving me a signal to pay closer attention, and I’m describing a scenario where that

Re: On the value of EV

No, I’m not presuming that; that’s why I put the ? after never. I’ve never heard of any, so it’s possible it really is never. But I’m pretty confident in at least the “rare” part because I’m sure if you knew of any you’d be sharing examples. ;) From: Ryan Sleevi Reply-To:

Re: On the value of EV

As I understand it, Adam’s argument there was that to get value out of a revoked certificate, you need to be between the user and the web server so you can direct the traffic to your web server, so you’re already in position to also block revocation checks. I don’t think that maps here because

Re: On the value of EV

tshir...@trustwave.com>> Cc: Nick Lamb <n...@tlrmx.org<mailto:n...@tlrmx.org>>, "dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org>" <dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org>>,

Re: On the value of EV

e: Wednesday, December 13, 2017 at 1:18 PM To: Tim Shirley <tshir...@trustwave.com> Cc: Nick Lamb <n...@tlrmx.org>, "dev-security-policy@lists.mozilla.org" <dev-security-policy@lists.mozilla.org>, Jakob Bohm <jb-mozi...@wisemo.com> Subject: Re: On the value of EV

Re: On the value of EV

So many of the arguments made here, such as this one, as well as the recent demonstrations that helped start this thread, focus on edge cases. And while those are certainly valuable to consider, they obscure the fact that “Green Bar” adds value in the mainstream use cases. If we were talking