[anonsec] I-D ACTION:draft-ietf-btns-c-api-00.txt

[caitlinb at broadcom.com (Caitlin Bestler)]

Nicolas Williams wrote:
> On Mon, Jun 18, 2007 at 01:47:03PM -0700, Caitlin Bestler wrote:
>> This draft makes many assumptions about the execution environment.
>> Far too many, in my opinion, for anything beyond an informational
>> RFC. 
> 
> Such as?
> 
>> In particular the requirements that the objects be "opaque" and
>> non-copyable are problematic in embedded and/or virtualized
>> environments.
> 
> As long as interfaces are provided for copying opaque objects
> that may need to be copied that should suffice to address the concern.
> 

A virtual machine or an application is opaque to the entity that
migrates it. There is no way to know that certain bytes require
special copying procedures.

It is also common for security libraries to have content that
SHOULD NOT/MUST NOT be copied to an unsecure location (such as
the swap disk).

Basically the rationale for opaqueness and special migration routines
needs to be clear in order to provide guidance for a wider set of
execution environments. Are the objects opague because that's good
programming practice, or because they might need to be accessible 
by encryption hardware and/or supporting daemons?

As an informational RFC it would be sufficient to state the assumptions,
if you want to be a standard then the specification of the API needs
to avoid making such assumptions unless it can justify them. I am
quite confident that Hypervisors will NOT add special migration hooks
for BTNS objects, so either the definition of these objects has to
be migration friendly or the library has to flag the memory as not
being migratable.

I assume there is no intent to actually mandate how Hypervisors and/or
embedded deployments will operate. But writing things as though the
entire world were Unix and making it a standard has the effect of
imposing arbitrary requirements in other environments.