Re: [sidr] Requesting comments on multiple publication points

[Tim Bruijnzeels <[e-mail]>]

On Aug 1, 2013, at 5:50 PM, Carlos Martinez-Cagnazzo <[e-mail]> wrote:
> thanks for all your input on this draft. I encourage all to send their comments and discuss the draft on the list.

I have some ideas I would like to share with the authors and working group after the presentation on multiple publication points.


= I support the idea of having multiple publication points in general

I think it addresses a need for increased redundancy, even if it adds complexity. 


= I agree that two documents instead of one would be useful

The problem of finding different out-of-sync information is different when retrieving TAs, and published objects of certificates.


= Instructions to TAs listing multiple publication point

I believe the TA SHOULD make sure that TA certificates published in different locations are kept up to date. I think a maximum of 24 hour delay between updating the first location and the last location is the right order of magnitude. If TAs can no longer maintain a publication point I believe they MUST remove the TA certificate from that publication point.


= Instructions to RPs looking at TAs

I believe it should be local policy whether an RP fetches just one, or several TA certificates.

I think it should be recommended to download all TA certificates, validate them (including self signed signature) and compare them. The certificate with the highest serial number should be used.


= Allowing changes to TALs

Obviously a more detailed document would be needed to describe this, but one way to achieve this could be to let the current TA to publish a signed object containing the new TAL, and some other information like: date when new TAL becomes operational and date when the current TAL will be withdrawn.

I believe this is useful here because it would allow TAs to change the list of URIs they include on the TAL. This can also give us a useful way to do planned rolls of TA keys, and with some other meta-info this might be useful for algorithm roll as well.



= Instructions to CAs using multiple publication points

I believe SIA fields can be used to list more than one publication point, irrespective of protocol.

I believe that CAs MUST maintain all their  publication points. As a rule I think that a "MUST send updates to all publication points with one hour is appropriate". Furthermore I believe that a CA that is planning to remove a publication point MUST request a new certificate minus the corresponding SIA pointers before withdrawing. And conversely, if CAs want to add publication point I believe they MUST start publishing there first, and only then request a new certificate with the additional SIA pointers.


= Instructions to RPs when using multiple publication points

I think local policy applies. I would recommend that multiple sources are checked, but if an RP will only use e.g. the first publication point I think that should be allowed. The CA has a responsibility to keep all those publication points up to date, or withdraw them if they can't, or just won't..

I believe that separating the object discovery and retrieval from validation can help to deal with inconsistencies between repositories. Described here:
http://tools.ietf.org/id/draft-tbruijnzeels-sidr-validation-local-cache-01.txt

In a nutshell the idea is to do validation using manifests as authoritative sources to find the current objects published by for a CA certificate. The latest *valid* manifest is used for this. The objects are retrieved by hash rather than their name. So it does not matter where the RP got this from, or how often.

That said this needs pilot work. I hope to do proof-of-concept code. I don't believe this is the only way for RPs to deal with this, but I think it would help to show a possible way to achieve this.


Cheers
Tim