[ this discussion is not to be taken as questioning if the draft should be adopted by the wg. i have already advocated for adoption. we're now in the post-adoption discussion :) ]
> 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. the assumption that json is a universally, or even widely, implemented format is not well founded. let's not get carried away into lala land. we're just trying to allow multiple uris in a tal. >> 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. huh? a difference in the cert's key between the tal and the repository is a major error. the question i asked was if we should/could give some guidance on how to deal with it. > 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' i suspect many of those "TA"s are "CA"s. operationally, how do you remove something from an unmaintained location irrespective of who does not maintain it. maybe you mean remove the uri from the tal? as it is the key, not the cert, which must match, i am not sure how critical this all is. and if the key changes, you have entered the world of key roll, and i suspect we don't want to go there this week. > 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? major expand-a-project. not if you want this draft finished in 2014. >> 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. that is one approach > 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). so the rp is to chase them all? how often. when three uris have the same serial, which do you choose? and perhaps we should recommend going with the uri which points to a cert with a serial which matches that in the tal? but mainly, i think it would be good to give some guidance. randy _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
