On Thursday, June 1, 2017 at 8:03:33 AM UTC-5, Gervase Markham wrote:
>
> My point is not that we are entirely indifferent to such problems, but
> that perhaps the category of "mis-issuance" is the wrong one for such
> errors. I guess it depends what we mean by "mis-issuance" - which is the
> ent
Hi all,
I thought it prudent in light of the recent response from Symantec regarding
the Google Chrome proposal for remediation to raise the question of the
possible remedies the community and the root programs have against a CA
behaving badly (mis-issuances, etc.)
Symantec makes a number of c
I broadly echo many of the comments and thoughts of Martin Heaps earlier in
this thread.
Much of Symantec's response is disheartening, especially in the "inaccuracies":
(the apparent dichotomy between how they have acted and their statement that
they only employ the best people implementing bes
On Tuesday, June 6, 2017 at 9:03:29 AM UTC-5, Gervase Markham wrote:
> I'm slightly surprised to see no engagement here. Perhaps it would be
> help to break it down. Symantec's specific requests for modification are
> as follows (my interpretation):
>
> 1) Scope of Distrust
>
> Google proposal:
On Tuesday, June 6, 2017 at 4:14:00 AM UTC-5, Gervase Markham wrote:
> On 05/06/17 14:29, Alex Gaynor wrote:
> > As I've expressed before, I find it baffling that this still happens.
>
> I am also disappointed. I have half a mind to keep track of how often
> this happens per CA, and impose a manda
On Monday, June 5, 2017 at 11:17:17 AM UTC-5, Ryan Sleevi wrote:
> While on paper the idea sounds quite good, it turns out to simply trade
> technical complexity for complexity of the non-technical sort. As such,
> it's best to focus on meaningful and actionable technical solutions.
Ryan,
I grea
On Wednesday, June 7, 2017 at 6:45:25 PM UTC-5, Jonathan Rudenberg wrote:
> Yet another batch of undisclosed intermediates has shown up in CT:
>
> -
> https://crt.sh/?sha256=f01c1aca392882af152e9f01ecccd0afddd8aa35bf895b003198b1e8c752ddb8
> -
> https://crt.sh/?sha256=29d8ac29f9007a6ad7923fdade3
On Thursday, June 8, 2017 at 7:44:08 PM UTC-5, Ben Wilson wrote:
> I don't believe that disclosure of root certificates is the responsibility
> of a CA that has cross-certified a key. For instance, the CCADB interface
> talks in terms of "Intermediate CAs". Root CAs are the responsibility of
> br
For these self-signed roots which have a certificate subject and key which
match to a different certificate which is in a trusted path (like an
intermediate to a trusted root), the concern is that the mere existence of the
certificate speaks to a signature produced by a private key which DOES ha
On Friday, June 9, 2017 at 11:52:53 AM UTC-5, Ryan Sleevi wrote:
> So that would be an arguement for disclosing both self-signed and
> self-issued certificates, and align with the "Disclose what the key does"
> mentality.
That was essentially the point I was trying to make. Of all the things to
I wonder if the device intercepts DNS queries within the LAN for that address
and substitutes in the IP of the appliance instead of 127.0.0.1. Is it often
deployed as the customer premise NAT/router in addition to serving video
purposes?
I'm thinking they probably wanted some other devices or
On Monday, June 19, 2017 at 11:40:22 PM UTC-5, Tom Ritter wrote:
> So at what point does the CA become culpable to misissuance in a case
> like this? Is it okay that we let them turn a blind eye to issuing or
> reissuing certificates where they have a strong reason to believe the
> private key will
On Tuesday, June 20, 2017 at 2:15:57 PM UTC-5, annie nguyen wrote:
> Dropbox, GitHub, Spotify and Discord (among others) have done the same
> thing for years: they embed SSL certificates and private keys into their
> applications so that, for example, open.spotify.com can talk to a local
> instanc
On Wednesday, June 21, 2017 at 1:43:18 AM UTC-5, jacob.hoff...@gmail.com wrote:
> > It's been an on-going question for me, since the use case (as a software
> > developer) is quite real: if you serve a site over HTTPS and it needs to
> > communicate with a local client application then you need thi
On Wednesday, June 21, 2017 at 4:59:01 AM UTC-5, Ryan Sleevi wrote:
>
> There are several distinct issues:
> 127.0.0.0/8 (and the associated IPv6 reservations ::1/128)
> "localhost" (as a single host)
> "localhost" (as a TLD)
>
> The issues with localhost are (briefly) caught in
> https://tools.
Hi all,
I'm sure questions of certificates leaked to the public via GitHub and other
file sharing / code sharing / deployment repository hosting and sharing sites
have come up before, but last night I spent a couple of hours constructing
various search criteria which I don't think were even esp
On Wednesday, June 21, 2017 at 12:41:53 PM UTC-5, andre...@gmail.com wrote:
> I feel like this is getting sort of off-topic. Web pages can communicate
> directly with applications on the local machine regardless of whether they
> abuse certificates in this way or not. (Such as, for example, by u
Hi all,
I was just reading through the baseline requirements -- specifically 3.2.2.4
and its children -- and noted that while there are particular standards as to
the blessed methods of validation of authority & control for domain names (and
host names within domain names), there is nothing spe
> Yes, however I don't think Matthew's concern was about systems owned by the
> CA but rather systems proximate to them in the network. For example if the CA
> purchases Internet service from a single local Internet Service Provider, the
> BRs obviously don't require that this ISP have all the s
On Thursday, July 20, 2017 at 9:39:40 AM UTC-5, Gervase Markham wrote:
> Your point, in the abstract, is a reasonable one, but so is your further
> point about trade-offs. The only way we can really make progress is for
> you to propose specific changes to the language, and we can then discuss
> t
One (Hypothetical) Concrete Example of a Practical DNS Validation Attack:
(Author's note: I've chosen for this example to utilize the Let's Encrypt CA
as the Certificate Authority involved and I have chosen as a target for
improper validation the domain eff.org. Neither of these is in any way
On Thursday, July 20, 2017 at 8:13:23 PM UTC-5, Nick Lamb wrote:
> 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
> > fai
On Thursday, July 20, 2017 at 3:32:29 PM UTC-5, Ryan Sleevi wrote:
> Broadly, yes, but there's unfortunately a shade of IP issues that make it
> more difficult to contribute as directly as Gerv proposed. Gerv may accept
> any changes to the Mozilla side, but if the goal is to modify the Baseline
>
It seems that a group of Princeton researchers just presented a live
theoretical* misissuance by Let's Encrypt.
They did a sub-prefix hijack via a technique other than those I described here
and achieved issuance while passing-through traffic for other destination
within the IP space of the hij
On Monday, July 24, 2017 at 2:49:20 AM UTC-5, Gervase Markham wrote:
> On 20/07/17 21:31, Ryan Sleevi wrote:
> > Broadly, yes, but there's unfortunately a shade of IP issues that make it
> > more difficult to contribute as directly as Gerv proposed. Gerv may accept
> > any changes to the Mozilla si
On Tuesday, July 25, 2017 at 1:00:39 PM UTC-5, birg...@princeton.edu wrote:
> We have been considering research in this direction. PEERING controls several
> ASNs and may let us use them more liberally with some convincing. We also
> have the ASN from Princeton that could be used with cooperation
It is what it is, I'm sure, but that definition in RFC5280 is rather tortured
and leads to ambiguity as to whether or not the leading 0x00 is. In fact, I
would say that it is not part of the integer value but rather an explicit sign
flag required by the encoding mechanism.
Wouldn't it have bee
To play the devil's advocate...
If everything is as Mr. Leroy of Certinomis points out, I don't see the problem
with the cross-sign.
In that version of events, the vast majority of the issues in the new PKI (test
certs, etc) had already been revoked and measures put in place to prevent that
so
> Do we really want the CA community to be filled with bureaucratic
> enforcement of harsh punishments for every slight misstep? This is the
> important question that any organization (in this case this community)
> needs to ask itself whenever new surveillance abilities make it possible
> to cat
On Monday, August 7, 2017 at 5:20:13 PM UTC-5, Ryan Sleevi wrote:
> This is entirely unnecessary and would present serious stability issues due
> to backwards compatibility.
>
> It may not be appropriate for this thread - discussing specific misissuances
> - but there is zero benefit from exten
It seems this thread has diverged a bit from its stated purpose, the
determination of the question of mis-issuance of a set of certificates which
have (possibly) longer than allowed serial numbers.
I raised a question as to the history of the selection of the 20 bytes limit
for serial numbers a
I don't know whether it was noticed or if it matters to anyone, but I did note
that for at least one of these certificates, particularly the one at
https://crt.sh/?id=92235996 , that the sole SAN dnsName for the certificate is
ev-expired.identrustssl.com.
The cert also had a whopping 24 hours o
Similarly, the cert at https://crt.sh/?id=92235998 has SAN dnsName of
ev-valid.identrustssl.com
It has a normal 2 year validity period.
Which again sounds like a certificate administratively created to serve as a
test point certificate for the root programs.
Didn't someone recently float the argument that the native u-label was required
by local regulation / custom (in China) to be included and so they stuffed it
into the CN?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https:/
On Thursday, August 10, 2017 at 11:27:53 AM UTC-5, Nick Lamb wrote:
> The truth is that there is no positive test for randomness, any work in this
> area is going to end up needing a judgement call, so I think inconveniencing
> the CAs even a small amount with such a policy change just to make a
I see both sides on this matter.
On the one hand, certlint/cablint catches lots of obvious problems, mostly with
ridiculous certificate profiles or manual special purpose issuances.
Certainly, there's a lot of bad issuance that having it in the blocking path
might help with...
but...
If one
Just from the posted serial numbers, it looks almost like the high order bits
may represent 32 bits of random, which is still far short of the requirement.
Perhaps they intended a 48 bit sequential counter after a 32 bit random, or
intended a 64 bit random followed by a 16 bit sequential counter
I concur in full with Nick Lamb's comments and positions on this matter.
There is no reasonable short cut to actually doing the DNSSEC thing if we want
to usefully intertwine those technologies at all.
There IS significant benefit in enforcing complete DNSSEC validation for (all)
the domain val
On Tuesday, September 12, 2017 at 5:36:56 AM UTC-5, Gervase Markham wrote:
>
> As the drafter of the section :-), my intent was to make it so that if a
> site owner were concerned about the possibility that their CAA record or
> DNS could be spoofed, they could use DNSSEC to solve the problem. I
On Tuesday, September 19, 2017 at 8:02:36 AM UTC-5, Gervase Markham wrote:
> I'd be interested in your engagement on my brief threat modelling; it
> seems to me that DNSSEC only adds value in the scenario where an
> attacker has some control of CA Foo's issuance process, but not enough
> to overri
On Tuesday, September 19, 2017 at 10:37:20 AM UTC-5, Gervase Markham wrote:
> On 19/09/17 14:58, Nick Lamb wrote:
> > An attacker only has to _prefer_ one particular CA for any reason,
>
>
> Yep, fair.
>
> Gerv
Quite true. In the example scenario that I have just posted, such preference
might
On Tuesday, September 19, 2017 at 10:13:26 AM UTC-5, Gervase Markham wrote:
> >From the above, we see that Visa only issues certificates to their own
> customers/clients, and not to the public. They believe that this permits
> them to keep confidential details of the certificates which they wish t
Has there been any serious discussion of the potential benefit of CAA reporting
for certificate issuance attempts?
I'm aware of what the spec says and the SHOULD language, etc...
I'm not a CA and don't represent one.
I do, however, think that it's easier to get buy-in for changes to CA
infrast
On Wednesday, September 27, 2017 at 11:56:27 AM UTC-5, Kathleen Wilson wrote:
> What action items do you all think PROCERT should complete before they can be
> re-included in Mozilla's root store?
> What do you think should happen if PROCERT completes those action items
> before their PSCProcer
On Thu, Sep 28, 2017 at 11:50 AM, Gervase Markham wrote:
>
> The nature of trust is that it's harder to regain than it is to gain in
> the first place. Just ask someone who's been the victim of adultery - or
> someone who is a now-repentant adulterer. Rightly or wrongly, people get
> a first chan
On Monday, October 9, 2017 at 8:33:39 AM UTC-7, Nick Lamb wrote:
> One nice thing about the current situation is that CAs are permitted (though
> not obliged) to arrange robustness against technical failure.
>
> If the only official way to contact Honest Achmed's CA is to email
> achmed@honestc
This is an interesting one.
The same researchers also published some spooky research last year in which
they're able to fingerprint an RSA public key and determine the probability
that a given library or device generated the key pair.
Which is scary. If they're able to reliably fingerprint tha
The authors of the paper on the weak RSA keys generated by Infineon TPMs and
smart cards have published code in multiple languages / platforms that provide
for an efficient test for weakness by way of the Infineon TPM bug.
Perhaps this should be a category of issue identified by the crt.sh engin
On Wednesday, October 18, 2017 at 4:15:03 AM UTC-5, Rob Stradling wrote:
> The list is at https://misissued.com/batch/28/
>
> Many of these are Qualified/EUTL certs rather than anything to do with
> the WebPKI. Only about half of them chain to roots that are trusted by NSS.
>
It's really inte
I can not help but notice that the host names of the certificates involved
rather strongly suggest that a series of device or embedded server is creating
these CSRs / utilizing these certificates.
As you mentioned, some users subsequently requested certs for the same keys
already previously uti
Hi,
I touched on my thoughts on this matter a bit before.
This is really about trust.
I think several factors must be weighed here:
1. Is "trust" really required of a CA in a soon-to-be
post-mandatory-CT-log world?
If some level of trust is required, then:
2. Can we say that the QiHoo 360 /
I think Ryan's commentary reflects, again, that the discussion here seems
to be about trust.
In that spirit, I put forth some questions of hypotheticals to provoke
further contemplation and discussion:
1. Presume that QiHoo 360 / WoTrus / WoTrust / StartCom actually purchased
one of the small bu
On Wed, Nov 22, 2017 at 12:00 PM, Ryan Sleevi wrote:
>
> Given that WoSign's CP/CPS itself was met by standard boilerplate, I would
> pose that it is insufficient - the past behaviour as a predictor of future
> behaviour means that the existing documentation approaches are insufficient
> to make
In defense of WoSign/WoTrus/StartCom's parent company, QiHoo 360...
While I don't personally attach a great value to the ethics of the owning
entity of the CA/proposed CA, for those who do or would attach such
importance, I would like to point out that the various vulnerabilities and
security rese
On Wed, Nov 22, 2017 at 3:34 PM, Nick Lamb via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> I don't see any reason why we would want to take that risk.
>
> It's not easy to spin up a new CA, but it's also not rocket surgery.
> Why should we prefer to re-admit a previousl
On Friday, November 24, 2017 at 6:07:44 AM UTC-6, Gervase Markham wrote:
> While I do not want to make this discussion entirely about specific
> people, as Mozilla's investigator of the issues at the time I am
> satisfied that WoSign's actions at the time were taken with full
> knowledge - that is
On Friday, November 24, 2017 at 5:36:20 PM UTC-6, Tom wrote:
> For information, WoSign/WoTrus can already sells WoSign-branded EV
> certificates accepted by major trusts stores, Mozilla's included.
>
> The intermediate certificate "WoSign EV SSL Pro CA" (
> https://crt.sh/?id=146206939 ) is sig
The position that WoTrus (and apparently QiHoo 360) take(s) here does seem
to clarify a matter involving the reinclusion.
It sounds like they are insisting that Richard Wang would be part of the
plan and would, in fact, retain a position of material control and
responsibility in the post-reinclusi
On Mon, Nov 27, 2017 at 3:07 PM, adisor19--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> After seeing the forced shutdown of StartCom, I see no reason to allow
> them back in. Richard Wang is back in his role as CEO and everything is
> back to square one except all
The (I believe) meritorious point that Mr. Hollebeek raises mainly pertains
to embedded devices.
As the IoT craze heats up, I keep seeing platforms ship with unfinished OS
stacks, missing drivers, etc. A lot of hardware in the field is shipping
with decent dedicated entropy sources on board coupl
That's not clear at all.
Someone other than the famous Stripe, Inc. has -- without violating BR
rules or requirements -- a proper EV certificate showing (correctly) entity
name Stripe, Inc.
That this exists suggests that EV is harmful if the target is normal
everyday people. Making the abstract
(Reposting as I accidentally replied directly to OP ).
Part of this discussion will necessarily have to include who the intended
and potential beneficiaries of EV certificate status are:
1. Is it the common web end user? If so, EV either needs to go or be
massively changed.
2. Is it for the ki
On Mon, Dec 11, 2017 at 1:37 PM, Ryan Sleevi wrote:
>
>
> On Mon, Dec 11, 2017 at 2:31 PM, Matthew Hardeman via dev-security-policy
> wrote:
>
>> (Reposting as I accidentally replied directly to OP ).
>>
>> Part of this discussion will necessarily have t
The question that I have is whether the community might consider it
in-scope to discuss enhancements (even fixes) to EV to arrive at assurance
commensurate to its handling.
Matt Hardeman
On Mon, Dec 11, 2017 at 2:09 PM, Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org>
roken web security frameworks of the past. Now that both me and Ian
> have demonstrated the fundamental issues with EV and the way its displayed
> in the UI, it's only time until the REAL phishing starts with EV.
>
> James
>
> On Mon, Dec 11, 2017 at 8:29 PM, Matthew Hardeman
- If the fundamental certificate does deserve the UI treatment, then
> demonstrate why it does. You seem to be in agreement that the present form
> of legal identity is insufficient for the presumed use case, so I'm hoping
> you can close the gap in my understanding on why something is
> simultaneo
On Mon, Dec 11, 2017 at 2:53 PM, Ryan Sleevi wrote:
>
>
> It feels like, to some extent, this is a question about whether we should
> point out the Emperor has no clothes if we don't have clothes to offer him.
> It'd be great if they was wearing some, I agree - the Emperor does need
> clothes. But
While I understand that it may formally be beyond the scope formally to
consider this in discussion with EV UI handling, I think some consideration
to ecosystem harm is appropriate here.
If we eliminate EV UI, we have reduced the scope of WebPKI to domain
validated certificates (in any pragmatic s
On Mon, Dec 11, 2017 at 5:03 PM, Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Monday, December 11, 2017 at 5:47:50 PM UTC-5, Matthew Hardeman wrote:
> > While I understand that it may formally be beyond the scope formally to
> > consider this in discussi
What I dislike about this particular rationale is that I presupposes we
should architect web security such as to avoid enhancements which have
value to anyone the least common denominator.
Is the average user (actually, the bottom rung of the concentration of
values around the average, I suppose)
On Monday, December 11, 2017 at 5:00:14 PM UTC-6, Ryan Sleevi wrote:
> > That Kentucky registration for Stripe, Inc. -- Is it completely fraudulent
> > as to registered agent, business address, etc? If it's not, then the
> > certificate and underlying entity serve as an archived investigative ent
On Monday, December 11, 2017 at 5:37:34 PM UTC-6, Ryan Sleevi wrote:
> Yes.
>
> If something is not valuable for billions of users, if it is not
> trustworthy for billions of users, it should not occupy the cognitive or
> visual model billions of users rely on.
>
Perish the thought that a UI el
In principle, I support Mr. Sleevi's position, practically I lean toward
Mr. Thayer's and Mr. Hollebeek's position.
Sitting on my desk are not less than 3 reference designs. At least two of
them have decent hardware RNG capabilities. What's noteworthy is the
garbage software stack, kernel suppor
> I appreciate your reply, but that seems to be backwards looking rather than
> forwards looking. That is, it looks and assumes static-RSA ciphersuites are
> acceptable, and thus the entropy risk to TLS is mitigated by client-random
> to this terrible TLS-server devices, and the issue to mitigate i
> As an unrelated but funny aside, I once heard about a expensive, high
> assurance device with a embedded bi-stable circuit for producing high quality
> hardware random numbers. As part of a rigorous validation and review process
> in order to guarantee product quality, the instability was no
On Wednesday, December 13, 2017 at 12:50:38 PM UTC-6, Ryan Sleevi wrote:
> On Wed, Dec 13, 2017 at 1:24 PM, Matthew Hardeman
> wrote:
>
> > As I pointed out, it can be demonstrated that quality ECDHE exchanges can
> > happen assuming a stateful DPRNG with a decent starting entropy corpus.
> >
>
On Monday, December 11, 2017 at 6:01:25 PM UTC-6, Ryan Sleevi wrote:
> > Not really - what matters is that the user insists they got had via a
> > phishing link or other process - that can certainly be verified after the
> > fact
>
>
> No.
Why's that? This is how investigations begin.
>
> -
On Wednesday, December 13, 2017 at 2:46:10 PM UTC-6, Gervase Markham wrote:
> My concern with this argument is that it's susceptible to the criticism
> that Adam Langley made of revocation checking:
> https://www.imperialviolet.org/2012/02/05/crlsets.html
>
> "So [EV identity is] like a seat-belt
On Tuesday, December 12, 2017 at 3:52:40 PM UTC-6, Ryan Sleevi wrote:
> Yes. This is the foundation and limit of Web Security.
>
> https://en.wikipedia.org/wiki/Same-origin_policy
>
> This is what is programatically enforced. Anything else either requires new
> technology to technically enforce
On Wednesday, December 13, 2017 at 3:42:38 PM UTC-6, Ryan Sleevi wrote:
> > Would Ian have requested a certificate for Stripe, Inc. if his full name
> > were also in that certificate? Maybe, maybe not. But anyone investigating
> > that certificate would need do no extra work to know what individ
On Wednesday, December 13, 2017 at 5:08:05 PM UTC-6, Matt Palmer wrote:
> > There is a "curatorship", if you will, engaged by the site author. If
> > there are sub-resources loaded in, whether they are EV or not, it is the
> > root page author's place to "take responsibility" for the contents of
On Wednesday, December 13, 2017 at 5:52:16 PM UTC-6, Peter Gutmann wrote:
> >Sitting on my desk are not less than 3 reference designs. At least two of
> >them have decent hardware RNG capabilities.
>
> My code runs on a lot (and I mean a *lot*) of embedded, virtually none of
> which has hardwa
On Wednesday, December 13, 2017 at 11:09:44 PM UTC-6, Matt Palmer wrote:
>
> Before that, though, a quick word from our sponsor, Elephant-Be-Gone Amulets
> of America, Inc. No elephants in America, you say? See, they're 100%
> effective! Get yours today!
Of relevance on this point, I'm quite
All,
Recent events and a body of historical research have of late been causing
questions among a great many respected security researchers and browser UI
guys about the benefits of browser UI signal for EV certificates.
I'd like to start a discussion tangent to that ongoing dialogue.
Regardless o
On Wednesday, December 13, 2017 at 2:46:10 PM UTC-6, Gervase Markham wrote:
> My concern with this argument is that it's susceptible to the criticism
> that Adam Langley made of revocation checking:
> https://www.imperialviolet.org/2012/02/05/crlsets.html
>
> "So [EV identity is] like a seat-belt
On Thursday, December 14, 2017 at 5:50:40 PM UTC-6, Matthew Hardeman wrote:
> Route hijacking your way to what would appear as a proper domain validation
> is practical for even a modestly resourceful adversary. I suspect that the
> only reason more spectacular demonstration of certs issuing pu
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 not even need that - they could just hijack traffic
headed to the IP address of the real DNS server in question.
Has anyone started looking into CA issuances -- or even more importantly -- CA
domain validations performed successfully and yet without issuing a certificate
(say, wanting to cache the validation) for the brief periods in which much of
the internet saw alternative target destinations for a grea
re requests in the future (where we would
> require responses within a certain time period.)
>
> -tom
>
> On 14 December 2017 at 22:16, Matthew Hardeman via dev-security-policy
> wrote:
> > Has anyone started looking into CA issuances -- or even more importantly
> -- CA domain
On Friday, December 15, 2017 at 8:08:44 AM UTC-6, Ryan Sleevi wrote:
> James’ research has showed the ease at which it is possible to use the UI
> afforded EV to mislead users - fundamentally, a form of phishing,
> exploiting the misunderstanding about what EV is it guarantees.
>
> Ian’s research
On Friday, December 15, 2017 at 1:50:38 PM UTC-6, Ryan Sleevi wrote:
> I'm not sure I made those statements, but would be happy to clarify the
> confusion. Indeed, as I tried to call out, there are a subset of users who
> are looking at it and relying on it - although it cannot be relied upon -
>
On Friday, December 15, 2017 at 3:08:32 PM UTC-6, Ryan Sleevi wrote:
> Respectfully, this is the tiger-repelling rock. We can't show that any
> tigers attacked, therefore, we should keep telling users they need
> tiger-repelling rocks. And oh, by the way, they take away attention from
> solutions
On Friday, December 15, 2017 at 3:21:54 PM UTC-6, Ryan Hurst wrote:
> Unfortunately, the PKCS#12 format, as supported by UAs and Operating Systems
> is not a great candidate for the role of carrying keys anymore. You can see
> my blog post on this topic here: http://unmitigatedrisk.com/?p=543
>
201 - 293 of 293 matches
Mail list logo
