Hi Goeff, On Feb 9, 2014, at 11:05 PM, Geoff Huston <[email protected]<mailto:[email protected]>> wrote:
Hi, I took the text n draft-ietf-sidr-multiple-publication-points as it related to TAs and placed it into the RFC6490bis draft without change. The syntax of the TAL is not something I care a lot about either - I suppose that one could get worried about rogue TA:s that try to place 1 million URIs into the TAL, and get into the whole JSON / plain ascii thing - I thought that the draft-ietf-sidr-multiple-publication-points document already had a certain level of WG buy-in behind it - I guess that was not a very good assumption on my part. I'll happily add what the WG wants here. The document went through the adoption process and was open to discussions for almost 2 years. We never went through WGLC, which is when most people pays a closer attention. The only formal comment that we received on the format was about the blank line Randy mentioned and that was incorporated. The issue about multiple CA certs that are different was something the earlier draft was silent about. They simply said that they MUST be the same and left it at that. I'm not sure how critical an issue this is, and whet forms of additional mechanism are necessary to allow RPs to retrieve all the referenced CA certs and define an algorithm for them to follow to select the "best". My simplistic thinking about the original intent in draft-ietf-sidr-multiple-publication-points was that an RP would pick oine URI, and if that was unresponsive after some local threshold it wuould try another, and so on. The discussion so far has been based on an assumption that an RP would retrieve the CA cert from 2 or more URI's and then worry about the case where the URIs differ. I am not sure what to add here to the draft - the WG will need to provide further guidance on this. I worry about a proposal for RPs to check all URIs - it seems to me to be adding to the total load and I'm then not sure where the benefit of multiple URIs in TAs comes from in such a scenario. I believe you should use Section 3.2 of draft-ietf-sidr-multiple-publication-points as a starting point. As you can see the recommended behaviour is to select a rule to fetch the TA certificate and stop when you fetch one that matches the TAL public key. 3.2<http://tools.ietf.org/html/draft-ietf-sidr-multiple-publication-points-00#section-3.2>. Rules for Relying Parties (RP) A RP can use different rules to select the URI from where fetch the Trust Anchor certificate. Some examples are: o Using the order provided in the TAL file o Selecting the URI randomly from the available list o Creating a prioritized list of URIs based on RP specific parameters such as connection establishment delay If the connection to the preferred URI fails or the fetched certificate public key does not match the TAL public key, the RP SHOULD fetch the TA certificate from the next URI of preference. Roque Finally, the issue obout URI diversity was again taken from teh original text and I had assumed that the WG had already considered this. regards, Geoff On 9 Feb 2014, at 12:14 am, Tim Bruijnzeels <[email protected]<mailto:[email protected]>> wrote: On Feb 8, 2014, at 5:21 AM, Randy Bush <[email protected]<mailto:[email protected]>> wrote: i think this is a worthwhile effort and this document is a good place to start. +1 Some initial comments in-line. -- presuming there is consensus to adopt, i have some some nits we can discuss when it is a wg item. o i thought folk wanted a blank line between the URI(s) and the key I am not sure that I care too much about this as long as it's well defined. But if the format is open to change, then I would feel more for a key=value style, or dare I say even json.. this is parsed by the machines after all. And using something like json makes it much more flexible regarding ordering of elements, or extending should that ever be necessary. o last para of 2.2 says Where the TAL contains two or more rsync URIs, then the same self-signed CA certificate MUST be found at each referenced location. maybe should say what happens when one or more do not have the same cert? does the whole TAL get ignored? I agree, but on top of that having multiple publication points by definition implies that there will be differences, albeit short lived. I would like to see wording along these lines. = TA MUST increment serial number whenever they re-issue the CA cert = TA SHOULD* publish the CA cert in all locations 'asap', within 1 hour? = TA SHOULD* remove the cert from unmaintained locations *: They may not be able to if this is hosted at a third party To handle all this more elegantly I think there should be a mechanism for TAs to publish replacement TALs. To add, or remove URIs, or even to do planned key rolls (for example: TA wants change HSM vendor). What if the TA could optionally publish one (1) signed object containing an updated TAL? And possibly some dates: do-not-use-this-before, and do-not-use-other-after? This would allow RPs to use existing TALs to discover updates and process automatically (it is signed by the key that I trust). It could stop re-trying retired URIs, and start using the new ones. And even planned key rolls could be as simple as this on this level (provided the TA re-issues and publishes all the products before the change date, under the new key and in its own repositories). o same last para of 2.2 it is RECOMMENDED that the domain name parts of each of these URIs resolve to distinct IP addresses that are used by a diverse set of repository publication points, and these IP addresses be included in distinct Route Origination Authorizations (ROAs) objects signed by different CAs. as this is ops guidance, and really the core of the proposed change, perhaps the rationale for this should be given o 3.1 Retrieve the object referenced by (one of) the URI(s) contained in the TAL. you may want to give some guidance as to which one. pseudo-random? first? think load balancing, proximity, ..., a la fns I like to see some guidance, but ultimately I think the RP should be allowed to choose a strategy. I would probably prefer to check all URIs regularly, and go with the certificate with the highest serial number (provided the key matches of course). Tim _______________________________________________ sidr mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/sidr _______________________________________________ sidr mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/sidr
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
