Tim,
--
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.
I'm not a fan of switching to JSON at this point.
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
I agree with Randy that the references to "TA" above should just be "CA"
I'm puzzled by the references to a "third party" above. Why would an
entity acting as
a TA not want to control all of the locations where it's TAL identifies
as places from
which to acquire the cert?
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?
These are desirable, additional features, but I agree with Randy that
they merit a new work item.
The change to allow a TAL to contain pointers to multiple locations for
cert retrieval seems to
be an easy change that we can agree upon.
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).
As I noted above, this seems like a good, new work item.
Steve
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
