Re: On the value of EV

[Jakob Bohm via dev-security-policy]

On 15/12/2017 02:30, Ryan Sleevi wrote:

On Thu, Dec 14, 2017 at 5:01 PM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


On 14/12/2017 00:23, Peter Gutmann wrote:

Tim Shirley via dev-security-policy <

dev-security-policy@lists.mozilla.org> writes:



But regardless of which (or neither) is true, the very fact that EV

certs are

rarely (never?) used on phishing sites


There's no need:



https://info.phishlabs.com/blog/quarter-phishing-attacks-hosted-https-domains


In particular, "the rate at which phishing sites are hosted on HTTPS

pages is

rising significantly faster than overall HTTPS adoption".



But how many of those are on *EV-certified https URLs* is the question
raised here.



No, it isn’t.

In particular, some participants insist there are many of those, but

have yet to post even a single concrete example, let alone statistics of
how many such examples exist.



Could you point to such an example where a participant insisted that? Or is
that merely a straw man argument used to advance a logically flawed
position?

Some participants have pointed out correlation is not causation - that you
can’t infer that never being attacked by a tiger while you’re holding a
particular rock means that the rock repels tigers, anymore than EV UI
prevents phishing.



YOU in particularly have kept insisting that it is a "myth" that
phishing sites don't use EV certificates, yet keep pointing to articles
about non-EV failures.

Now you rephrase it as "the EV UI versus phishing", dodging the
question.


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: On the value of EV

[Ryan Sleevi via dev-security-policy]

On Thu, Dec 14, 2017 at 5:01 PM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 14/12/2017 00:23, Peter Gutmann wrote:
> > Tim Shirley via dev-security-policy <
> dev-security-policy@lists.mozilla.org> writes:
> >
> >> But regardless of which (or neither) is true, the very fact that EV
> certs are
> >> rarely (never?) used on phishing sites
> >
> > There's no need:
> >
> >
> https://info.phishlabs.com/blog/quarter-phishing-attacks-hosted-https-domains
> >
> > In particular, "the rate at which phishing sites are hosted on HTTPS
> pages is
> > rising significantly faster than overall HTTPS adoption".
> >
>
> But how many of those are on *EV-certified https URLs* is the question
> raised here.


No, it isn’t.

In particular, some participants insist there are many of those, but
> have yet to post even a single concrete example, let alone statistics of
> how many such examples exist.


Could you point to such an example where a participant insisted that? Or is
that merely a straw man argument used to advance a logically flawed
position?

Some participants have pointed out correlation is not causation - that you
can’t infer that never being attacked by a tiger while you’re holding a
particular rock means that the rock repels tigers, anymore than EV UI
prevents phishing.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: On the value of EV

[Matthew Hardeman via dev-security-policy]

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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: On the value of EV

[Matthew Hardeman via dev-security-policy]

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 pursuant to such 
> hijacks haven't arisen owes to ethical considerations, poor overlap of those 
> with the network interconnection experience and the CA DV practices 
> knowledge, and that doing it effectively means doing it in a well documented 
> way -- ringing a bell you can not unring.

So when I wrote the above, I had not yet seen this (just published):

https://twitter.com/matthew_d_green/status/941460537724080128

I have lots of ideas on how to help make DV more resilient against this, though 
they have various costs of complexity, infrastructure, and time.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: On the value of EV

[Matthew Hardeman via dev-security-policy]

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 that snaps when you crash. Even
> though it works 99% of the time, it's worthless because it only works
> when you don't need it."

I would like to point out that this is true of certificates in general.  It is 
also true of DV certificates.  It is also true of the DV validation processes.

The same criticism can be applied to any mechanism which has a non-zero 
potential for elevating the user's expectation and confidence to any level 
above "anyone can see this, anyone can manipulate this."

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 pursuant to such hijacks 
haven't arisen owes to ethical considerations, poor overlap of those with the 
network interconnection experience and the CA DV practices knowledge, and that 
doing it effectively means doing it in a well documented way -- ringing a bell 
you can not unring.

The same targets worth hijacking and getting fraudulent DV certificates for are 
those same sites that can derive benefit from strong identity validation and 
enhanced indication that you're talking to infrastructure of the party that 
underwent that.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: On the value of EV

[Jakob Bohm via dev-security-policy]

On 14/12/2017 00:23, Peter Gutmann wrote:

Tim Shirley via dev-security-policy  
writes:


But regardless of which (or neither) is true, the very fact that EV certs are
rarely (never?) used on phishing sites


There's no need:

https://info.phishlabs.com/blog/quarter-phishing-attacks-hosted-https-domains

In particular, "the rate at which phishing sites are hosted on HTTPS pages is
rising significantly faster than overall HTTPS adoption".



But how many of those are on *EV-certified https URLs* is the question
raised here.

In particular, some participants insist there are many of those, but
have yet to post even a single concrete example, let alone statistics of
how many such examples exist.


It's like SPF and site security seals, adoption by spammers and crooks was
ahead of adoption by legit users because the bad guys have more need of a
signalling mechanism like that than anyone else.

Peter.




Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: On the value of EV

[Jakob Bohm via dev-security-policy]

On 13/12/2017 22:40, Matthew Hardeman wrote:

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 it (such as a new scheme), or is
offloading the liability to the user.



The notion that a sub-resource load of a non-EV sort should downgrade the EV 
display status of the page is very questionable.

I'm not sure we need namespace separation for EV versus non-EV subresouces.

The cause for this is simple:

It is the main page resource at the root of the document which causes each 
sub-resource to be loaded.

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 the DV or EV validated sub-resources that they 
cause to be loaded.

Frankly, I reduce third party origin resources to zero on web applications on 
systems I design where those systems have strong security implications.

Of course, that strategy is probably not likely to be popular at Google, which 
is, in a quite high percentage of instances, the target origin of all kinds of 
sub-resources loaded in pages across the web.

If anyone takes the following comment seriously, this probably spawns an 
entirely separate conversation: I regard an EV certificate as more of a 
code-signing of a given webpage / website and of the sub-resources whether or 
not same origin, as they descend from the root page load.



For clarity, I was not referring to the subresource problem.  Only to
the following simpler but important cases:

1. Mid-event change of certificate for *the same* address (DNS name)
  to a certificate that has any non-trivial differences from the
  certificate used by the browser to render its address bar indicator.
   This should be seen as a security-relevant connection failure and
  cause the browser to stop before sending any request under that
  weaker certificate.  False alarms would normally only happen during
  a certificate rollover or with inconsistently configured server farms.

2. POST (not GET) to a different address than the page address, where
  that other address does not present an equally-strong or stronger
  certificate naming the same entity.
   This should result in security warnings similar to posting to a
  http address.

Similar protections could be added (with less urgency) for switching to
a less secure encryption algorithm (based on the Browser's
classification of what is stronger/weaker/equivalent/incomparable).



Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: On the value of EV

[Jakob Bohm via dev-security-policy]

On 13/12/2017 20:55, Gervase Markham wrote:

On 11/12/17 17:00, Ryan Sleevi wrote:

Fundamentally, I think this is misleading. It presumes that, upon
something bad happening, someone can link it back to that certificate
to link it back to that identity. If I was phished, and entered my
credentials, there's no reason to believe I've maintained the record
details including the phishing link to know I was phished. Are users
supposed to spleunk their HTTP cache or maintain complete archives of
every link they visited, such that they can get the cert back from it
to aid an investigation?


This is something that has always worried me about the EV value
proposition. Even if it worked perfectly, once one has realised one has
been scammed, one would want to find the cert again to know where to
serve the lawsuit papers or send the police. Unless your browser caches
all EV certs for sites you've ever visited in the past month, and
provides some UI for querying that cache, then that's not necessarily
going to be possible. So having the info about the site owner in the
cert isn't actually useful.

CT does address this to a degree, but only to a degree.



In the case of non-phishing frauds, the EV cert and the display of the
company name in the address bar matching the company name on payment
documents (receipts, off-site credit card clearing services etc.) would
serve to verify to the user that the company to sue is the one they
thought they were dealing with, thus reducing this down to the
traditional situation of the victim knowing a-priori who is at fault.

It's the scenario of the user ordering a book from LittleExampleBookshop
(with a green address bar saying "Little Example Books Inc (Virginia,
US)"), but getting a much less valuable book, then wanting to prosecute
Little Example Bookshop for not fulfilling the purchase contract.  No
offense meant to any real world bookshop.

Phishing frauds are a different matter, as there it is a matter of
having enough signals that the scammer is not whom they claim to be,
despite lots of flashy claims to the contrary.



Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: On the value of EV

[Jakob Bohm via dev-security-policy]

On 14/12/2017 17:51, Peter Bachman wrote:

@Jakob I was referring to the classical namespaces which have evolved since the 
1980s. The NSF pilot project was based on a now obsolete version of X.500, 
Quipu,  that world rooted with participating county directories. While I 
managed that part of the capital D Directory it was in the context of c=US. It 
was at that point we modified the EDB of the pilot project to include 
certificates so that the nuclear labs could use low cost Internet mail to 
collabrate with other organizations to decrease the number of weapons under the 
negotiated treaties.



So do you mean the "Distinguishe Name" namespace, or not?


During that time the labs went through the process of also proposing and 
adopting the domain component approach.

Still it was possible as an internet user to download a certificate from a part 
of c=US that was part of that directory tree.

Since the certificate is a viable stand alone ASN1 object then it actually does 
not entirely matter where one obtains the certificate, (but with some caveats 
as to the original design) which relates to semiotics and the general nature of 
what is considered authoritative or even useful in the post dot com world.

For example, when those of us in the US represent ourselves to people that are 
not in the US. I can look at the certificate that is pushed to a user (and of 
course no longer trusted) and say, hmm based on my knowledge of Google, and 
geography, and business, they are not located in Boca Raton.



What certificate is that?

Do you mean the TLS server certificate for www.google.com returned when
users access https://www.google.com, and which (as of this moment and
seen from my European location has the Distinguished Name:

  C=US, ST=California, L=Mountain View, O=Google Inc, CN=www.google.com

with a validity period of 3 months, issued by an unconstrained Google-
operated CA cert issued by one of the soon-to-be-distrusted former
Symantec roots).

What do you mean by "and of cause no longer trusted"?


I find the EV helpful as a user, but I know it is masking a deeper problem. And 
I don’t see any of the CA who acknowledge this problem privately as doing the 
right thing based on a tacit realpolitik that ultimately disadvantages the 
Internet user with less than optimal security.

It’s not that the state chancery errors would replicate into an X.500 
environment, on the contrary that is name confusion engineered into DNS to 
profit from user name confusion.

The classic example is whitehouse.com


While this is a known problem, it was originally not engineered to cause
confusion but to allow scoping to deal with the inherent ambiguity of
existing human chosen names.  It was also engineered to clearly and
obviously (to all users at the time) distinguish between commercial,
educational, telecommunications, military government and civilian
government entities.





Registrars offer similar names at a discount bundle price for this reason, it 
is a business model. At the same time they sell certificates. They blind the 
ownership in WHOISbecause frankly one gets horribly spammed when one uses WHOIS 
the way it was intended in the original DDN-NIC version of the 1980s.



As someone who has not blinded our addresses in whois, I strongly resent
such blinding and see it as a sign of likely dishonesty of the domain
holder.  I also find that the resulting amount of e-mail spam (after
minimal filtering) is actually quite tolerable.  The amount of spam
calls to our front desk phone number is worse, but that number is widely
published elsewhere.


So the Internet needs to have a viable trust framework and one already exists 
under c=US, using X.500. which feeds the various trust frameworks that don’t 
entirely trust the Internet.



Can you point directly to where that framework actually exists (like a
URL or an institution that currently operates and maintains it)?


CT is one of those technologies that benefits the Internet directly, but the 
business model is based on these separate organizations which the CA interact 
with, the  selling proposition  to them is that the BR are BS.  You need my 
dear customer a trust framework that uniquely represents you as a member of the 
Carpenters Union so your unique woodworking skills are fairly representated. As 
opposed to anyone who can set up shop as Stripe Carpenters with a business 
registration.



So far, CT has mostly been used as an audit and enforcement mechanism
for detecting and policing BR violations.  So its selling proposition is
clearly not "the BR are BS".

CT has nothing to do with the existence or non-existence of widely
trusted mechanisms for issuing certificates that indicate skills,
professional organization membership or other such non-geographic
hierarchical status.  Such a structure would also not be a good fit for
the Distinguished Name structure that typically resembles a postal
address.



That allows for the enterprise certificates and 

Beyond EV: Thoughts on trust and actionable trust signals

[Matthew Hardeman via dev-security-policy]

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 of any changes in EV certificate handling -- or any lack of
changes, I think it may be worthwhile to have a discussion about the
appropriateness of trust indicators in browser UI and the things that might
support an indication of a trust indicator.

Today, browsers grant an enhanced display to EV certificates because EV
certificates identify the existence of an entity, the authorization of a
certificate requestor to request a certificate on behalf of the entity, and
link the certificate between the domain(s) of the entity and the entity
itself.

In general, it is presumed that this increases the notion that the website
presenting this certificate is trustworthy -- most especially, the
marketing of the EV "brand" suggests to us that these websites are more
trustworthy in terms that we can be confident in engaging in commerce with
these websites.

Recent work by security researches such as Ian Caroll have shown that trust
is likely a bit more complicated.  We can't trust, in the general case,
that "Stripe, Inc." means the Stripe of stripe.com -- the payment
processor.  In fact, Ian's work involved the creation of a separate
"Stripe, Inc." in Kentucky.

I have several questions for the community to ponder:

1.  If a technologically detectable and authenticatable indicator that a
site was "measurably more trustworthy than the general case for the purpose
of engagement in commerce", would that merit a browser UI indicator of some
form?  Specifically a browser initiated UI element, such that the target
website itself could not simulate or emulate the indicator in a compelling
way.

2.  What data or documentation, fully validated, might possibly rise to the
above bar regarding the real world identification and legitimacy of the
operator of the target website?

Certainly, I have my own thoughts and opinions on this topic.  And if
there's interest and traction on those questions by other community
matters, I hope to expound on those in the course of that conversation.

Thanks,

Matt Hardeman
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: On the value of EV

[Peter Bachman via dev-security-policy]

@Ryan

“Since improving it as a technical means is an effective non-starter (e.g. 
introducing a new origin for only EV certs), the only fallback is to the 
cognitive means” 

EV is a convenient signal. I like it. The problem is the infrastructure that 
pits the Internet and it’s protocols with inadequate protection for the end 
user against active adversaries. Whether the false “claim” of security is being 
made contrary to what most security experts would consider a fact (or an I 
wrong?) is a problem not specific to UI, but to one of OWASP threats. Perhaps a 
moral question of fooling Internet users via a higher level of security 
knowledge. In general the  IETF and IAB have already reached consensus that 
internet users and use cases should have the same rights to protection that 
other organizations have. Mozilla acknowledges this by not locating the 
GooglePlex in Boca Raton, Fl.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: On the value of EV

[Peter Bachman via dev-security-policy]

@Jakob I was referring to the classical namespaces which have evolved since the 
1980s. The NSF pilot project was based on a now obsolete version of X.500, 
Quipu,  that world rooted with participating county directories. While I 
managed that part of the capital D Directory it was in the context of c=US. It 
was at that point we modified the EDB of the pilot project to include 
certificates so that the nuclear labs could use low cost Internet mail to 
collabrate with other organizations to decrease the number of weapons under the 
negotiated treaties.

During that time the labs went through the process of also proposing and 
adopting the domain component approach.

Still it was possible as an internet user to download a certificate from a part 
of c=US that was part of that directory tree.

Since the certificate is a viable stand alone ASN1 object then it actually does 
not entirely matter where one obtains the certificate, (but with some caveats 
as to the original design) which relates to semiotics and the general nature of 
what is considered authoritative or even useful in the post dot com world.

For example, when those of us in the US represent ourselves to people that are 
not in the US. I can look at the certificate that is pushed to a user (and of 
course no longer trusted) and say, hmm based on my knowledge of Google, and 
geography, and business, they are not located in Boca Raton.

I find the EV helpful as a user, but I know it is masking a deeper problem. And 
I don’t see any of the CA who acknowledge this problem privately as doing the 
right thing based on a tacit realpolitik that ultimately disadvantages the 
Internet user with less than optimal security.

It’s not that the state chancery errors would replicate into an X.500 
environment, on the contrary that is name confusion engineered into DNS to 
profit from user name confusion.

The classic example is whitehouse.com

Registrars offer similar names at a discount bundle price for this reason, it 
is a business model. At the same time they sell certificates. They blind the 
ownership in WHOISbecause frankly one gets horribly spammed when one uses WHOIS 
the way it was intended in the original DDN-NIC version of the 1980s.

So the Internet needs to have a viable trust framework and one already exists 
under c=US, using X.500. which feeds the various trust frameworks that don’t 
entirely trust the Internet.

CT is one of those technologies that benefits the Internet directly, but the 
business model is based on these separate organizations which the CA interact 
with, the  selling proposition  to them is that the BR are BS.  You need my 
dear customer a trust framework that uniquely represents you as a member of the 
Carpenters Union so your unique woodworking skills are fairly representated. As 
opposed to anyone who can set up shop as Stripe Carpenters with a business 
registration.

That allows for the enterprise certificates and directories as a market, the 
government and military who to some extent use the commercial CA, but also do 
not, and thus gain the advantages of cross certification using X.500 at the 
Federal Bridge between these major siloed trust frameworks.

The DN is inherently unique. The Internet enterprise OID is something else.  If 
geography has anything to do with this, then it’s possible to extend c=US to 
have semantic meaning.

According to the last extant analysis done. The US government can’t solely be 
c=US, that’s a common namespace confusion.

They are at an Organization level. 

However there are two OID paths in that regard.







___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Third party use of OneCRL

[J.C. Jones via dev-security-policy]

Niklas,

That's fine. Thanks for the heads up. Note that the format has a
possibility of changing some in 2018, but only in the way of adding fields,
not changing existing data.

Cheers,

J.C.
Crypto Engineering

On Thu, Dec 14, 2017 at 9:03 AM, niklas.bachmaier--- via
dev-security-policy  wrote:

> We are now ready to use the OneCRL in production. Approximately 2500 hosts
> would be requesting one OneCRL copy per day. Please let me know if this is
> not okay for you.
>
> Thanks a lot
> Niklas
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: On the value of EV

[Tim Hollebeek via dev-security-policy]

Of course, the main reason Comodo gets sucked into this swamp is the 
price point.  That isn't necessarily their fault.

As I've pointed out elsewhere, Comodo has some great ideas about fixing
revocation that would go a long way towards solving the "misbehave only
after issuance" problem that you correctly pointed out.

-Tim

> -Original Message-
> From: Rob Stradling [mailto:rob.stradl...@comodo.com]
> Sent: Thursday, December 14, 2017 6:01 AM
> To: Tim Hollebeek 
> Cc: Peter Gutmann ; Gervase Markham
> ; mozilla-dev-security-pol...@lists.mozilla.org; Tim
> Shirley 
> Subject: Re: On the value of EV
> 
> On 14/12/17 00:25, Tim Hollebeek via dev-security-policy wrote:
> > If you look at where the HTTPS phishing certificates come from, they
> > come almost entirely from Let's Encrypt and Comodo.
> >
> > This is perhaps the best argument in favor of distinguishing between
> > CAs that care about phishing and those that don't.
> 
> Tim,
> 
> We reject certificate requests for sites that are already known to engage
in
> phishing, and we revoke (for all the good that does) certificates for
sites that
> are subsequently discovered to have engaged in phishing.
> 
> IIUC, you're saying that "CAs that care about phishing" are ~100%
successful
> at avoiding issuing certs to phishing sites.  If so, that's great!
Perhaps you
> could help us to become one of the "CAs that care about phishing" by
sharing
> your crystal ball technology with us, so that we too can avoid issuing
certs to
> sites that subsequently engage in phishing?
> 
> --
> Rob Stradling
> Senior Research & Development Scientist
> COMODO - Creating Trust Online



smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: CA generated keys

[Tim Hollebeek via dev-security-policy]

Within 24 hours?  Once the download completes?  It doesn’t seem significantly 
harder than the other questions we grapple with.  I’m sure there are plenty of 
reasonable solutions.

 

If you want to deliver the private key first, before issuance, that’d be fine 
too.  It just means two downloads instead of one and I tend to prefer avoiding 
unnecessary complexity.

 

-Tim

 

From: Wayne Thayer [mailto:wtha...@mozilla.com] 
Sent: Wednesday, December 13, 2017 5:40 PM
To: Tim Hollebeek 
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: CA generated keys

 

On Wed, Dec 13, 2017 at 4:06 PM, Tim Hollebeek via dev-security-policy 
 > wrote:


Wayne,

For TLS/SSL certificates, I think PKCS #12 delivery of the key and certificate
at the same time should be allowed, and I have no problem with a requirement
to delete the key after delivery.

 

How would you define a requirement to discard the private key "after delivery"? 
This seems like a very slippery slope.

 

  I also think server side generation along
the lines of RFC 7030 (EST) section 4.4 should be allowed.  I realize RFC 7030
is about client certificates, but in a world with lots of tiny communicating
devices that interface with people via web browsers, there are lots of highly
resource constrained devices with poor access to randomness out there running
web servers.  And I think we are heading quickly towards that world.
Tightening up the requirements to allow specific, approved mechanisms is fine.
We don't want people doing random things that might not be secure.

Why is it unreasonable in this IoT scenario to require the private key to be 
delivered prior to issuance?



smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: On the value of EV

[Rob Stradling via dev-security-policy]

On 14/12/17 00:25, Tim Hollebeek via dev-security-policy wrote:

If you look at where the HTTPS phishing certificates come from, they come
almost entirely from Let's Encrypt and Comodo.

This is perhaps the best argument in favor of distinguishing between CAs
that care about phishing and those that don't.


Tim,

We reject certificate requests for sites that are already known to 
engage in phishing, and we revoke (for all the good that does) 
certificates for sites that are subsequently discovered to have engaged 
in phishing.


IIUC, you're saying that "CAs that care about phishing" are ~100% 
successful at avoiding issuing certs to phishing sites.  If so, that's 
great!  Perhaps you could help us to become one of the "CAs that care 
about phishing" by sharing your crystal ball technology with us, so that 
we too can avoid issuing certs to sites that subsequently engage in 
phishing?


--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy