Subject: Re: [P2PSIP] Reissuing certificate [was I-D Action: draft-ietf-p2psip-base-19.txt]

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 06 Jun 2012 07:08:54 -0700

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-masked]
Professional email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 15 Jun 2012 17:21:22 -0600

> (password errors SHOULD be returned as 401 Unauthorized).

that was on slide 6 of the preso at last meeting - I need to go find all the notes but I seem to recall the decision was 401 would not be used.

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 15 Jun 2012 17:14:56 -0700

On 06/15/2012 04:21 PM, Cullen Jennings wrote:
>> It would be great also if the open issue in section 11.3 could be
>> decided (password errors SHOULD be returned as 401 Unauthorized).
> 
> that was on slide 6 of the preso at last meeting - I need to go find all
> the notes but I seem to recall the decision was 401 would not be used.
> 

OK, so for until it is fixed, I'll return "512 Specification broken" in my
implementation.

- -- 
Marc Petit-Huguenin
Email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug