[Cryptech Tech] Draft Requirements

[Rob Austein]

First response to Requirements draft as relates to RPKI.

- Not sure about per-key storage requirements yet.  Origin of per-key
  numbers currently shown in Wiki not immediately obvious to me
  (perhaps I need to read the Wiki page a few more times?).

- Algorithms look OK for current RPKI and BGPSEC specs: everything is
  RSA-2048, EC-P256, and SHA-256.

  I think Randy wants EdDSA 25519, but has not sold SIDR WG on it, so
  it's not in the current specs.

- RPKI has a lot of keys flying around.  The obvious ones to protect
  are CA keys, but there are a lot of EE keys as well.

  Depending on software design choices, RPKI EE keys can be use-once
  throwaways, ie, one generates the keypair, signs something, and
  destroys the private key; opinions vary on how good an idea this is,
  as key generation is relatively expensive, thus this could be
  construed as an invitation to an amplification attack, but this
  approach does bypass the question of storing all those EE keys.

- RPKI CA operators fall into two very different categories (based
  purely on operational issues, no fundamental protocol difference):

  - operators who provide hosting (eg, at present, all of the RIRs)
    will be operating a separate CA for each hosted customer (hundreds
    or thousands of CAs);

  - operators who don't provide hosting will (probably) just be
    operating a handful of CAs for themselves.

  Very different requirements.  In practice, at present, I think all
  of the RIRs who use HSMs only use them for their own CAs, not for
  customer ("member") CAs, much less customer EE operations, thus
  avoiding the key storage issue.

- A typical singleton change to an RPKI CA's outputs requires 2-5
  signatures, depending on implementation choices and the specific
  change being made:

  - New object (EE key signing CMS);
  - EE certificate for new object (CA key signing EE certificate);
  - Manifest (EE key signing CMS);
  - EE certificate for manifest (CA key signing EE certificate);
  - CRL (CA signing CRL).

  Bulk changes to the outputs of a single CA can amortize the last
  three signatures over the entire batch.  Since CRLs and manifests
  are supposed to stay synchronized, we will probably issue a new CRL
  every time we issue a new manifest (ie, with every change) even if
  we haven't revoked anything.

  Adding or changing a child CA is similar, with 2-4 signatures (one
  fewer because parent CA signs child CA certificate directly rather
  than issuing an EE certificate for a CMS-wrapped blob).

- The "one signature/hour" guess for CRL signing is probably (very)
  optimistic.  When a customer clicks on the button saying "I want to
  originate my prefix foo at AS bar", the customer probably expects
  something to happen quickly, not after lunch.  Opinions seem to vary
  greatly on this point, mostly depending on whether or not the person
  expressing the opinion has a job description like "NOC monkey".

  I suspect the history of expected publication times in the DNS
  hosting business may be a better model for customer expectations
  here than the traditional CA business.

- RPKI only uses CRLs, not OSCP; the CRLs are published along with the
  rest of the RPKI data.

The above is probably too verbose for the requirements page, which is
why I'm sending it as email rather than just editing the page.  Use as
you see fit.