Peter Bowen writes:
>When we replaced a certificate on a publicly facing server, certain functions
>on a consumer electronics device stopped working.After debugging we found out
>that the device in question does not have an internal time and date
>reference.When the device initializes communicati
Jeremy Rowley writes:
>I think this is a good idea. Per 5280, the notBefore date is used to
>indicate the start of the certificate's validity (not the date it was
>issued). Using a new optional extension for issuance date will avoid causing
>technical problems with other systems and still let Mo
Erwann Abalea writes:
>Has this extension been de-obsoleted? It was already deprecated in RFC2459,
>it's not even present in RFC5280 anymore.
Like other aspects of the web PKI (e.g. wildcard certs), this is one of the
areas where you need to ignore what PKIX says and do what makes sense. I've
Rob Stradling writes:
>SHA-256, SHA-384 and SHA-512 are the algorithms that CAs should use.
In my playing around with all the TLS and SSH implementations I could find
that talk SHA-2, I've found that SHA-256 is the new SHA-1. In other words if
you want interoprability with anything that does SH
"Man Ho (Certizen)" writes:
>If there is no constraints on choosing SHA-256, SHA-384 or SHA-512, why CAs
>are so conservative and prefer SHA-256 rather than SHA-512? I think going
>directly to a higher security strength should be preferable.
What extra security does -512 give you that -256 doe
"Man Ho (Certizen)" writes:
>According to NIST SP 800-57, only SHA-512 can provide a security strength of
>256 bits, while SHA-256 can only provide 128 bits.
In that case why not go for a hash with million-bit security? That statement
is meaningless without some sort of qualifiers for what you
Rob Stradling writes:
>RFC5820 4.2.1.12 seems to say it's _not_ entirely useless in TLS:
> "id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 }
> -- TLS WWW server authentication
> -- Key usage bits that may be consistent: digitalSignature,
> -- keyEncipherment _or keyAgreement_
Chris Palmer writes:
>Tangential, fun note: felt, et al. found that ~50% of users thought a
>green lock was *open*, hence unsafe â green means you can go, through
>the locked door, while red means the lock is securely locked. Like an
>airplane toilet...
Do you have a reference for this?
Peter
[Apologies if you've seen this before, it looks like up to a week's worth of
mail from here has been lost, this is a resend of the backlog]
Chris Palmer writes:
>Firefox 31 data:
>
>on desktop the median successful OCSP validation took 261ms, and the 95th
>percentile (looking at just the univer
Chris Palmer writes:
>FWIW, that's a misquote; I didn't write that.
Ooops, sorry, it was posted by Patrick McManus (I used
a script to try and resurrect the lost emails for re-send, I suspect something
got mangled somewhere).
So the question should have been addressed to Patrick (or anyone els
John Nagle writes:
>There's a real risk here. A break-in at any of those sites allows
>impersonating all of them. This creates a huge attack surface.
It's actually a lot worse than that, see "Virtual Host Confusion: Weaknesses
and Exploits" by Antoine Delignat-Lavaud and Karthikeyan Bhargavan
Mark Atwood writes:
>On Tue, Nov 18, 2014, at 11:25, Salz, Rich wrote:
>> Initial drop of code and specs available here:
>> https://github.com/letsencrypt
>>
>> From https://letsencrypt.org/2014/11/18/announcing-lets-encrypt.html :
>
>So Mozilla et al have been giving CAcert the runaround for over
Ryan Sleevi writes:
>DSA certificates are complicated due to parameter inheritance through the
>chain - which few get right, but which add ambiguity for path building and
>processing. DSA certificates cannot be used for certificate pinning in some
>cases because of this inherent ambiguity (
>http
Ryan Sleevi writes:
>(and for sure, Microsoft's stack _does_ implement it,
Does anyone know the motivation for this? MS also implemented support for
X9.42 certificates, which no-one has ever seen in the wild, but it was in
receive-only mode (it would never generate data using them) and was d
Framarti writes:
>i'm working for a company that is issuing trusted SSL OV certificates as a
>subsidiary CA. I was thinking about becoming a trusted root CA in order to
>get rid of the fees per each issued certificate to be given to actual root CA.
>
>2 - Submission to a third party Audit (i.e. v
writes:
>mmm i don't think it's the correct amount. As long as i know, obtaining a
>report (and relative seals) for Baseline v.2.0 and SSL criteria 2.0 should
>cost you around 100K dollars. Obviously not considering the money needed to
>fill any eventually emerged gaps from the standards (i.e. bu
Peter Kurrasch writes:
>I think focusing on the trusted root store as a way to resolve this problem
>is (or will be) less than ideal.? I understand the desire to look there but I
>don't think it will necessarily end well.
I think focusing on the browser as a whole is less than ideal. The browse
Matt Palmer writes:
>On Thu, Mar 19, 2015 at 01:01:32PM -0700, Peter Bowen wrote:
>> In the Pilot CT log, which includes every certificate that the Google
>> crawler has seen, I found 19 unexpired certificates issued by this CA.
>> Their subjects are as follows (using the default OpenSSL DN to str
Matt Palmer writes:
>However, given that CNNIC felt it appropriate to violate their CPS with
>regards to an intermediate CA certificate, I don't see that there's any
>greater reason to trust their adherence to their CPS in any other aspect.
>Thus, I'm not not keen on allowing them to issue *any*
Daniel Micay writes:
>CNNIC is known to have produced and distributed malware for the purpose of
>mass surveillance and censorship.
TeliaSonera aided totalitarian governments, Comodo provided the PrivDog MITM
software, and that's just the first two off the top of my head.
>If you have solid evi
Robin Alden writes:
>Your assertion about Comodo is wrong and that blunts your point instead of
>helping you make it.
I was using IT news stories as the source, e.g. IDG's "'Secure' advertising
tool PrivDog compromises HTTPS security":
Instead, the problem was tracked down to another advertis
Did anyone save a copy of the cert chain? I'd like to add it to my collection
of broken cer^H^H^H^H^Hcert parser test vectors, but the site has been fixed
and the Bugzilla entry doesn't contain it.
Peter.
___
dev-security-policy mailing list
dev-securit
Kurt Roeckx writes:
>The site hasn't been fixed, at least not for me.
Ah, both Firefox and IE were connecting, but that was because the HTTPS got
redirected to plain HTTP, and any of the links to HTTPS sites that I could
find on the site led to a bewildering array of affiliated sites that all
Erwann Abalea writes:
>That's really an OID, in the Microsoft arc. I don't know what triggered the
>"Error: OID contains random garbage" message,
Uhh, the fact that it contains random garbage encoded as an OID?
>This OID is correctly encoded, the fact that it contains somewhat random
>looking
AnilG writes:
>This is really big picture here: I've looked up and suddenly seen Firefox
>market share trajectory looking like we need some steering input fast. This
>is a 3 to 6 year picture of decline so it will take as long to correct.
Oh dear, this is really going to open a can of worms that
AnilG writes:
>To make my point again, I can't access https://input.mozilla.org/en-US/ from
>Firefox, I have to use Chrome.
Hmm, interesting, I'm getting it fine via Firefox. Could you be behind a MITM
proxy or something?
Peter.
___
dev-security-pol
Eric Mill writes:
>can anyone lay out what the steps to doing that would look like so the S/MIME
>community can react in more concrete ways?
Well, first you'll have to tell the S/MIME community what it is you want them
to do...
Peter.
___
dev-security
Peter Bowen writes:
>There are a couple of rules that may create false positives, so please don't
>assume every certificate on the sheet is problematic.
That's still pretty scary, nearly 50,000 names from a who's-who of commercial
CAs. Yet more evidence that, like the output from the EFF SSL Ob
Patrick T writes:
>I've found one of the certificates here (*.gov.bn, Symantec issued) seems to
>contain some NULL characters in the SAN.
Wow, you're right:
673 359: SEQUENCE {
677 33: SEQUENCE {
6793: OBJECT IDENTIFIER subjectAltName (2 5 29 17)
684 26:
Kai Engert writes:
>Independently of the request for inclusion, this group could discuss if the
>Kazakhstan's CAs should be blacklisted, by adding them to the Mozilla CA list
>using negative distrust flags
That would have some pretty bad consequences. With the MITM CA cert enabled,
Borat [0] ca
Kai Engert writes:
>On Sat, 2016-01-09 at 14:11 +0000, Peter Gutmann wrote:
>> That would have some pretty bad consequences. With the MITM CA cert enabled,
>> Borat [0] can read every Kazakh user's email, but no-one else can. With the
>> MITM CA blacklisted, Borat c
Paul Wouters writes:
>> If you disallow the cert and turn off encryption, Borat can still read
>> everyone's traffic, but so can everyone else on the planet.
>
>Who said "turn off encryption"?
If you don't allow the MITM cert, which is needed to enable encryption in the
browser, you don't get an
Paul Wouters writes:
>Or we ensure that firefox and chrome refuses to see those sites at all,
>because they refuse a downgrade attack.
So users will switch to whatever browser doesn't block it, because given the
choice between connecting to Facebook insecurely or not connecting at all,
about, oh
Gervase Markham writes:
>Mozilla is very keen to see SHA-1 eliminated, but understands that for
>historical reasons poor decisions were made in private PKIs about which roots
>to trust, and such decisions are not easily remedied.
I'm curious about what's going on here, as you say this is a priva
Rob Stradling writes:
>But if it's an old version of NSS or OpenSSL, then the community could help
>find an exploitable bug.
If it's a remote-code-exec we could patch their firmware for them to support
SHA-256. Think of it as an undocumented remote admin capability.
(Something like this has be
Steve writes:
>They state no business case where the 9 payment gateways are accessible by
>browsers or that any business case exists on the gateways that uses any
>client other than the payment terminal.
So these things will never see access by a browser enforcing the SHA-1
restrictions? Where
Dean Coclin writes:
>The same one they've been using and know works: VeriSign Class 3
>International Server CA - G3.
So the devices will trust any cert from this CA?
This is a serious question, a contractor once got into USG infrastructure
with a $20 or so cert because they'd done the same th
rbar...@mozilla.com writes:
>While we are disappointed that a critical part of the Internet
>infrastructure is holding back an increase in security, we believe that
>this allowance strikes an acceptable compromise between minimizing
>disruption and risk and encouraging migration away from SHA-
Dean Coclin writes:
>According to WP, as part of the EMV program, they are aggressively rolling
>out new devices to replace all old equipment in the field. They expect this
>to be completed by the end of the year. They have already moved a large
>number of devices to support SHA-2.
Wouldn't it b
Jürgen Brauckmann writes:
>Nice example from the consumer electronics world: Android >= 4.4 is quite
>resistant against private PKIs. You cannot import your own/your corporate
>private Root CAs for Openvpn- or Wifi access point security without getting
>persistent, nasty, user-confusing warning m
Jakob Bohm writes:
>2. Find a way to add OCSP responder chosen random data in each OCSP
> response.
Responder or requester? You've got the OCSP nonce, although since every
(public) CA has disabled it that probably won't help much. OTOH since clients
won't be checking the nonce because of thi
Andrew Ayer [a...@andrewayer.name] writes:
>Are there clients that will choke if they receive a response without the
>expected nonce?
See my previous message, since no public CAs honour nonces [0] I don't think
there'd be any problem.
Peter.
[0] At least as of the last check a few years ago.
__
Matt Palmer writes:
>On Mon, May 16, 2016 at 02:22:08PM +0200, Richard Z wrote:
>> knowingly issuing/tolerating certificates for sites known to inject
>> malware is
>> * contrary to user expectaions
>
>[Citation needed]
So you're saying users expect CAs to certify malware sites?
(There have bee
Hubert Kario writes:
>then users expect impossible
Users expect CAs to be something other than certificate vending machines. The
fact that CAs fail to do this is a problem with browser PKI and CAs, not with
users.
(There have been numerous cases of security people reporting CA-certified
phishin
Richard Z writes:
>If any criminal can easily get EV certificates what is the point of https?
The point of HTTPS is twofold:
1. Convince users that the Internet is safe to do business on (financial
transfers, medical data).
2. Provide a steady revenue stream for CAs.
There's also somethin
Ryan Sleevi writes:
>This seems both off-topic and not productively addressing the topic at hand.
Yeah, maybe it's best taken to another list like cypherpunks or the crypto
list. It was intended as an honest, and probably pretty blunt, assessment of
the state of HTTPS: It was introduced to buil
Gervase Markham writes:
>It depends what alternative configuration-free idiot-proof secure
>communications technology you have invented in your fantasy world to take its
>place.
Are you really trying to claim that the sad farce that is current browser PKI
is absolutely the very best that browser
John Nagle writes:
>As an example, suppose a server sending a page sends, at the beginning of the
>page, a hash value which is based on the contents of the page about to be
>sent, and also based on the first 64 bytes of the crypto bits of the
>connection. The browser checks this. The MITM attacke
Nick Lamb writes:
>There's plenty of hysteria about this cert based on who it was issued to,
>which is funny because the best example of real trust ecosystem risk we have
>recently is from the Disney subCA [quietly revoked by its issuer when it
>ceased obeying the BRs...], yet I saw precisely zer
Nick Lamb writes:
>ACME is a protocol intended to become an IETF Standards Track RFC.
Oh dear God, another one? We've already got CMP, CMC, SCEP, EST, and a whole
slew of other ones that failed to get as far as RFCs, which all do what ACME
is trying to do. What's the selling point for ACME? T
Nick Lamb writes:
>In the examples I've reviewed the decision seems to have been made (either
>explicitly or tacitly) to leave the really difficult problem - specifically
>achieving confidence in the identity of the subject - completely unaddressed.
There wasn't any decision to leave it unaddres
Nick Lamb writes:
>Early drafts of SCEP, before it confined itself to "closed networks" even
>spell out what the problem is before they basically say they're not going to
>make any real attempt to tackle it. CMP, CMC and SCEP all resort to saying
>that some "out of band" mechanism should be used
Patrick Figel writes:
>On 08/07/16 08:04, Peter Gutmann wrote:
>> Or is it that ACME is just a desperate attempt to derail StartCom's
>> StartEncrypt at any cost?
>
>That doesn't make any sense - ACME has been in production for close to a
>year, while Sta
Nick Lamb writes:
>SCEP (and all the real SCEP implementations that I could find) take the
>optimistic view that this is somebody else's problem, and so the practical
>result is security theatre.
Uhh, do you even know how SCEP is used? When you're provisioning a VPN
gateway, SCADA device, an i
itk98...@gmail.com writes:
>Wosign indirectly bought StartSSL, https://www.letsphish.org
Has there been any independent investigation into this? We know that CAs are
bought and sold like baseball trading cards, but it's usually done publicly
and freely acknowledged, whereas this one seems to ha
Rob Stradling writes:
>https://crt.sh/?serial=056d1570da645bf6b44c0a7077cc6769&iCAID=1662 says
>"Not Revoked" three times. I wonder if that's causing some confusion here.
Just to make sure I'm not misreading this in some way, is this really saying
there are 313 certs issued all with the same se
Rob Stradling writes:
>>I guess it makes them easy to revoke, if a single revocation can kill 313
>>certs at once.
>
>That's true.
Hey, WoSign has solved the CRL scalability problem!
>It'd be impossible to revoke (via CRL and/or OCSP) a subset of those 313
>certs though.
I also get the feeli
Vincent Lynch writes:
>I think Eddy Nigg (founder of StartCom) and/or Richard Wang (of WoSign)
>should make a statement about this.
+1. I'd already asked for something like this earlier and got silence as a
response, which isn't inspiring confidence.
Peter.
Peter Bowen writes:
>It was brought to my attention that there is another incident.
This is great stuff, it's like watching a rerun of Diginotar. Definitely the
best web soap in the last few weeks...
Peter.
___
dev-security-policy mailing list
dev-s
Eddy Nigg writes:
>On 09/04/2016 09:20 AM, Peter Gutmann wrote:
>> This is great stuff, it's like watching a rerun of Diginotar
>
>.says the audience on the backbenches gleefully
Well, it doesn't exactly paint the best picture of a competently-run CA, s
Matt Palmer writes:
>Our of curiosity, is anyone keeping a tally of the number of times WoSign has
>said, "yep, they're all logged now", only to have more unlogged certificates
>turn up? This is starting to feel like a bit of a repeat of DigiNotar,
We apologise for the fault in the CA. Those re
Peter Bowen writes:
>In addition to the direct impact, I note that WoSign is the subject of cross-
>signatures from a number of other CAs that chain back to roots in the Mozilla
>program (or were in the program).
This is incredible, it's like a hydra. Do the BRs say anything about this
type of
Nick Lamb writes:
>On Tuesday, 6 September 2016 15:11:00 UTC+1, Peter Gutmann wrote:
>> Why would a public CA even need cross-certification from other CAs?
>
>Maybe this question has some subtlety to it that I'm missing?
OK, I really meant "that many other CAs".
Peter Kurrasch writes:
>I would also ask for confirmation that "Andy Ligg" is in fact a real person
>and not a pseudonym adopted by Richard or someone else. The similarity to
>Eddy's name is...remarkable.
Andy Ligg? The only similar name I saw in Gerv's post was Revital Nigg, who
I'm guessing i
Jakob Bohm writes:
>Am I reading something wrong, or is their an unintended loophole in the
>Mozilla Policy, as written, in this regard?
A cynic would say that that's the exact intent of the policy, to ensure that
anything but a catastrophe-scale event that's so big that Mozilla can't ignore
it
Peter Bowen writes:
>As someone pointed out on Twitter this morning, it seems that the PSC
>notification for Startcom UK was filed recently:
>https://s3-eu-west-1.amazonaws.com/document-api-images-prod/docs/UdxHYAlFj6U9DNs6VBJdnIDv4IQAWd4YKYomMERO_2o/application-pdf
So if I'm reading that correc
Jakob Bohm writes:
>While you are at it:
>
>1. How many WoSign/StartCom certificates did you find with domains not
> on that IANA list?
>
>2. How many WoSign/StartCom certificates did you find for other uses
> than https://www.example.tld:
>
>2.1 Certificates for "odd" subdomains such as "ext
Jakob Bohm writes:
>This tells me that Firefox OCSP defaults are *insecure* and reaffirms my
>impression that Firefox has completely dropped the ball on CRL handling
>(Since the security-on setting is for OCSP only).
No, it tells me that the Firefox developers applied common sense (OK, the
peopl
Percy writes:
>On Tuesday, September 27, 2016 at 2:15:38 AM UTC-7, Gervase Markham wrote:
>> Participants may be interested in this blog post from Tyro:
>> https://tyro.com/blog/merchant-security-is-tyros-priority/
>
>So this is almost proof that WoSign/StartCom has been intentionally back-
>datin
Gijs Kruitbosch writes:
>(Some) People who "do" Firefox UI read this group. If you have concrete/
>constructive suggestions, please file bugs or write to more topical mailing
>lists - especially if you think there are things we should do "frontend"-
>wise to improve the security of end users.
O
Rob Stradling writes:
>Today we have revoked (via CRL and OCSP) all 3 of the cross-certificates that
>we'd issued to WoSign:
This allows us to examine the modern Internet variant of an old philosophical
question, "If a certificate is revoked in the web PKI and no one checks the
CRL, does it make
Rob Stradling writes:
>Easy. It doesn't make a sound. Unrevoked certificates don't make sounds
>either.
What I was really asking, in a tongue-in-cheek way, was whether there was any
indication of how successfully the information could be propagated to
browsers.
Peter.
Kurt Roeckx writes:
>This is why browsers have something like OneCRL, so that they actually do
>know about it and why Rob added that information to the bug tracker (
>https://bugzilla.mozilla.org/show_bug.cgi?id=906611#c2).
That still doesn't necessarily answer the question, Google have their CR
Ryan Sleevi writes:
>What is the goal of the root program? Should there be a higher bar for
>removing CAs than adding them? Does trust increase or decrease over time?
Another thing I'd like to bring up is the absolute silence of the CAB forum
over all this. Apple have quietly unilaterally distr
Ryan Sleevi writes:
>On Friday, October 14, 2016 at 3:44:50 PM UTC-7, Peter Gutmann wrote:
>> Another thing I'd like to bring up is the absolute silence of the CAB forum
>> over all this.
>
>It has not been.
I haven't heard anything from them. If they've ma
Peter Bowen writes:
>The CA/Browser Forum is not a regulatory body. They publish guidelines but
>do not set requirements nor regulate compliance.
It's a bit hard to describe its actual functioning, in theory they just
advise, but then so does ISO, IEEE, and others. They're not regulatory bodie
Erwann Abalea writes:
>And that's not CABF's duty and responsibility. What the CABF can impose to
>CABF members is to follow the bylaws, the internal governance rules. By
>following them, all members write the guidelines and decide on what changes
>to adopt, and browsers then impose CAs to follow
Nick Lamb writes:
>Although we'd usually say "contract" means a signed piece of paper the law
>considers that just an artefact, a contract is the "meeting of minds"
>requiring both parties to understand and agree on its terms. That's why
>tricking someone into signing works in the movies but not
popcorn writes:
>There were comments admonishing StartCom and WoSign for not reporting change
>of ownership in a timely manner.
>
>I am not sure if this has been reported earlier, but if not, then Qihoo 360
>change of ownership may be relevant to the current discussion:
>
>http://www.prnewswire.c
Peter Bowen writes:
>I think you found the "wrong" True Thrive Limited.
Ah, thanks.
>This appears to just be a name collision. Naming is hard :(
Actually if you think that's tough, try figuring out who the real Midco is...
Peter.
___
dev-security-p
Percy writes:
>As we observed the large scale MITM against iCloud, Outlook, Google and
>Github carried out on the backbone router with self-signed certs, and that
>the browsers are explicitly loads self-signed certs, I think it's clear that
>browsers in China are compelled by the gov to enable in
Tom Ritter writes:
>There's been (some) mention that even if a user moves off Cloudflare, the CA
>is not obligated to revoke.
Would it matter? I guess it depends on circumstances (whether you control the
private key or Cloudflare does, whether you intend to use the same domain
elsewhere or not,
lcchen.ci...@gmail.com writes:
>I explained the rollover certificate process outlined in RFC 4210 by signing
>the old public key with the new private key and the new public key with the
>old private key.
Uhh, that stuff was a gedanken experiment dreamed up by some folks in PKIX,
alongside things
capuchin...@gmail.com writes:
>However, that does not means our PKIX (RFC-5280) conforimg implementation
>will cause errors or bugs to current implementations of browsers.
Given all the bizarre stuff that ended up in the PKIX spec, it would be quite
easy to create a fully PKIX-compliant cert tha
Wen-Cheng Wang writes:
>Actually, we have tested the capabilities of many browsers in the wild and
>found they can live peacefully with our PKIX-compliant root certs.
Ah, OK. That's the right way to do it.
>They are not so weak as you might think.
I bet I can create PKIX-compliant certs (spe
Eric Rescorla writes:
>I don't think this really accurately reflects the consensus of the security
>community
Or of any community AFAIK. Perhaps there could be a special version of
Firefox that uses one-time pads for everything, and on startup uses a
cryptographically secure geolocation service
Jakob Bohm writes:
>DSA and ECDSA signatures are only secure if the hash algorithm is specified
>in the certificate, presumably as part of the AlgorithmIdentifier in the
>SubjectPublicKeyInfo.
It's in the (badly-named) signature field of the cert, if it was in the
signatureAlgorithm it wouldn't
Jakob Bohm writes:
>Surprised you didn't know that, considering who you are.
Uhh, I did know that, that's why I checked it about 15-odd years ago to see if
anything would notice if it was done wrong (I can't remember the exact date,
it was when I was still updating the X.509 Style Guide so aroun
Jakob Bohm writes:
>This changed the moment SHA-2 came out, though one could interpret that the
>length of the signature elements would uniquely indicate the SHA variant.
>With SHA-256/160 and SHA-3, that is completely gone as there are now two SHA
>hash algorithms for each length. Plus any non-
Ryan Sleevi writes:
>Current (and presently proposed) Mozilla policy does not allow them. Nor are
>they supported in Mozilla NSS anymore (and their previous support was not one
>you should use for security-critical purposes). Nor are they supported in
>other UAs.
I should point out that, for the
Kathleen Wilson writes:
>The encoding of the Issuer field in the CRL should be byte-for-byte
>equivalent with the encoding of the Issuer in the certificate; that is, using
>the exact same string types and field contents. The specs (RFC 2459, RFC 3280,
>RFC 5280) permit them to mismatch, but that
Nick Lamb writes:
>In practice then I think we should try to ask local experts (ie people at
>least resident in the relevant country) when trying to judge whether the
>Locality and State elements of a Subject DN are acceptable for identifying
>the actual Subject unless it is very obvious (as with
Kathleen Wilson writes:
>Indeed, and as per your comment here:
>https://bugzilla.mozilla.org/show_bug.cgi?id=1056341#c24
So just to satisfy my curiosity, it's been known ever since top-down
construction was first advocated by PKI loon^H^H^Htheoreticians:
https://www.youtube.com/watch?v=CoOrmK4O
Martin Heaps writes:
>web address for accessing the E&Y assessment:
>https://cert.webtrust.org/SealFile?seal=2168&file=pdf and that access this
>address gives a
>
>> Secured Connection Failure: SSL_ERROR_UNSAFE_NEGOTIATION
>
>status. This (webtrust) organisation which seems to run the role of
>ce
Kirk Hall via dev-security-policy
writes:
>To remedy this, Entrust Datacard surveyed all of its TLS/SSL web server
>certificate customers
And what a marvellously disingenous "survey" it is too, artfully constructed
to produce exactly the result the CA's marketing department wants. Mixed in
wit
Ronald Crane via dev-security-policy
writes:
>"Virtually impossible"? "Anyone"? Really? Those are big claims that need real
>data.
How many references to research papers would you like? Would a dozen do, or
do you want two dozen?
(This has been researched to death, it's not rocket science, gi
Paul Walsh writes:
>I would like to see one research paper published by one browser vendor to
>show that website identity visual indicators can not work.
Uhhh... are you serious with that request? You're asking for a study from a
browser vendor, a group who in any case don't publish research p
Ronald Crane via dev-security-policy
writes:
>Please cite the best study you know about on this topic (BTW, I am *not*
>snidely
>implying that there isn't one).
Sure, gimme a day or two since I'm away at the moment.
Alternatively, there's been such a vast amount of work done on this that a f
Paul Walsh via dev-security-policy
writes:
>The data suggests that automatically issued DV certs for free is a favorite
>for criminals.
True, but that one's just an instance of Sutton's Law, they go for those
because they're the least effort. I was at a talk yesterday by a pen-tester
who talke
Paul Walsh via dev-security-policy
writes:
>I have no evidence to prove what I’m about to say, but I *suspect* that the
>people at BSI specified “EV” over the use of other terms because of the
>consumer-visible UI associated with EV (I might be wrong).
Except that, just like your claims about M
1 - 100 of 212 matches
Mail list logo
