On Fri, Mar 8, 2019 at 4:35 PM watson--- via dev-security-policy < [email protected]> wrote:
> We are interested in CAs signing x509 certificates that can be used with > delegated credentials for TLS, > https://tools.ietf.org/html/draft-ietf-tls-subcerts-03. The certificates > to be signed by the CA are x509 certificates that contain a special > extension that identifies them as being able to sign short-lived (maximum 7 > days) credentials to terminate TLS connections with. The short term > credentials do not increase, decrease, or modify the authorization attached > to the certificate: they are a tool to enable services like CDNs, SaaS > providers, and indeed web servers to terminate TLS on behalf of a site for > the duration chosen by the issuer of the authorization. The validity period > of the certificates will not change, nor do we think there should be extra > requirements on verification to issue certificates with this extension. > Is there a security considerations or analysis that explores the considerations that were examined with respect to these certificates? I ask, because in the context of HTTP Signed Exchanges https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html , there was an effort to introduce additional validation requirements, most notably, the explicit consent and opt-in by a site (via CAA) and a policy expectation encoded in the spec that CAs SHALL NOT issue unless that CAA constraint is satisfied. While in the case of HTTP Signed Exchanges, these represent an extension of capability, and especially the ability to be used in the absence of a direct connection to the authoritative origin (as determined by DNS), it would be useful to know what sort of considerations have been made - whether it's ruling out particular concerns or including particular concerns (e.g. the inclusion within Section 3.2 of the draft of the delegationUsage extension) One example that stands out is the requirement that the extension MUST be marked non-critical. The rationale for that decision would be useful to capture in some way, whether in this document or in a supplementary "explainer", so as to capture the thinking. A small note, if it can be accepted, is that I believe the intended wording is "MUST NOT be marked critical", since as a DEFAULT value in a sequence with a value of FALSE, you would not encode anything for the criticality field. I highlight this, as it's an area where CAs have incorrectly DER encoded FALSE values (see https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Things_for_CAs_to_Fix ), and such wording may lead to a similar, and undesirable, result. If using delegated credentials on a webserver with a separate server > producing the delegated credentials, an event like Heartbleed that results > in disclosure of a key has a more limited impact than the disclosure of the > certificate's private key. Cloudflare has implemented Keyless SSL to > achieve a similar effect, and this draft came out of the TLS WG's > recognition that a standardized technology with similar properties would be > broadly desirable. We need certificates to opt-in due to concerns about > cross-protocol attacks. Delegated credentials can only be used with one > signature scheme and are tied to the certificate and scheme used to issue > them, so are robust in the face of cross-protocol attacks. To further > minimize the risk we will add to security considerations that ECDSA certs > are better due to Bleichenbacher issues in old TLS versions. > To confirm: In the event of a Heartbleed-like event, the expectation would be that CAs would revoke non-Delegation Credential certificates (due to the possible key compromise issues), but that certificates bearing the delegationUsage extension would not be revoked, correct? > We are currently interested in deploying delegated credentials over the > next few months, and hope CAs will help enable this for the broader web > ecosystem. Nothing in the BR or Mozilla Root Program requirements forbids > issuing certs with these extensions, but we felt it would be prudent to ask > for feedback on this proposal from more sources then just those involved in > the TLS WG. I look forward to your thoughts. Just to echo this for participants who may not be familiar with the specific requirements of the Baseline Requirements, the specific requirement or dispensation exists with 7.1.2.4 of the Baseline Requirements (v1.6.3) All other fields and extensions MUST be set in accordance with RFC 5280. > The CA SHALL NOT issue a > Certificate that contains a keyUsage flag, extendedKeyUsage value, > Certificate extension, or other data not > specified in section 7.1.2.1, 7.1.2.2, or 7.1.2.3 unless the CA is aware > of a reason for including the data in the > Certificate. CAs SHALL NOT issue a Certificate with: > a. Extensions that do not apply in the context of the public Internet > (such as an extendedKeyUsage > value for a service that is only valid in the context of a privately > managed network), unless: > i. such value falls within an OID arc for which the Applicant > demonstrates ownership, or > ii. the Applicant can otherwise demonstrate the right to assert the data > in a public context; or > b. semantics that, if included, will mislead a Relying Party about the > certificate information verified by > the CA (such as including extendedKeyUsage value for a smart card, where > the CA is not able to verify > that the corresponding Private Key is confined to such hardware due to > remote issuance). Under this provision, the argument is that the existence of the IETF draft document, with the to-be-assigned extension point for this usage, would allow CAs to satisfy the requirement of 7.1.2.4(a)(ii), provided they issued according to that draft document once such an OID has been assigned. The only concern with such an interpretation respect to 7.1.2.4(b). Is it correct that the assumption is that the CA will require that the Applicant for such a certificate affirmatively declare it shall be used for that purpose? _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
