On Tue, Mar 10, 2015 at 02:16:04PM +0000, t. p. wrote:
----- Original Message -----
From: "Sam Hartman" <hartmans-ietf(_at_)mit(_dot_)edu>
To: "t.p." <daedulus(_at_)btconnect(_dot_)com>
Cc: "Sam Hartman" <hartmans-ietf(_at_)mit(_dot_)edu>;
<ietf(_at_)ietf(_dot_)org>;
<secdir(_at_)ietf(_dot_)org>; <iesg(_at_)ietf(_dot_)org>;
<draft-ietf-netconf-rfc5539bis(_dot_)all(_at_)tools(_dot_)ietf(_dot_)org>
Sent: Tuesday, March 10, 2015 12:48 PM
"t" == t p <daedulus(_at_)btconnect(_dot_)com> writes:
Well, I think you still need to answer questions like
* Is it a fingerprint of the cert or the key?
* Is the server expected to re-normalize the DER? Allowed to
re-normalize the DER?
Sam
Thank you for your comments.
The I-D specifies fingerprint of the certificate so that is specified.
Normalisation is not specified and is an interesting point; as you say,
something to be considered.
The model follows RFC 6353 (STD 78) and I am not aware of any issues
that were reported against STD 78 because fingerprints do have issues
with being ambiguous. So are we talking about a real-world problem or
a problem that could exist in theory?
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103 <http://www.jacobs-university.de/>