At 11:07 PM -0400 7/6/10, Rob Austein wrote:
At Wed, 7 Jul 2010 10:40:40 +1000, Geoff Huston wrote:
On 07/07/2010, at 12:29 AM, Rob Austein wrote:
> I would also like to see some discussion of the simplified trust
> anchor proposal.
What appears to me missing in this second model, aside from the
comments provided earlier by Steve Kent, is the singalling to
relying parties as to the suggested refresh interval for the RTA. IN
the ETA/RTA model the CRLDP provides a time interval that can be
used by RPs to configure their next refresh of the local RTA. In
this model what is the suggested refresh interval? Does one
explicitly use short validity times on the RTA (this would be
strange/ possibly bad) or does one leave it to the RP to just guess
(again this seems strange/ possibly bad).
The simplified mechanism has no need for an explicit refresh interval.
The self-signed RPKI certificate (corresponding to the RTA in the
ETA/RTA model) is just another object to be retrieved using rsync, so
one using rsync to retrieve it on validation if it has changed, same
as any other object. No special handling needed.
Rob,
rsync is not an ideal way to know when a new cert needs to retrieved, since
we don't assume that either the repository or the channel used to
access it are integrity secure.
If I understand Geoff's comment, I might have phrased it differently. For both
the compound TA and simplified TA models, the self-signed certs that
used as TAs for 3779 validation contain a validity interval which is
the primary way to determine when to acquire a new cert. However, in
the compound TA model there is a CRL, and that provides an
independent way to tell an RP when to check to see if the TA may have
been replaced, without having to re-issue that cert if there is no
change. I think you can achieve the same effect by mandating a second
tier CA as the effective TA, which will be covered by a CRL issued by
the top tier TA. (I believe my analysis urged adoption of this 2-tier
CA model to make the two schemes comparable. Geoff's observation
provides another motivation for doign so.)
Steve
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
