Terry, Please see inline.
Roque On Jul 19, 2012, at 2:51 AM, Terry Manderson wrote: > Roque and Steve, > > Firstly I think that the ability to specify multiple repositories for the > TAL is warranted. (Roque) ok. > I spent some time 6 months ago thinking this through and circulated a rough > format that was: > (Roque) Good, I was not aware. > 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 > > 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. (Roque) We can discuss the particular semantic. > > 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. The relying party > then may make their own decision. 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. (Roque)That is what we are proposing in section 3.2 > > 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. > (Roque) As you mentioned, I am in favor on moving the decision to the RP. This may mean updating RFC 6487 if the WG decides. > 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? > > So, probably we need to do somethingAt 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! :-) > > 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? (Roque) I do not think so. The WG analyzed and dropped the CMS proposal already. > Cheers > Terry > > On 19/07/12 1:47 AM, "Stephen Kent" <k...@bbn.com> wrote: > >> Roque, >> >>> Hi Steve, >>> >>> Thanks for your comments. >>> >>> I tried to extract the most relevant for discussion on text format. >>> >>> 1) Section 2: RFC 6487 limitation to multiple Repository Publication Points. >>> >>> Comment: "6487 says that, for AIA: In this profile, a single reference to >>> the >>> publication point of the immediate superior certificate MUST be present, >>> ŠThat RFC later says that it¹s OK to have other types of accessMethods, >>> which >>> contradicts the earlier text. In any case, the latter text prohibits >>> multiple >>> instances of the same method (e.g., rynch) so Š" >>> >>> (Roque) In summary, RFC 5280 allows multiple "accessMethod + >>> accessLocation". >>> However, RFC 6487 has the contradiction that you pointed out that would >>> prevent not only multiple Repository Publication Points but also for the AIA >>> to allow RSYNC + HTTP support (something we have commented in this list). >>> Although we know that today the AIA has in practice little use, I think we >>> would need to update RFC 6487 in the text to remove the reference to the >>> "single reference". >> It's not a contradiction for 6487 to be more restrictive in this >> respect. 6487 imposes a number of restrictions relative to 5280. So, if >> we decide to change 6487 it should be because we decide that >> we need the flexibility, not because 6487 was inconsistent wrt AIA vs. >> SIA and CRLDP. >> >>> 2) Section 3: >>> "In order to increase robustness, It is RECOMMENDED that a different FQDN >>> could be resolved to IP addresses included in ROA objects from different CAs >>> and hosted in diverse Repository Publication Points." >>> >>> Comment:"I can¹t understand the latter part of this sentence." >>> >>> (Roque) The idea is that the different FQDN: rpki.operator1.org, >>> rpki.operator2.net resolve respectively to IP1 and IP2 addresses. So, those >>> two addresses are recommended to be covered by different ROAs, even >>> administrated by different CAs. Again, the idea is to increase diversity and >>> to avoid any sort of circular dependency. >> Good idea, but not well explained in the text. Also, this takes some >> effort, if the FQDN might >> resolve to multiple addresses and we have to check all of them against a >> set of ROAs. How would this work for an anycast address? >>> 3) Section 3.2 >>> "A RP can use different rules to select the URI from which to fetch the >>> Trust >>> Anchor certificate." >>> Comment: "Is this a good recommendation?" >>> >>> (Roque) The idea here was to imitate the DNS behavior and let the RP to have >>> their "secret sauce" to chose the operator. Normally what you want is to >>> chose the closest one, that is why in DNS you keep track of the response >>> time >>> from the different servers. >> We already have the ability to use DNS for pub point diversity, as your >> text noted. I think it might be preferable to give CAs a different >> mechanism with more tightly-defined semantics to influence RP behavior >> re RPKI data retrieval when we introduce these additional mechanisms. >> >> Steve >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
