3.1 It's true that many browsers don't do certificate status checks by
default, but only Firefox (AFAIK) gives the user the option to enable those
checks.

3.4 " Despite this situation, at least one major browser does not support
name constraints, and as a result, CAs are reluctant to use name
constraints." That's true, but it's only part of the story. Symantec (as an
example) issues certificates to FQDNs in practically all TLDs, ccTLDs, gTLDs
including many of the newly-approved ones. It's simply not practical for us
to use name constraints on our issuing CAs. And in the small number of cases
where we issued an issuing CA to an external third party, every single one
has rejected the idea of name constraints because they all wanted the
ability to issue to newly-acquired domain names. 

4.1.  Determination of the Trusted Certificate Authorities
" The browser vendors and the CAs determine what should and should not be
trusted by default." Not true; only the browser vendors determine what
should and should not be trusted. CAs have no control over their decisions.

Under " 5.  Emerging Technical Improvements" you might add the use of
Content Delivery Networks. Most major CAs today use CDNs to deliver CRLs and
OCSP responses, resulting in high availability and low latency for clients.
However, browser vendors still eschew status checking. 

5.1.1 " Sadly, few CAs take advantage of the CRLDP certificate extension." I
don't agree. Most of the CAs I'm aware of still add CRLDP extensions, even
though they're not required by the CABF Baseline Requirements and largely
ignored by browsers.

5.2.1 DANE
" DNSSEC has a single root domain as opposed to a multiplicity of trusted
CAs" It's true that DNSSEC has a single root domain, but if fully deployed,
every domain owner would also have to manage their own PKI. It's not
trivial, and there are no audit or compliance standards for this. 

I would suggest that you mention the multiple DANE modes of operation. In
two of the modes, no PKIX chain validation is needed; hence a self-signed
cert might appear as trustworthy as a CA-signed cert. 

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
wpkops mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/wpkops

Reply via email to