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"
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
