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 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. 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. 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. 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! :-) 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? 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
