On Thu, Jun 1, 2017 at 10:19 PM, Peter Bowen via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Thu, Jun 1, 2017 at 5:49 AM, Ryan Sleevi via dev-security-policy
> > So I would definitely encourage that improper application of the
> protocols
> > and data formats constitutes misissuance, as they directly affect
> > interoperability and indirectly affect security :)
>
> I think the policy needs to be carefully thought out here, as there is
> no limitation to what can be signed with the key used to sign
> certificates. What is a malformed certificate to one person might be
> a valid document to someone else. Maybe you could disallow signing
> things that are not valid ASN.1 DER?
>
I'm not really sure I see the slippery slope argument you mention.
On the most basic level, this is describing what Mozilla considers
misissuance - warranting at least some discussion and, if appropriate,
updates to policies. It naturally suggests that, in order to improve both
security and transparency, the policy should be maximally applicable, and
then allow situational constructs to override, rather than to try to
accommodate every unknown hypothetically good activity.
For example, I think we'd easily agree that improper DER encoding is
misissuance - that's an improper application of the data format. I think
we'd also hopefully agree that if, for example, a CA asserted a set of KUs
that were 'validated', but not conformant to RFC 5280 (e.g. 5280 says MUST
NOT and a CA does it anyways), then that's an improper application of the
data format/protocol.
I suspect you're raising a concern since a CA can use a SIGNED{ToBeSigned}
construct from RFC 6025[1] to express a signature over a structure defined
by "ToBeSigned", and wanting to distinguish that, for example, a
certificate is not a CRL, as they're distinguished from their ToBeSigned
construct. I would argue here that any signatures produced / structures
provided should have an appropriate protocol or data format definition to
justify the application of that signature, and that it would be misissuance
in the absence of that support. Logically, I'm suggesting it's misissuance
to, for example, expose a prehash signing oracle using a CA key, or to sign
arbitrary data if it's not encoded 'like' a certificate (without having an
equivalent appropriate standard defining what the CA is signing)
It seems far better for avoiding confusion to treat everything as wrong,
and then if it is indeed acceptable, to modify the policy at that time. I
don't think we can reasonably give "the benefit of the doubt" anymore.
[1] https://tools.ietf.org/html/rfc6025#section-2.3
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
