On 11 Feb 2014, at 3:23 am, Roque Gagliano (rogaglia) <[email protected]> wrote:
> Hi Goeff, > > On Feb 9, 2014, at 11:05 PM, Geoff Huston <[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. no criticism was intended here Roque about the previous process. I was trying to explain my assumptions when incorporating this text into 6490bis. I agree that in general it takes a Last Call to elicit readers and comments, although there are always exceptions and this call for adoption is one of them. > >> 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 whe re >> 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. 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. > I can (and will) certainly add that text to section 3 of the bis document. However, the question raised by Randy and commented on by Tim still remains - what should a RP do if it chooses to retrieve the material from 2 or more URIs and finds that the CA certificates that are retrieved in this manner differ? And from Tim, some further contemplation about that the TA publisher could do to provide hints to the RP in such a situation. regards, Geoff _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
