On 02/06/2017 17:12, Ryan Sleevi wrote:
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.
If you read the paper, it contains a proposal for the CAs to countersign
the computed super-crl to confirm that all entries for that CA match the
actual revocations and non-revocations recorded by that CA. This is not
currently deployed, but is an example of something that CAs could safely
do using their private key, provided sufficient design competence by the
central super-crl team.
Another good example could be signing a "certificate white-list"
containing all issued but not revoked serial numbers. Again someone
not a random CA) should provided a well thought out data format
specification that cannot be maliciously confused with any of the
current data types.
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.
In this case, it would presume that technical competence exists at high
end crypto research / specification teams defining such items, not at
any CA or vendor. For example any such a format could come from the
IETF, ITU-T, NIST, IEEE, ICAO, or any of the big crypto research centers
inside/outside the US (too many to enumerate in a policy).
Here's one item no-one listed so far (just to demonstrate our collective
lack of imagination):
Using the CA private key to sign a CSR to request cross-signing from
another CA (trusted or untrusted by Mozilla).
Functionally, this is identical to banning the "any other method" for
domain validation. Yes, it allowed flexibility - but at the extreme cost to
security.
However the failure mode for "signing additional CA operational items"
would be a lot less risky and a lot less reliant on CA competency.
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.
It is restrictions for restrictions sake, which is always bad policy
making.
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.
If necessary, one could define a short list of technical characteristics
that would make a signed item non-confusable with a certificate. For
example, it could be a PKCS#7 structure, or any DER structure whose
first element is a published specification OID nested in one or more
layers of SEQUENCE or SET tags, perhaps more safe alternatives could be
added to this.
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.
An incorrect CRL is an incorrect CRL and falls under the CRL policy
requirements.
An incorrect OCSP response is an incorrect OCSP response and falls under
the OCSP policy requirements.
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.
Those whitelists have already proven problematic, banning (for example)
any serious test deployment of well-reviewed algorithms such as non-NIST
curves, SHA-3, non-NIST hashes, quantum-resistant algorithms, perhaps
even RSA-PSS (RFC3447, I haven't worked through the exact wordings to
check for inclusion of this one).
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
