Tim,
Thanks for taking the time to read and comment on the document.
I will change CA certificate analysis to be section 2.1, and make the
CRL section b 2.3, as per your request. The Manifest section will remain
2.2, ROAs will become 2.4, GB will become 2.5, and Router Certificates
will remain 2.6. This will require a lot of changes to the pointers
within and between sections, but we aim to please :-).
A-5.4.1: I agree that reducing the set ofresources in a CA certificate
may be done for legitimate reasons, even if the INR holder does not
agree with the reduction. Nonetheless, this is an adverse action from
the perspective of the INR holder. It’s important to note that there are
cases when this reduction is the result of an attack against or an error
by the parent CA. Thus I believe it is important to retain this action
in the list.
A-5.4.2: I’ll delete this action.
A-5.4.5: I agree that this may be hard to distinguish from a legitimate
key rollover, except that a key rollover would have both old and new CA
keys present simultaneously. I’ll add a note to this effect.
I disagree with your suggestion that we remove the modification,
revocation, and injection actions for Manifests, ROAs, and Router
Certificates. First, remember that adverse actions include errors by
CAs, and transient attacks against CAs. In the former case the private
key is clearly available and the CA may also control the repository. In
the latter case note that an attacker need not need learn the private
key’s value; he/she needs only the ability to cause an HSM to use the
key. Also, an attacker need not control the repository to effect these
actions; an RP might be misdirected to a different set of files via a
routing system attack (ironic?) or a DNS attack.
Recall that the goal of this document is to document, as best we can, a
wide range of actions that are adverse, irrespective of whether we can
prevent or detect such actions. Your message noted that RRDP may make it
easier for RPs to detect some of these actions; I suggest you add
references to the relevant sections of this document as further
motivation for transitioning to RRDP.
Finally, when we revised an earlier version of the document we decided
to include every action in the same order in each section (except for GB
records, where it would be trivial), to make it easier for a reader to
see that we were addressing the same issues for each object.
Steve
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
