[bind10-dev] crypto API

[Francis Dupont]

> It is an answer.  If thing1 IS A thing2, you write it one way.  If
> thing1 HAS A thing2, then you write it another.  It's an answer.

=> if it is so obvious what this says about public DNSSEC key vs
private DNSSEC key?

> > => I disagree: the API should be designed from our needs, not in the
> > other way. But this doesn't mean crypto++ or botan or ... can't be
> > good source of ideas, I just prefer to look at applications first.
> 
> I would not want to see ISC making a crypto library.  That's not what we
> know how to do, and it's not what we should be doing.

=> you didn't understand my idea: with other words IMHO it is better to
adapt existing crypto libs to what BIND 10 needs than the opposite,
so the API should be designed from the need, not the offer.
BTW this should guarantee to not be locked to a particular library
(i.e., not reproduce the BIND 9 and OpenSSL issue).

Francis Dupont <fdupont at isc.org>

PS: I believe the most important is to stay high level and DNS (or other
things supported by BIND 10). For instance a DNSSEC public key is fully
included (oops, is or has? :-) into an RRdata of a DNSKEY RR.