On 15/10/2012, at 3:10 AM, Ondřej Surý <[email protected]> wrote:
> Just a question - would anyone would be interested in joining a project to > build an OpenHardware FPGA-based HSM with focus on DNSSEC? > > O. > APNIC has no skills in FPGA level design and construction, but I would be very interested in participating in the specification of the user space requirements for this work. I'm particularly interested in its ability to support a key migration mechanism which would prevent capture of the signing materials by a single implementation. We're finding that the equipment we have now, supports simple mechanisms within the single vendor chain (so you can upgrade) but has no good inter-provider key exchange mechanism, and we've had a similar experience with other (DNSSEC) solutions. A recent conversation suggests that there are no good standards in this space, and that a public-private key exchange between the HSM is the way to go, possibly augmented by a shared-secret generated on-box and shared between them. -G > On 16. 8. 2012, at 2:24, George Michaelson <[email protected]> wrote: > >> >> I got 8 replies. 2 ccTLD, 2 root Ops, almost everyone in s/w development or >> operational related roles, and some independent consultants. >> >> Only one happy user, and I'd qualify that: they'd want a longterm migration >> plan off the device. This person is using Solaris. >> >> Everyone said avoid more than 255 keys on the device. Several said use the >> import/export mechanism. >> >> Two people explicitly mentioned the bad Linux driver. >> >> The overall tone of the (small sample) responses is: "this is not a good >> choice right now" >> >> >> My context is not DNSSEC, its RPKI, which has a far larger keypair >> requirement. Noting a suggestion to re-use keypairs, I'd still have to >> risk-manage future potential for multiple keys per hosted client, and exceed >> the on-card keystore size, so the suggestion to use the import/export >> features makes sense. Having said that, documentation on this is really >> scant, and its hard to confirm how easily you can manage this given there is >> no explicit OpenSSL PKCS11 support for managing PKCS12 wrapped objects, and >> you are therefore using a java or shell command to do the key import, >> followed by OpenSSL engine, followed by shell/java to remove the key. >> >> If you use a pure Java solution its probably more tenable. >> >> Thank you to everyone for the response. I hope this summary meets a sense of >> privacy, and OT posting. >> >> -G >> _______________________________________________ >> dns-operations mailing list >> [email protected] >> https://lists.dns-oarc.net/mailman/listinfo/dns-operations >> dns-jobs mailing list >> https://lists.dns-oarc.net/mailman/listinfo/dns-jobs > > -- > Ondřej Surý -- Chief Science Officer > ------------------------------------------- > CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC > Americka 23, 120 00 Praha 2, Czech Republic > mailto:[email protected] http://nic.cz/ > tel:+420.222745110 fax:+420.222745112 > ------------------------------------------- > _______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
