On Fri, Jun 2, 2017 at 10:09 AM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 02/06/2017 15:54, Ryan Sleevi wrote:
> > On Fri, Jun 2, 2017 at 9:33 AM, Peter Bowen <pzbo...@gmail.com> wrote:
> >
> >> On Fri, Jun 2, 2017 at 4:27 AM, Ryan Sleevi <r...@sleevi.com> wrote:
> >> Yes, my concern is that this could make SIGNED{ToBeSigned} considered
> >> misissuance if ToBeSigned is not a TBSCertificate. For example, if I
> >> could sign an ASN.1 sequence which had the following syntax:
> >>
> >> TBSNotCertificate ::= {
> >> notACertificate UTF8String,
> >> COMPONENTS OF TBSCertificate
> >> }
> >>
> >> Someone could argue that this is mis-issuance because the resulting
> >> "certificate" is clearly corrupt, as it fails to start with an
> >> INTEGER. On the other hand, I think that this is clearly not
> >> mis-issuance of a certificate, as there is no sane implementation that
> >> would accept this as a certificate.
> >>
> >
> > Would it be a misissuance of a certificate? Hard to argue, I think.
> >
> > Would it be a misuse of key? I would argue yes, unless the
> > TBSNotCertificate is specified/accepted for use in the CA side (e.g. IETF
> > WD, at the least).
> >
> > As a practical matter, this largely only applies to the use of signatures
> > for which collisions are possible - since, of course, the
> TBSNotCertificate
> > might be constructed in such a way to collide with the TBSCertificate.
> > As a "assume a jackass genie is interpreting the policy" matter, what
> about
> > situations where a TBSNotCertificate has the same structure as
> > TBSCertificate? The fact that they are identical representations
> > on-the-wire could be argued as irrelevant, since they are non-identical
> > representations "in the spec". Unfortunately, this scenario has come up
> > once before already - in the context of RFC 6962 (and hence the
> > clarifications in the Baseline Requirements) - so it's not unreasonable a
> > scenario to expect.
> >
> > The general principle I was trying to capture was one of "Only sign these
> > defined structures, and only do so in a manner conforming to their
> > appropriate encoding, and only do so after validating all the necessary
> > information. Anything else is 'misissuance' - of a certificate, a CRL, an
> > OCSP response, or a Signed-Thingy"
> >
>
> Thing is, that there are still serious work involving the definition of
> new CA-signed things, such as the recent (2017) paper on a super-
> compressed CRL-equivalent format (available as a Firefox plugin).
This does ny rely on CA signatures - but also perfectly demonstrates the
point - that these things should be getting widely reviewed before
implementing.
>
> Banning those by policy would be as bad as banning the first OCSP
> responder because it was not yet on the old list {Certificate, CRL}.
This argument presumes technical competence of CAs, for which collectively
there is no demonstrable evidence.
Functionally, this is identical to banning the "any other method" for
domain validation. Yes, it allowed flexibility - but at the extreme cost to
security.
If there are new and compelling thing to sign, the community can review and
the policy be updated. I cannot understand the argument against this basic
security sanity check.
>
> Hence my suggested phrasing of "Anything that resembles a certificate"
> (my actual wording a few posts up was more precise of cause).
Yes, and I think that wording is insufficient and dangerous, despite your
understandable goals, for the reasons I outlined.
>
> Note that signing a wrong CRL or OCSP response is still bad, but not
> mis-issuance.
What would you call it? A malformed OCSP response, when signed, can be
indistinguishable from a certificate.
There is little objective technical or security reason to distinguish the
thing that is signed - it should be a closed set (whitelists, not
blacklists), just like algorithms, keysizes, or validation methods - due to
the significant risk to security and stability.
>
>
>
> 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
>
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
