Re: 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

> Not allowing the client to copy the object to another
location in the
> same process, or to an entirely different process is
quite reasonable.

   I don't think it says that.
   What it says is that if you have a handle in one process,
that it will not 
be transparently valid in another process.   If you want to
move the object 
to another process, then you have to have cooperation of the
object. It's 
just like a file handle or a socket.

> But can the process itself be migrated? Are these
objects expected
> to work after a Unix style fork? What if the entire IP
host is
> migrated to another physical machine?

   Do sockets work after you do these things?

> What needs to be stated is what expectations there are
about
> this memory. Are normal operations on the entire memory
space,
> such as swap-out/swap-in and virtualization migration,
compatible
> with these objects or not?

   We were also very specific in the requirements document
(I think you 
didn't read it), that we never let the application processes
see keying 
material. They have no business knowing about that.


_______________________________________________

 

> -----Original Message-----
> From: anonsec-bouncespostel.org 
> [mailto:anonsec-bouncespostel.org] On Behalf Of
Michael Richardson
> Sent: Thursday, July 19, 2007 11:24 AM
> To: anonsecpostel.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).





_______________________________________________

On Thu, Jul 19, 2007 at 03:21:10PM -0700, Caitlin Bestler
wrote:
> >    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.

Well, I would hope not -- implementing accessor functions as
macros
makes the structure of the object part of the ABI, even
though not part
of the API.  

> >    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?

I think it should be quite clear already that
"opaque" here means "with
respect to the application" since we're defining an
API.  (And
certainly when the language is compared with that of other
Internet RFCs
that describe APIs.)

But adding a simple qualifier like "with respect to the
application"
should be no problem.  Michael?

> 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).

Nothing in this API deals directly with cryptographic key
material.

Nico
-- 
_______________________________________________

Caitlin Bestler wrote:
> 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?

I would be happy to clarify anything. In the IETF tradition,
you can send 
text.  If you send patches, I will apply them.

I just want to be clear that you want me to clarify that the
Application 
Programming Interface is a set of requirements on an
interface that 
Applications use.

They aren't constraints on the application, or on the
operating environment. 
They are constraints are the interface only.  And we aren't
creating an ABI 
either, or promising that a change in the implementation of
the API won't 
require a recompilation of the applications.  (It is
certainly is a nice 
feature if you have, but it certainly isn't required)

> 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

Keys never traverse this API. That is a requirement.
Where the IPsec "kernel" puts keys is it's own
business.


_______________________________________________