(Cross-posting to TRANS)
Jeffrey, does "private PKI" mean...
1. A publicly-trusted root, a publicly-logged intermediate, and
non-logged end-entity certs.
or
2. A non-publicly-trusted root, a non-logged intermediate, and
non-logged end-entity certs.
If 1, then please take a look at the mechanism in 6962-bis [1] for
logging a name-constrained intermediate CA certificate in place of the
end-entity certs issued under it.
If 2, then I suspect that this is out of scope for CT, since it seems
likely that most CT logs accepted by browsers will only issue SCTs for
(intermediate or end-entity) certs that chain to publicly-trusted roots.
[1]
https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/?include_text=1
On 22/04/15 00:59, Jeffrey Walton wrote:
According to the CT FAQ at
http://www.certificate-transparency.org/faq, there are three ways to
avoid warnings in some user agents:
* X509v3 Certificate Extension
* TLS Extension
* OCSP Stapling
If a private PKI includes a subordinate in the chain that is name
constrained, then can that be used in lieu of the three methods above?
RFC 6962 does not discuss it (https://tools.ietf.org/html/rfc6962).
But I feel like if the problem is issuing server certificates for
domains *not* authorized to do so, then name constraints seems like a
natural solution.
Thanks in advance.
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
