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 the
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 you'v
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 r
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
[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 BouncyCa
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
t
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.
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 is
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
#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 t
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 the
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
, mozilla-dev-security-policy
Subject: Re: On the value of EV
If the signal can
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, 5
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 signal
I don’t see how you can argue that the EV “seatbelt” breaks 100% of the time.
I know my bank uses an EV cert. Any time I come across a site claiming to be
my bank but lacking an EV cert, and my browser shows me that distinction, is a
time when the seatbelt saves me, through that extra signal t
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: "r...@sleevi.com"
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
2017 at 1:18 PM
To: Tim Shirley mailto:tshir...@trustwave.com>>
Cc: Nick Lamb mailto:n...@tlrmx.org>>,
"dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org>"
mailto:dev-security-policy@lists.mozilla.org>>,
Jakob Bohm mailto:jb-mozi
PM
To: Tim Shirley
Cc: Nick Lamb , "dev-security-policy@lists.mozilla.org"
, Jakob Bohm
Subject: Re: On the value of EV
On Wed, Dec 13, 2017 at 12:58 PM, Tim Shirley via dev-security-policy
mailto:dev-security-policy@lists.mozilla.org>>
wrote:
As an employee of a CA, I’m sure many
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 a
20 matches
Mail list logo