Have you been following the IETF's GSS-API work?

Yes - and implemented a GSS-API mechanism. The relationship between GSS-API and a general crypto interface is contentious - as the interfaces to "export" a key for a remote principal (cf ExportKey and PubExportKey in the draft FIPS) resemble the GSS-API context initiation interface (cf gss_init_sec_context in RFC 1509), but have more assumptions about the possible KM (key management) protocols than GSS-API - or at least only make explicit provision for X9.17, D-H, and RSA. GSS-API has been implemented over Kerberos, DASS, KryptoKnight, DCE1.1, SESAME, and possibly others I haven't heard of. Also, discussions for an extension of GSS-API to layer over PEM/PGP were kicked off at the last IETF to enable mail-enabled applications to be linked in to easily consume authentication and key management services. Hence GSS-API is somewhat proven to be KM-mechanism-independent. There is a potential relationship between this export/import class of interface and the IPSEC packet format (now - or soon to be? - documented), and ongoing IETF IPSEC WG discussions re KM. Specifically, it would be helpful for fast implementations (in both senses) if as much of the processing of IP security could potentially be handed off to hardware-implemented routines via common KM-mechanism-independent and algorithm-independent interfaces (which, based on the NIST proposal primitives, would be [Pub]ExportKey/[Pub]ImportKey, Encipher/Decipher, and GenerateDAC/VerifyDAC). If the right interfaces are standardised in h/w crypto, perhaps little other than negotiation and SAID handling need usually be in software. Piers