At 2:58 PM -0500 11/9/06, Sandy Murphy wrote:
>This is not the way that a PKI would be expected to work, in general.
A signer of data cannot in general know what TAs RPs may select, so
it is not incumbent on a signer to try to provide multiple signatures
to accommodate this uncertainty.
(This isn't a matter for the minutes, since it wasn't mentioned in
the meeting. So I changed the subject.)
So you are saying that there is no need for the list of signatures
in the ROA that Brian Weiss was showing?
not for the reasons cited in your message.
Suppose there were a small handful of commonly used trust anchors
Would you then say that a list of signatures made sense?
well, if the list is "commonly used" then you could pick any one, right :-)?
(Obviously, if there were a wild plethora of trust anchors in use,
trying to list all needed ones would be infeasible.
And we don't know which will be the case.)
right.
Having a list of single signature ROAs works as well as a single ROA
with a list of signatures, I believe. So this is not a functional
difference, more an engineering decision.
I still think this is the wrong model. The original rationale for
multiple signatures for a ROA was NOT to accommodate multiple TAs,
but rather to accommodate a ROA that contained prefixes acquired from
multiple sources, and thus no EE cert could be created that merged
these prefixes (due to RFC 3779 constraints).
Thus there may still be a good basis for supporting multiple
signatures for a ROA, if we want to allow a ROA to contain prefixes.
However, if we become comfortable with the notion that one should
just create multiple ROAs in these circumstances, we can live with a
single signature ROA syntax. This also would obviate a security issue
Geoff raised, i.e., stripping a signature from a ROA.
Steve
_______________________________________________
Sidr mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/sidr
