George Michaelson wrote:
On 05/11/2009, at 4:50 PM, Robert Kisteleki wrote:
Hi,
I'm proxying two questions from our development team regarding the TA
draft:
1) How do the authors envision key roll overs for the RTA?
Even though the draft allows for re-publication of the self-signed RTA
with new resources, it does not seem to address key roll overs for
that RTA. It seems one would have to publish a new ETA to support
this, which would make invalidating the previous RTA (if that's ever
needed) difficult.
Nowhere in the document does it say that the ETA and RTA keys are
linked. Therefore it's not clear to me *WHY* the ETA has to necessarily
roll when an RTA re-keys.
If an RTA publisher wanted to roll their RTA key, then it seems feasible
by having the ETA simply use the key conservatively and assume an
indefinite lifetime. The important caveat is that the RTA should be
treated with the same level of respect as any trust anchor.
The document does say that there is one SIA for the ETA. It also says that
one CMS bag can contain exactly one RTA. So the only option to publish more
RTAs (while doing a rollover, or just because) is to publish multiple bags
at the SIA location. Is that the intention? I'm wondering if that's enough
if the RTA needs an unplanned key rollover, for which there could be better
support.
2) Can we have a more clear pointer the RTACMS object for relying
parties?
The current proposal has the ETA CA point to a directory. See page 7
of the draft for an ascii-art representation of this. This means that
relying parties will have to find the actual RTACMS object in this
directory themselves. Probably rsync the whole thing and loop over the
entries to figure out which is which.
Robert, the ETA certificate has an SIA. The ETA SIA *should* point to a
directory, which will contain a CMS object, and a CRL. It *can* contain
the ETA too. What else does this directory contain, that a relying party
is not interested in seeing?
Perhaps an mpeg of the cat? Why does the RP need to download everything and
check which one looks like a CMS object, which is a CRL and what's
unimportant, after?
Relying party software, assuming it trusts this ETA, periodically scans
this SIA space and picks up all valid CMS signed objects and loads the
payload RTAs, again assuming that it trusts the ETA. It needs to see the
CRL too.
CMS is quite recognisable, testable, provable. Thats the whole point.
The ETA can be signing over more than one RTA (for instance, key
rollover) so there can be more than one CMS bundle to be seen, signed by
the ETA.
The document is not clear on whether there could be multiple CMS bags in the
directory pointed to by the ETA SIA. But even when this is corrected, we
still have the recognition problem stated above. This is what I'm after here.
Robert
-George
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
