Geoff,
On Feb 10, 2014, at 5:43 PM, Geoff Huston <gih...@gmail.com> wrote:
>
> On 11 Feb 2014, at 3:23 am, Roque Gagliano (rogaglia) <rogag...@cisco.com>
> wrote:
>
>> Hi Goeff,
>>
>> On Feb 9, 2014, at 11:05 PM, Geoff Huston <gih...@gmail.com> 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.
>
(Roque) No problem and thank you for taking over the work.
>
>>
>>> 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 wh
ere
>>> 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.
(Roque) Two different problems:
1) Fetching two different TA certificates that match the public key but
do not have the same content: This problem can happen today as even if you have
one URI, you can have two different "real" rsync servers behind, we are just
making it evident. I personally believe we should stay only what is the
expected behaviour rather than enumerating all the alternatives.
2) Tim proposal to expand the TAL verbosity: I am sympathetic to the
idea of using key=value style. However, as we only have two "keys", I see
little incremental value on the changes from one version to the next one. On
the other side, I am skeptical to add more verbosity to the TAL with
information that we cannot cryptographically verify (the TAL is a plain text
not signed document.) I remember Carlos proposed the idea of having a special
TAL signed object only available at the TA's publication point that would add
information referring to the TAL lifecycle (maybe including a new TAL file to
be replacing the existing one.) This seams to be a more appropriate way to
solve the problem of replacing the TA key and keep the compatibility with the
old install base (and as long as it is not been compromised :-) ).
Regards,
Roque
> regards,
>
> Geoff
>
_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
