-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I am currently reimplementing my RELOAD enrollment server and unfortunately the questions below were never answered.
It would be great also if the open issue in section 11.3 could be decided (password errors SHOULD be returned as 401 Unauthorized). And as I am at it, here a nit in section 11.3: s/with the parameter encode as described/with the parameters encoded as described/ and two more in section 11.1: s/Inside each overlay element, the required-kinds elements can/Inside each configuration element, the required-kinds element can/ s/Multiple required-kinds elements MAY be present./Multiple kind-block elements MAY be present./ On 10/29/2011 02:33 PM, Marc Petit-Huguenin wrote: > Not a full review yet, but I saw this new text in section 10.3: > > "The enrollment server SHOULD maintain a mapping of users to node-ids and > if the same user returns (e.g., to have their certificate re-issued) > return the same Node-ID, thus avoiding the need for implementations to > re-store all their data when their certificates expire." > > Even after the sentence is fixed there would still be two issues: > > - How does this work if the user requested multiple certificates from the > same login? - How does this work if the number of Node-Ids requested > changes? > > Also I would like to point out that I proposed a different solution to > this problem in this draft: > > http://tools.ietf.org/html/draft-petithuguenin-p2psip-reload-bis-00#section-6 > > My solution does not permit to change the private key without assigning > new Node-Ids, but in addition of not having the two problems listed above, > it does not require server-side storage. > - -- Marc Petit-Huguenin Personal email: [email protected] Professional email: [email protected] Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJPz2RwAAoJECnERZXWan7EndYP/j/uvdvV75NgeLu7nzyx25DP UrnpB12MQyZjzkT/5FluR862dIYTaBIYXVsKyLxslEfEp1FVs59O9q0gtEeCETay TBRj7g5Ag+KZ2ibvzTk2aYjRhO7sZFdTzmGpHM027kLLAlcDalRd6RGb3IsRpmGd nOnKwb2t+++AHQ2b/zmLpOS+ESwITHlcw3dISfyLBM4BphBQ31OWUCZGdGVgtWED P0+BC31c093V2MwcbN30o4aDEsttpp8eUKS0DaeObHpSmcszFD8VwkzuglLOsHfd gzQNZcNIWXSCKvc8+zWEU+6hqcCYHKB4quuSZLi+028sQ/95RZ30ZY0YBtK8A/I8 5zUsPNH07fGWOhIs6CoXOLmDAd7exR23Fg2HL8TvqoeIId4XONYL1zmeZ9VUOtHT NH2BRLV4VkpDzpjKlMLKgwdMO0pnIqA91sWSGZlzzGyE12iXUXJLfSk03oQ//Op0 LwMzb+SY79rSTmIt2T9yexjG1g/XGT6HL0oLO1R7777/gRB7AiIb0aGOd+ekJFY1 HbFehJ9QJ2k1nvgx1f3SNG5sHlo0/zylkVYzoKVoNA73s1+SR0S78HGqMr2iTwkl ZlfnQ3IBXEQuBsWvc7YW8D/q4UQCqC0hENJpkn4A9Ghj300bmgYUoIyfIjdvULDd 1TodgYyudu4mnLye3eUF =jXKJ -----END PGP SIGNATURE----- _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
