[Cryptech Tech] Restricting CA signing

[Rob Austein]

Related topic, from a meeting today that spent about fifteen minutes
somewhere near the intersection of RPKI and Cryptech.  The following
is based primarily on advice from Russ Housley, who is on this list
and can speak for himself, but who is also just a tad busy.

1) Russ advised us to think carefully about threat model for things we
   check inside the HSM tamper boundary.  Don't check the kitchen
   sink, only check the stuff that would cause a real problem.

   So, for RPKI, concentrate on the handful of fields which, if wrong,
   could make an RPKI object dangerous, and don't worry about things
   like harmless violations of the ten zillion little constraints that
   the RPKI certificate profile imposes on top of X.509, or things
   that are so obviously broken that the object would never pass
   validation.

   For RPKI checking in the Cryptech context, my candidate list of
   critical fields would be:

   - Validity interval (same issue as Jakob's for DNSSEC)

   - Issuer key / issuer name (more on this below)

   - BC, SIA and CRLDP extensions.

   Folks familiar with RPKI may be surprised not to see the RFC 3779
   extensions which are the entire point of RPKI on the above list.
   One could certainly make a case for including them, the problem is
   that these values change over time, which, given the expected usage
   model, would mean that somebody in the Security Officer role would
   have to authorize each change to the values allowed in these
   extensions.  The RPKI already has mechanisms to detect issuance of
   certificates containing resources to which the issuer lacks rights.

   Russ also suggested that one might run full RPKI validation on the
   output of the HSM before publishing as an additional precaution.
   In theory, this would catch most of the potential garbage without
   loading checks for all the silly cases into the HSM itself.

2) Russ pointed out that, if one is going to perform this kind of
   checking at all, whether it's for DNSSEC, RPKI, or ..., the set of
   constraints had better be bound up with the key in whatever
   packaging we use to support key backup, so that the key can't be
   separated from the constraints and used without them.  Russ seemed
   to think this is achievable within the general framework of PKCS #12.

Russ, please correct if I got any of this wrong.