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

[caitlinb at broadcom.com (Caitlin Bestler)]

 

> -----Original Message-----
> From: anonsec-bounces at postel.org 
> [mailto:anonsec-bounces at postel.org] On Behalf Of Michael Richardson
> Sent: Thursday, July 19, 2007 11:24 AM
> To: anonsec at postel.org
> Subject: Re: [anonsec] I-D ACTION:draft-ietf-btns-c-api-00.txt
> 
> Caitlin Bestler wrote:
> > This draft makes many assumptions about the execution environment.
> > Far too many, in my opinion, for anything beyond an 
> informational RFC.
> > 
> > In particular the requirements that the objects be "opaque" and 
> > non-copyable are problematic in embedded and/or virtualized 
> > environments.
> 
>    You are mis-understanding the requirements.
>    The requirements are there in order to free the API 
> developer to be able to  do what make sense in a multitude of 
> environments.  An object is said to be opaque to make sure 
> that the *APPLICATION* does not depend upon the ability to 
> look into the object in order to function.
>    An object is said to be non-copyable, in order that you do 
> not assume that you can copy it trivially by doing a structure copy.
> 
>    In both cases, if your choose to implement the accessor 
> functions as #define macros, and the copy function as 
> *foostruct=*barstruct, that's just fine.
> 
>    However, in a Posix environment, I can not assume that
> 

Would you be ok with explicitly clarifying that the requirements
described are only intended for the application layer code, and are
not intended to constrain implementaion of the operating environment?

Or if there are constraints on the operating environment, to list those
separately? For example, it is concievable that there is a requirement
that the key material not be place in swap eligible memory. If so, that
should be separate and explicit. (Personally, I think that falls under
"quality of implementation" and is not something that should be
standardized,
but I could see valid arguments to the contrary).