Hi Yoav, thanks for corrections. But i think i failed to convey what i wanted to say for the first half part.
Received from Yoav Nir, on 2013-06-06 10:48 PM: > > On Jun 7, 2013, at 8:25 AM, Bry8 Star <[email protected]> wrote: > >> Since most domain-owners/holders send their CSR (cert signing >> request) to their choice of public CA over unencrypted emails, if >> these emails are intercepted by such entity/group who is/are capable >> of doing so, ... then can those entities/groups use such CSR file to >> obtain an alternative cert from another 3rd party or compromised >> public CA cert ? > > CAs make some effort to only send the signed certificate to the actual domain > owner, but I suppose if the attacker is able to intercept the domain owner's > mail, they could probably use the CSR to obtain a valid certificate for the > domain. > >> and then, can they do/run various types of MITM, >> exploitations, spoofing, forwarding, surveillance, data-collection, >> DPI (deep packet inspection) type of devices (or servers), etc ? > > No. Since they're using the original CSR, their MitM attack will fail. If > they generate their own CSR, the keys won't fit the TLSA record (or HPKP pin) > Since most domain-owner uses HOSTing/CLOUD based REMOTE-SERVERs, i consider any type of private_keys, secret_keys, etc there are already intercepted / copied / compromised. Since many are known to assist in Surveillance and Data-collection. And most domains are not yet DNSSEC signed, and most domain-owner's do not sign with DNSSEC, yet. *sad* I should have mentioned this in my posted paragraph. I wanted to talk about things, what most domain-owner's normally do and believe. > >> Common/Public CA entities should either get CSR over TLS encrypted >> pages from domain-owner, or, over GPG/PGP encrypted emails. > > Many already allow you to upload the CSR through the web site, which is > sometimes protected by TLS. But CSRs, much like certificates, are not > considered secret information. > Thanks for clarifying. > >> And should domain-owner(s) move all CSR, csr.pem, prv.key, >> prv.key.pem, etc files to an external removable portable (and >> preferably hot-pluggable) storage device which has encrypted >> partition ? when dealing with, either their own Private self-signed >> Root CA, IA (Intermediate Authority), i-CA etc type of cert, or, >> when dealing with public CA signed cert, unless it is a end-entity >> server cert related prv.key file, as server/service software needs >> end-entity server cert's prv.key. > > It depends. The operational security of running HTTPS servers is a complex > issue, and the solution that fits a personal blog is not the same that would > fit a small online store, and not the same that would fit Google, Facebook, > or a bank. I don't see what Google would gain from placing the private key on > an external, removable, portable, and hot-pluggable device - their servers > are always on. > I do not think i said, Google should place private_keys on removable storage device. I mentioned, any private self-signed Root-CA, intermediate CA, intermediate authority, etc cert's private_keys, csr, etc files should be moved into removable storage device, and mentioned NOT to move last level / end-entity, that is, server-cert's private_keys, as service software needs that private_keys. Google suppose to keep server-cert's private_key on their server. > >> I understand, it is possible to obtain same domain-name based SSL >> cert from a 3rd party CA, and use in middle and run a fake same >> domain-name server. >> >> And if TLSA (aka, DANE) dns record declares/publishes what exact SSL >> cert is trusted by the domain-owner/holder, then web-browser clients >> which can/will check it, can make sure what is the correct SSL cert. >> So that is a very large +point numbers for DANE's advantage, to use >> very correct SSL cert for securing the communication. >> >> But, what type of other problems exist with current PKI >> implementations ? and, How DANE and which other DNSSEC aspects can >> solve it slightly better ? >> >> -- Bright Star. >> >> >> >> Received from Jakob Schlyter, on 2013-05-30 12:37 AM: >>> On 30 maj 2013, at 04:24, Rick Andrews <[email protected]> wrote: >>> >>>> Is there another list that's right for discussing the merits and demerits >>>> of the different DANE options? I work for a CA, so of course I believe >>>> that the current PKI is *not* irreparably broken, nor do I agree that >>>> modes 2 and 3 are "substantially more robust". Because I believe your >>>> voice is respected in this forum, I wanted to speak up to make it clear >>>> that this opinion is not shared by all. >>> >>> Unless the chairs do not object, I believe this mailing list is a good >>> place to discuss this matters. >>> >>> IMHO, classic PKI augmented by DANE would be a very strong package. >>> However, I would argue that without the extra identity proofing and other >>> controls set by by Extended Validation (EV), DANE has equally security >>> properties to a plain Domain Validation (DV) certificate. >>> >>> For a foreseeable future, we definitely need to combine DANE with classic >>> PKI in order for the general Internet user to be able to validate >>> certificates. For limited deployments, or applications where classic PKI >>> has not yet gained significant traction (such as TLS for SMTP), a pure DANE >>> solution makes sense (unless EV is required). >>> >>> jakob >>> >>> _______________________________________________ >>> dane mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/dane >>> >> >> _______________________________________________ >> dane mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/dane
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
