On Fri, Jan 23, 2015 at 1:21 PM, Stephen Farrell <[email protected]> wrote:
> > > On 23/01/15 18:12, Richard Barnes wrote: > > Yes, you could quasi-templatize it. You would still have to manually > > adjust length fields and munge byte strings together. Eww. > > Not in practice no, public key lengths aren't that variable > and all that's is done by most libraries incl. webcrypto and > openssl - in fact I'd be interested in knowing which crypto > libraries do not directly support this already. I can't think > of any tbh. And I assume our thumbprinting code will use > a library for the hashing and that the public key is very > likely to be used as well as just thumbprinted, so your > argument seems to me broken and h(spki) likely simpler > overall. > > > Given the amount of DANE deployment, it's not a huge priority for me. > DANE > > could also meet us half-way here by defining a new binding type should > > there be a need. > > It's not only DANE - if you go looking around h(spki) is > what's used elsewhere too. And the reason is it's obvious > and correct. > > The choice seems to be between something compatible with > other protocols (allowing comparisons) or rolling your > own to save 2 lines of code or so. (Assuming there are > no other advantages to what you're suggesting?) > > But we're repeating ourselves nearly I guess. > As a matter of process, this would have been a good objection to bring up at milestone / doc adoption time, since if we're just doing h(spki), there's no need for a document. --Richard > > S. > >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
