Terry,
Roque and Steve,
Firstly I think that the ability to specify multiple repositories for the
TAL is warranted.
I spent some time 6 months ago thinking this through and circulated a rough
format that was:
3 ; rsync://rrs.me.org/TA/root.cer ; rsync://rrs.friend.net/TA/root.cer ;
rsync://rrs.them.com/TA/root.cer
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAovWQL2lh6knDx
GUG5hbtCXvvh4AOzjhDkSHlj22gn/1oiM9IeDATIwP44vhQ6L/xvuk7W6
Kfa5ygmqQ+xOZOwTWPcrUbqaQyPNxokuivzyvqVZVDecOEqs78q58mSp9
nbtxmLRW7B67SJCBSzfa5XpVyXYEgYAjkk3fpmefU+AcxtxvvHB5OVPIa
BfPcs80ICMgHQX+fphvute9XLxjfJKJWkhZqZ0v7pZm2uhkcPx1PMGcrG
ee0WSDC3fr3erLueagpiLsFjwwpX6F+Ms8vqz45H+DKmYKvPSstZjCCq9
aJ0qANT9OtnfSDOS+aLRPjZryCNyvvBHxZXqj5YCGKtwIDAQAB
I recall.
So very similar to what you propose, the only semantic difference is that
the number of locations is provided. That has varying degrees of mileage
depending on your point of view.
I see the multiple locations in the TAL as the 'avoidance' on any circular
or even single dependencies of protocol, DNS name->IPvX address, and routing
domain. (irrespective of how the service provision is constructed those are
the three basic building blocks)
In looking at the TAL contents, should more URIs be added the premise must
be that they are all equal in the eyes of the publisher.
why do you say that? it seems like an arbitrary assertion. Why not allow
a TA to assert preference through ordering?
The relying party
then may make their own decision.
RPs are always allow to do that :-) .
But I would suggest that only one URI
selection REOMMENDATION be provided, ie 1) by the closest (RTT) location, 2)
protocol preferece (if HTTP makes it there), 3) order of the TAL. or
whatever the WG decides if this item is adopted.
I'm in favor of making a recommendation, and noting other options
available to RPs.
I also see that you seem to be (section 4) updating the SIA interpretation
in RFC6487, the SIA ordering suggests:
"The ordering of URIs in this accessDescription sequence reflect the CA's
relative preferences for access methods to be used by RPs, with the first
element of the sequence being the most preferred by the CA."
I don't mind if you update it, but the ruleset changes from the ordered
preference by the SIA publisher, to one enacted by the relying party.
I'm in favor of retaining the current interpretation.
While I think that its nice to say that IP addresses are covered by ROAs - I
don't see that as something that is a must as it might be a hindrance down
the road and wouldn't that in itself be a circular dependency?
At the time I thought over this I promised to write some text about it after
publication of the RFC (RFC6490), I didn't - so I am supremely glad you
have! :-)
Thanks go to Roque.
One of the reasons that I didn't make any exerted efforts to put pen to
paper is that I kept coming back to this paragraph in 6490
The TAL is analogous to the TrustAnchorInfo data structure [RFC5914]
adopted as a PKIX standard. That standard could be used to represent
the TAL, if one defined an rsync URI extension for that data
structure. However, the TAL format was adopted by RPKI implementors
prior to the PKIX trust anchor work, and the RPKI implementer
community has elected to utilize the TAL format, rather than define
the requisite extension. The community also prefers the simplicity
of the ASCII encoding of the TAL versus the binary (ASN.1) encoding
for TrustAnchorInfo.
Should we revisit this and form the appropriate PKIX extensions? If not, why
not?
I think the simple answer is that developers of RP software, and
putative TAs, seem
to like the very simple TAL format. However, if we make changes that
cause that format
to become more complex, we might want to revisit the question. If so,
then I would
recommend using one of the formats in 5914.
Steve
_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
