On Monday, May 22, 2017 at 3:41:50 AM UTC-5, Gervase Markham wrote: > On 19/05/17 20:40, Matthew Hardeman wrote: > > Not speaking as to the status quo, but rather in terms of > > updates/changes which might be considered for incorporation into > > policy would be to recognize the benefit of name constrained > > intermediates and allow a reduction in burden to entities holding and > > utilizing name constrained intermediates, both in SSL Server > > Authentication, and Email Protection. (Probably also allow that OCSP > > signing, client authentication, certain encrypted storage extended > > key usages, etc, be allowed). > > This is certainly a question worth considering. I think a careful > comparative risk analysis is in order, and so thank you for starting > that process.
I'm a long time lurker of the list and happy to contribute what thoughts that I may. I was uncertain whether the question(s) that I raised were within the scope of this particular thread, but as you have engaged in dialogue I'll proceed under the assumption that they are unless otherwise directed. > > The issue with excluding any certificate or group of certificates from > the entire scope of the policy is that the issuer would then be free to > issue SHA-1 certs, certs with bad or unpermitted algorithms, and so on. > Are you suggesting that EE certs issued from such an intermediate be > entirely unregulated, or that we should strip down the regulation to > merely technical requirements, ignoring requirements on audit, CP/CPS, > revocation etc.? > I am suggesting that regulations pertaining to issuance from these technically constrained subCAs be stripped down to purely technically enforced requirements if and only if this can be done without disproportionate risk to the Web PKI. My belief is that compelling product offerings could arise in this space if there exist guidelines for the issuance of the technically constrained subCAs and if proper issuance and management of the lifecycle of these subCA certificates can be construed in a way that does not burden the root programs and their member CAs with significant manual audit duties AND which still preserves the integrity of the web PKI. Regarding specifically the risk of the holder of a technically constrained subCA issuing a certificate with an SHA-1 signature or other improper signature / algorithm, my belief at this time is that with respect to the web PKI, we should be able to rely upon the modern client software to exclude these certificates from functioning. My understanding was that IE / Edge was the last holdout on that front but that it now distrusts SHA-1 signatures. > >> From a perspective of risk to the broader web PKI, it would appear > >> that a properly name constrained intermediate with (for example) > >> only the Server and Client TLS authentication ekus with name > >> constraints limited to particular validated domains (via dnsName > >> constraint along with excluding wildcard IP/netmask for IPv4 and > >> IPv6) is really no substantively more risky than a multi-SAN > >> wildcard certificate with the same domains. > > I currently agree this is broadly true, with the exception of the > lifetime issue which you raise in a later message. > > There would be little point in such a TCSC having a max lifetime equal > to the max lifetime of an EE cert, because then after day 1, the EE > certs it issues couldn't have the max lifetime (because the EE cert > can't last longer than the intermediate!). So perhaps max lifetime of EE > + 1 year, so the issuing TCSC needs to be replaced once a year in order > for the organization to continue issuing max length certs? While I certainly think it would be fine to extend the life of a technically constrained subCA significantly beyond that of an EE certificate, as long as the risks are balanced, I do have a question here: 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? The reason that I raise this question pertains to the lifecycle of EE certificates issued subordinate to a technically constrained subCA such that the until date of the leaf certificate exceeds the until date on the parent subCA. If we contemplate a subsequent renewal of the technically constrained subCA with same SPKI, it occurs to me that the subCA can issue a certificate which has an until date which exceeds the subCA until date and then merely change what subCA certificate is distributed to build the trust path, thus allowing the certificate to remain valid as long as the subCA is renewed and deployed on time. This may be especially the case if AIA chasing upon initial path creation / validation failure becomes common practice. > > The sub-subdomain issue is also a difference, but my current view is > that it doesn't have much of an effect on the risk profile in practice. > I believe this is particularly the case if we presume that a technically constrained subCA will have been issued by way of at least an organization validation. Including, of course, demonstration of ownership & control of the included domains (or at a minimum a validated authorization to include a domain owned & controlled by another party). > > As to disclosure of these name constrained intermediates, I should > > think that if they became popular, even among largish enterprises, > > there might arise quite a lot of such intermediates. Perhaps rather > > than in CCADB, these name constrained intermediates should be > > required as a matter of policy to be submitted to CT logs (to an > > acceptable number of logs, with an acceptable number of those under > > separate administrative control). > > If we exempt the certs they issue from CP/CPS and audit requirements, > the need for such TCSCs to be disclosed in CCADB is much reduced. 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? > > Gerv _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
