dual signing keys (Was: Support for signing key on hardware security modules)

[Cantor, Scott]

> I forgot to ask the ultimate question (which is more interesting than
> the service categorization issue you mentioned): How will you
> distribute the signing certificate for the short-lived key?

Local metadata feeds for on campus systems, in which case I could do it daily if I really wanted) but mostly manual "login to web UI and update". We're talking annually or bi-annually, not monthly.

> I guess the answer depends on what you mean by "short-lived." If by
> that you mean O(days), I don't think current infrastructure is
> adequate.

Metadata is perfectly adequate for that, but obviously a lot of them don't handle it, making that impractical, and there's no way to divide things cleanly into "does" and "doesn't". Categorization *is* the issue, operationally speaking.

Any services that are both high risk to us and don't provide me a way to update the key myself will be put into a separate discussion category with hopefully an eye on dropping them using the auditors as a stick.

I don't know if Box actually uses the InCommon metadata, for example, so that will be a good test case.

-- Scott