On Monday, May 22, 2017 at 2:14:57 PM UTC-5, Ryan Sleevi wrote:

> Another approach is to make an argument that such validations are already
> accounted for in the EV Guidelines, in which a certificate may be issued
> for 27 months, but for which the domain must be revalidated at 13 months.
> In this case, the TCSC might be issued for an 'extended' period (perhaps on
> an order of many-years), with the expectation that the CA will revoke the
> TCSC if the domain does not (periodically) revalidate.
> 
> Each of these approaches are with their own tradeoffs in design,
> complexity, and risk, and argue more or less strongly for disclosure
> because of it.
> 
> My own take is that I would prefer to see TCSCs uniquely named (e.g.
> through the use of dnQualifier), limited to the validity period permitted
> of leaf certs (since they're, effectively, "ultra" wildcards), with some
> robust diclosure & revocation story. I'm concerned that extending the
> period of time is to incentivize such certs, which introduce additional
> risks to the evolution of the Web PKI.

Hi, Ryan,

Thanks for the information regarding the chain validity periods and their 
impact as to the RFC defined behavior and in-field implementation behaviors.  I 
suspected there would be some differences across implementations.

I am inclined to agree with your assessment as to the validity period.  The 
future in which I would envision more common use of TCSCs would still be a 
future that encourages leaf deployment automation and, ideally, quite limited 
with respect to the validity period (at least, I should say, with respect to 
TLS server certificates).

To any such extent that TCSCs might discourage server operators from 
establishing good certificate and key lifecycle management, or server operators 
might attempt to rely upon a TCSC as a way of generating 
longer-than-BR-allows-for-validity leaf certificates, I would say that policy 
should probably prevent this as even a potential incentive.

I would be interested to learn more of your perspective on "robust disclosure & 
revocation story".  What constitutes a robust disclosure?  For example, does 
that imply a mandatory timely publication in CCADB?  With respect to a revoked 
TCSC, does that require formalized submission to the root programs for 
distribution in their respective centralized revocation distribution mechanisms 
(OneCRL, etc.)? Which remaining features of a TCSC provide capabilities which 
might be mitigated by this level of disclosure versus mere mandatory 
publication to CT?

Thanks,

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

Reply via email to