On 22/05/2017 19:41, Matthew Hardeman wrote:
On Monday, May 22, 2017 at 11:50:59 AM UTC-5, Gervase Markham wrote:
So your proposal is that technical requirements should be enforced
in-product rather than in-policy, and so effectively there's no need for
policy for the EE certs under a TCSC.
This is not an unreasonable position.
That is a correct assessment of my position. If we are able to unambiguously
enforce a policy matter by technological means -- and most especially where
such technological means already exist and are deployed -- that we should be
able to rely upon those technology constraints to relieve the administrative
burden of auditing and enforcing compliance through business process.
How do the various validation routines in the field today validate a
scenario in which a leaf certificate's validity period exceeds a
validity period constraint upon the chosen trust path? Is the
certificate treated as trusted, but only to the extent that the
present time is within the most restrictive view of the validity
period in the chain, or is the certificate treated as invalid
regardless for failure to fully conform to the technical policy
constraints promulgated by the chain?
Good question. I think the former, but Ryan Sleevi might have more info,
because I seem to remember him discussing this scenario and its compat
constraints recently.
Either way, it's a bad idea, because the net effect is that your cert
suddenly stops working before the end date in it, and so you are likely
to be caught short.
Here I would concur that it would be bad practice for precisely the reason you
indicate. I was mostly academically interested in the specifics of that topic.
I would agree that extending the certificate lifecycle to some period beyond
the max EE validity period would alleviate the need. Having said that, I can
still envision workable scenarios and value cases for such technically
constrained CA certificates even if it were deemed unacceptable to extend their
validity period.
I submit, then, that the real questions become further analysis and
feedback of the risk(s) followed by specification and guidance on
what specific constraints would form up the certificate profile which
would have the reduced CP/CPS, audit, and disclosure burdens. As a
further exercise, it seems likely that to truly create a market in
which an offering of this nature from CAs would grow in prevalence,
someone would need to carry the torch to see such guidance (or at
least the relevant portions) make way into the baseline requirements
and other root programs. Is that a reasonable assessment?
Well, it wouldn't necessarily need to make its way into other places.
Although that's always nice.
Agreed. I primarily made mention of the other rules, etc. because it occurs to me that
part of the same standards of what might qualify for preferential / different treatment
of technically constrained subCAs with respect to disclosure might also neatly align with
issuance policy as might pertain in, for example, your separate thread titled
"Policy 2.5 Proposal: Fix definition of constraints for id-kp-emailProtection"
The question of audit & disclosure requirements pertaining to technically constrained
subCAs seems to be ripe for discussion. I note that Doug Beattie recently sought
clarification regarding this question on the matter of a name constrained subCA with the
emailProection eku only several days ago in the thread "Next CA Communication"
Maybe there is a simpler, less onerous way to sanely impose new CAB/F or
other policy requirements on TCSC without having them operate as full
fledged public CAs with related complexities.
How about this:
* TCSCs can, by their existing definition, be programmatically
recognized by certificate validation code e.g. in browsers and other
clients.
* If TCSCs are limited, by requirements on BR-complient unconstrained
SubCAs, to lifetimes that are the BR maximum of N years + a few months
(e.g. 2 years + a few months for the latest CAB/F requirements), then
any new CAB/F requirements on the algorithms etc. in SubCAs will be
phased in as quickly as for EE certs.
* If TCSCs cannot be renewed with the same public key, then TCSC issued
EEs are also subject to the same phase in deadlines as regular EEs.
* When issuing new/replacement TCSCs, CA operators should (by policy) be
required to inform the prospective TCSC holders which options in EE
certs (such as key strengths) will not be accepted by relying parties
after certain phase-out dates during the TCSC lifetime. It would then
be foolish (and of little consequence to the WebPKI as a whole) if any
TCSC holders ignore those restrictions.
* With respect to initiatives such as CT-logging, properly written
certificate validation code should simply not impose this below TCSCs.
With the above and similar measures (mostly) already in place, I see no
good reason to subject TCSCs to any of the administrative burdens
imposed on public SubCAs.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
