On Thu, June 16, 2016 13:53, Walter H. wrote:
> On 15.06.2016 16:17, Warren Young wrote:
>> but it also affects the other public CAs: you canâ??t get a
>> publicly-trusted cert for a machine without a publicly-recognized
>> and -visible domain name. For that, you still need to use
>> self-signed certs or certs signed by a private CA.
>>
> A private CA is the same as self signed;
>
No it is not. A private CA is as trustworthy as the organisation that
operates it. No more and not one bit less.
We operate a private CA for our domain and have since 2005. We
maintain a public CRL strictly in accordance with our CPS and have our
own OID assigned. Our CPS and CRL together with our active, expired
and revoked certificate inventory is available online at
ca.harte-lyne.ca. Our CPS states that we will only issue certificates
for our own domain and furthermore we only issue them for equipment
and personnel under our direct control.
In a few years DANE is going to destroy the entire market of 'TRUSTED'
root CA's -- because really none of them are trust 'worthy' --. And
that development is long overdue. When we reach that point many
domains, if not most, will have their DNS forward zones providing TLSA
RRs for their domain CA certificates and signatures. And most of
those that do this are going to be running their own private CA's
simply to maintain control of their certificates.
Our DNS TLSA flags tell those that verify using DANE that our private
CA is the only authority that can issue a valid certificate for
harte-lyne.ca and its sub-domains. Compare that to the present case
wherein any 'trusted' CA can issue a certificate for any domain
whatsoever; whether they are authorised by the domain owner or not[1].
So in a future with DANE it will be possible to detect when an
apparently 'valid' certificate is issued by a rogue CA.
The existing CA structure could not have been better designed for
exploitation by special interests. It has been and continues to be so
exploited.
Personally I distrust every one of the preloaded root CAs shipped with
Firefox by manually removing all of their trust flags. I do the same
with any other browser I use. I then add back in those trusts
essential for my browser operation as empirical evidence warrants.
So I must trust certain DigiCert certificates for GitHub and
DuckDuckGo, GeoTrust for Google, COMODO for Wikipedia, and so forth.
These I set the trust flags for web services only. The rest can go
pound salt as we used to say.
[1]
https://nakedsecurity.sophos.com/2013/12/09/serious-security-google-finds-fake-but-trusted-ssl-certificates-for-its-domains-made-in-france/
--
*** e-Mail is NOT a SECURE channel ***
Do NOT transmit sensitive data via e-Mail
Do NOT open attachments nor follow links sent by e-Mail
James B. Byrne mailto:ByrneJB@xxxxxxxxxxxxx
Harte & Lyne Limited http://www.harte-lyne.ca
9 Brockley Drive vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada L8E 3C3
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
