On 19/11/2010, at 12:49 AM, Roque Gagliano wrote: > Hi Geoff, > > Thank you for your email, please see comments inline. > >> >> I am of the opinion that the protocol already has sufficient knobs to >> support an environment of algorithm transition without further augmentation. >> >> The existing protocol supports: >> - multiple algorithms are implemented as multiple classes > (Roque) agree. >> - algorithms for each class are identified in the certificate provided by >> the server in the response to a LIST command > (Roque) agree. I believe you meant that as we implement top-down you could > use the issuer's certificate, correct?
geoff: yes. >> - the server performs a proof of possession text using the algorithm >> associated with the class that was nominated in the certificate request. > (Roque) agree. And if we do not create any additional error code and if a > client sends a "issue" request using a non-supported algorithm for a given > class, the server will respond MUST an error code 1203: badly formed payload. > correct? Geoff: Correct. In an algorithm transition context, the client MUST use the same algorithm as used in the server (issuer's) certificate within a resource class (as provided by the Issuer in the LIST command response), and the server will response with a 1203 error code otherwise. You can write that up in the algorithm document. > > I will add text describing this mechanism in the next version of the agility > draft. thank you Geoff _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
