Hi Roque, all, First of all, the short version: = Yes, I support adoption = No, I don't see big issues / show stoppers, have some comments = Yes, I do see potential for other improvements (but I understand we may want to leave it for now)
On Feb 10, 2014, at 6:28 PM, Roque Gagliano (rogaglia) <[email protected]> wrote: > Geoff, > > On Feb 10, 2014, at 5:43 PM, Geoff Huston <[email protected]> wrote: > >> >> 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. >> > > (Roque) No problem and thank you for taking over the work. As I tried to say in my previous mail. This is not show stopper for me, and I am aware that changing this would be new work. So, if this proves too timely and difficult now, or there is simply no wg consensus on this, then I really don't mind deferring this. >>>> 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. 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. For this I think we can assume that the keys match. If the certificate is for another key, it will simply not validate according to the known TAL and be dismissed. But even with the same key other important bits may have changed. Most importantly the resources, but possibly also the publication point. I think the general semantics should be that: = The TAL is just a hints file really, the URIs are there to help the RP find a certificate matching the key they chose to trust = If the RP finds multiple certificates matching the TAL, then (to me) it would make sense to go with the most recent one.. That's where I was driving with the whole Trust Anchor must increase the serial number whenever it re-issues a self signed TA certificate. Then the RP can just go with the one with the highest serial. If we find this a little scary (though I don't see a clear attack here), then I would also be fine with saying that the TA should set the signing-time, and the RP can go with the most recent (non future dated) certificate it knows. I think it's up to the RP to decide how many URIs it will try and how often. You could try to limit that here, but I don't think you can make them.. > 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.) As said above.. not a show stopper, my feeling of the room is that people are not keen, but.. We are actually using a key value pair based tal format in our validator today. We wanted additional info in there, like a human friendly name, and a list of pre-fetch URIs to aid in validating non-hierarchical TA repos. None of this is actually used for validation, it's just hints that make it a bit smoother. If the standard said something like: - must contain one value for the 'subjectPublicKeyInfo' - must contain one or more values for the 'URI' - may contain additional elements - and RP: just ignore what you don't care about Then it would be a little easier to be back-ward compatible. And we could publish our extended TAL and other validators would still understand. And finally on this, I do think json is a better format. Especially when dealing with arrays. Randy you may want to check RFC4627 and the list of links to libraries for 50 odd languages at json.org. It's actually pretty well defined, and widely used. > 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 :-) ). Ah cool. I forgot that, or I missed it, or it lingered in my subconsciousness . In any case it's exactly what I was referring to in my previous mail. I was triggered by this text in section 2.2: If an entity wishes to withdraw a self-signed CA certificate as a putative Trust Anchor, for any reason, including key rollover, the entity MUST remove the object from the location referenced in the TAL. I think a signed TAL would really help here.. If the entity wishes to remove a self-signed CA certificate they SHOULD first publish a new signed TAL where this URI is no longer present and then proceed to remove the object. If the entity wishes to add a self-signed CA certificate publication point they SHOULD first publish the object at the new location and then publish a new signed TAL where this URI has been included. And maybe even the planned key roll.. If the entity wishes to perform a key roll of the self-signed CA certificate they MUST first re-issue all the signed objects signed by the old key under the new key under a new location. Then they MUST publish a new TAL with an subjectPublicKeyInfo matching the new key, one or more URIs, and a date by which the old key will be retired*. I am not saying this is finished.. or even that it must be included now, but I really think this would be useful, and it does not have to get much more complicated than this. *: Note.. on second thought I figured that the not-before-date I mentioned earlier doesn't make sense here: just publish when ready, not before. Cheers Tim > Regards, > Roque > >> regards, >> >> Geoff >> >
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
