Re: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption

[Peter Gutmann via dev-security-policy]

Ryan Sleevi  writes:

>Mozilla updates every six to eight weeks. And that works. That's all that
>matters for this discussion.

Do all the world's CAs know this?

Peter.

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

Re: April CA Communication: Results

[Peter Gutmann via dev-security-policy]

Jakob Bohm via dev-security-policy  
writes:

>Indeed, I strongly suspect Microsoft *customers* combined with Microsoft
>untrustworthiness (they officially closed their Trustworthy Computing
>initiative!) may be the major hold out, specifically:
>
>1. [...]

5. Microsoft has SHA-1 deeply hardcoded into their cert-management
   infrastructure, and in some places it can't be replaced.  For example their
   NDES cert management server replies to a SHA-2 request with a SHA-1
   response that can't be decrypted, implying that it's never even been tested
   with SHA-2.  If you submit an MD5 request then everything works as expected
   (as does SHA-1).
   
   That's MD5, in 2017.

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

Re: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption

[Peter Gutmann via dev-security-policy]

Ryan Sleevi via dev-security-policy  
writes:

>An alternative solution to the ossification that Alex muses about is to
>require that all CAs must generate (new) roots on some interval (e.g. 3
>years) for inclusion. That is, the 'maximum' a root can be included in a
>Mozilla product is 3 years (or less!)

Unless someone has a means of managing frequent updates of the root
infrastructure (and there isn't one, or at least none that work), this will
never fly.  There's a reason why roots have 20-40 year lifetimes and why they
get on-sold endlessly across different owners rather than simply being
replaced when required.

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

Re: CA Validation quality is failing

[Peter Gutmann via dev-security-policy]

Ryan Sleevi  writes:

>For an EV cert, you look in 
>https://cabforum.org/wp-content/uploads/EV-V1_6_1.pdf   

It was meant as a rhetorical question, the OP asked whether doing XYZ in an
EV certificate was allowed and I was pointing out that the CAB Forum 
guidelines should provide the answer.  Vincent Lynch's reply was the appropriate
one, pointing out the text that covers this situation.

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

Re: CA Validation quality is failing

[Peter Gutmann via dev-security-policy]

Kurt Roeckx via dev-security-policy  
writes:

>Both the localityName and stateOrProvinceName are Almere, while the province 
>is Flevoland.

How much checking is a CA expected to do here?  I know that OV and DV certs 
are just "someone at this site responded to email" or whatever, but for an 
EV cert how much further does the CA actually have to go?  When e-Szignó 
Hitelesítés-Szolgáltató in Hungary certifies Autolac Car Services, Av Los 
Frutales 487 urb., Lima, Peru, are they expected to verify that it's really 
in Av Los Frutales and not Los Tolladores, or do they just go ahead and
issue the cert?  Can someone point to the bit of the BR that says that this
is obviously right or wrong?

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

Re: Researcher Says API Flaw Exposed Symantec Certificates, Including Private Keys

[Peter Gutmann via dev-security-policy]

Nick Lamb via dev-security-policy  
writes:

>In order for Symantec to reveal anybody's private keys they'd first need to
>have those keys

That's standard practice for many CAs, they generate the key and certificate
for you and email it to you as a PKCS #12.  It seems to be more common among
lesser-known CAs though, particularly ones with government-mandated monopolies
for some reason, so I'm not sure if Symantec does it.

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

Re: Over 14K 'Let's Encrypt' SSL Certificates Issued To PayPal Phishing Sites

[Peter Gutmann via dev-security-policy]

Martin Heaps via dev-security-policy  
writes:

>This topic is frustrating in that there seems to be a wide attempt by people
>to use one form of authentication (DV TLS) to verify another form of
>authentication (EV TLS).

The overall problem is that browser vendors have decreed that you can't have
encryption unless you have a certificate, i.e. a CA-supplied magic token to
turn the crypto on.  Let's Encrypt was an attempt to kludge around this by
giving everyone one of these magic tokens.  Like a lot of other kludges, it
had negative consequences...

So it's now being actively exploited... how could anyone *not* see this
coming?  How can anyone actually be surprised that this is now happening?  As
the late Bob Jueneman once said on the PKIX list (over a different PKI-related
topic), "it's like watching a train wreck in slow motion, one freeze-frame at
a time".  It's pre-ordained what's going to happen, the most you can do is
artificially delay its arrival.

>The end nessecity is that the general public need to be educated [...]

Quoting Vesselin Bontchev, "if user education was going to work, it would have
worked by now".  And that was a decade ago.

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

Re: [FORGED] Criticism of Mozilla Re: Google Trust Services roots

[Peter Gutmann via dev-security-policy]

Kurrasch via dev-security-policy  writes:

>* Types of transfers:  I don't think the situation was envisioned where a
>single root would be transferred between entities in such a way that company
>names and branding would become intermingled.

This has happened many times in the past, root certs have been sold and re-
sold for years.

>* Manner of transfer:  As we learned from Ryan H., a second HSM was
>introduced for the transfer of the private key meaning that for a period of
>time 2 copies of the private key were in existence.

I would be surprised if only two copies were in existence, given the value of
root keys I'd hope CAs have multiple backup copies.

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

Re: Intermediates Supporting Many EE Certs

[Peter Gutmann via dev-security-policy]

Jakob Bohm via dev-security-policy  
writes:

>Unfortunately, for these not-quite-web-server things (printers, routers
>etc.), automating use of the current ACME Let's encrypt protocol with or
>without hardcoding the Let's Encrypt URL is a non-starter for anyone using
>these things in a more secure network and/or beyond the firmware renewal
>availability from the vendor.

That's one of the least concerns with IoS devices.  For one thing they're
mostly going to have RFC 1918 addresses or non-qualified names, which CAs
aren't supposed to issue certs for (not that that's ever stopped them in the
past).  Then the CA needs to connect back to the device to verify connection
to the domain name it's issuing the cert for, which shouldn't be possible for
any IoS device that's set up properly.  And I'm sure there's more...

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

Re: Taiwan GRCA Root Renewal Request

[Peter Gutmann via dev-security-policy]

Gervase Markham via dev-security-policy  
writes:

>Peter: you are going to have to re-summarise your question. And then, if you
>are asking why Mozilla code works in a certain way, mozilla.dev.security or
>mozilla.dev.tech.crypto are almost certainly far better venues.

Sure, no problem.  I was just replying to a post by Kathleen on this list, and
it seemed like a policy issue so I figured it was the right forum.  I'll CC it
to dev.security as well...

The original post was about the fact the Mozilla runs into lots of problems
with top-down path construction:

>Indeed, and as per your comment here:
>https://bugzilla.mozilla.org/show_bug.cgi?id=1056341#c24

I asked:

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=CoOrmK4OueY

that you work bottom-up, not top-down.  If that's not obvious just from about
a beer's worth of analysis then it should have been when one of said PKI
theoreticians described trying to implement it at a conference and pointed out
that his implementation ran for three days without terminating, after which he
tried the same thing again.

Did no-one see that this was going to happen?  Why would anyone try and do it
this way?  Rather baffled minds want to know...

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