Subject: Re: [cicm] BoF Request for CICM at IETF 81

From: "Novikov, Lev" <[email-masked]>
Date: Wed, 18 May 2011 08:07:20 -0400

On 2011-05-16 at 21:11, Dennis Bourget wrote:
> Again, I may be picking nits, but I still don't believe that the API
> offers any security domain separation. 
> I would just delete "and thus offers".

On 2011-05-16 at 23:36, John Davidson wrote:
> Dennis wrote:  ...I still don't believe that the API offers any security 
> domain separation. I wish I had written that!  Policy enforcement is not an 
> API's thing, IMHO.

On 2011-05-17 at 13:31, Kevin Wall wrote:
> And while we're picking nits, should read "vendor NEUTRAL", not 
> "vendor agnostic"...unless you believe that nothing can be known / proven 
> wrt the existance of vendors. ;-)

Good points all. Updated.
http://code.google.com/p/ietf-cicm/wiki/WGCharter

  The Common Interface to Cryptographic Modules (CICM) defines an application 
  programming interface for the security services provided by cryptographic 
  modules developed by multiple vendors. The API is intended to support high 
  assurance cryptography, security domain separation, and enhanced module, 
  key, and channel management capabilities that are vendor neutral.

On 2011-05-17 at 10:28, John Davidson wrote:
> This may be a case for just leaving out the "high assurance" (HA) part.
> [...]
> Isn't our API more about being generic and allowing the user to make design 
> choices between best effort and rigorous HA?  

The reason we're referring to high assurance is because it is an important
differentiating factor between CICM and current commercial crypto APIs 
(e.g., PKCS#11). CICM allows users to make a design choice that is not 
available in other APIs-- a point that we need to stress to create this 
Working Group. Otherwise, we are just a very large, generic API (and the IETF
already has GSS-API: Generic Security Services API).

Thank you all for your feedback. Any other points we should clarify?
We'll be asking the Security Area Directors for permission to hold the BoF 
next week (Friday), so let's make sure the charter is ironed out before then.

Thanks,
Lev

---

From: "Davidson, John A." <[email-masked]>
Date: Wed, 18 May 2011 06:52:56 -0700

Wow, what an important point, Lev.  
Could you provide a brief list of features present in our APIs and
missing elsewhere? 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Novikov, Lev
Sent: Wednesday, May 18, 2011 5:07 AM
To: CICM Discussion List
Subject: Re: [cicm] BoF Request for CICM at IETF 81

  The Common Interface to Cryptographic Modules (CICM) defines an
application 
  programming interface for the security services provided by
cryptographic 
  modules developed by multiple vendors. The API is intended to support
high 
  assurance cryptography, security domain separation, and enhanced
module, 
  key, and channel management capabilities that are vendor neutral.

> choices between best effort and rigorous HA?  

The reason we're referring to high assurance is because it is an
important
differentiating factor between CICM and current commercial crypto APIs 
(e.g., PKCS#11). CICM allows users to make a design choice that is not 
available in other APIs-- a point that we need to stress to create this 
Working Group. Otherwise, we are just a very large, generic API (and the
IETF
already has GSS-API: Generic Security Services API).

Thank you all for your feedback. Any other points we should clarify?
We'll be asking the Security Area Directors for permission to hold the
BoF 
next week (Friday), so let's make sure the charter is ironed out before
then.

Thanks,
Lev
_______________________________________________
cicm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/cicm

---

From: "Bourget, Dennis" <[email-masked]>
Date: Wed, 18 May 2011 10:05:05 -0700

Lev, I am OK with the new wording.

-----Original Message-----

Thanks,
Lev

---

From: "Fitton, John" <[email-masked]>
Date: Wed, 18 May 2011 19:17:21 +0000

Lev, I am OK with your latest version.

-----Original Message-----
From: Novikov, Lev [mailto:[email-masked]] 
Sent: Wednesday, May 18, 2011 8:07 AM
To: CICM Discussion List
Subject: Re: [cicm] BoF Request for CICM at IETF 81

Thanks,
Lev

---

From: "Novikov, Lev" <[email-masked]>
Date: Wed, 18 May 2011 21:33:36 -0400

John,

> Could you provide a brief list of features present in our APIs and

Clearly the biggest difference is the concept of domain separation; it impacts the entire logical model, especially channel management.

Additionally, CICM defines more key and module management APIs than other crypto APIs because of the more extensive management available in high assurance devices. 

See: http://tools.ietf.org/html/draft-lanz-cicm-lm-00#section-2

Lev

---

From: "Davidson, John A." <[email-masked]>
Date: Thu, 19 May 2011 07:49:23 -0700

Lev, et al, 
I would vote for it as it is now, but I might even be pinch more
satisfied if it said some of this kind of stuff:  

The Common Interface to Cryptographic Modules (CICM) defines an
application programming interface for the security services provided by
cryptographic modules developed by multiple vendors. It provides
enhanced module, key and channel capabilities that are intended to be
vendor neutral.  The API is structured to enable it to operate in IA
environments that enforce domain separation.  This enables it to be
adaptable to high assurance IA applications.  

-John

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Novikov, Lev
Sent: Wednesday, May 18, 2011 6:34 PM
To: CICM Discussion List
Subject: Re: [cicm] BoF Request for CICM at IETF 81

John,

> Could you provide a brief list of features present in our APIs and

Clearly the biggest difference is the concept of domain separation; it
impacts the entire logical model, especially channel management.

Additionally, CICM defines more key and module management APIs than
other crypto APIs because of the more extensive management available in
high assurance devices. 

Lev

---

From: "Novikov, Lev" <[email-masked]>
Date: Sat, 21 May 2011 22:30:46 -0400

John,

> adaptable to high assurance IA applications.  

It seems that you are trying to distinguish between environments that 
enforce domain separation and high assurance environments. I've been thinking 
about how to incorporate that point into our existing text.

What do people think about the following?

  The Common Interface to Cryptographic Modules (CICM) defines a 
  vendor-neutral application programming interface for security services 
  provided by cryptographic modules developed by multiple vendors. The API 
  defines enhanced module, key, and channel capabilities and is structured to 
  to enable applications to operate in environments that enforce security 
  domain separation, such as high assurance environments.

While I can see the point being made, it might make it harder for people who 
are not familiar with our fine distinctions (i.e. the rest of the IETF) to 
understand why CICM is important.

I'm open to other suggestions.

Thanks,
Lev

---

From: Richard Graveman <[email-masked]>
Date: Sun, 22 May 2011 06:36:14 -0400

It seems to me that high assurance may well be needed in cases with
only one domain. Is that out of scope?

Richard Graveman

---

From: "Novikov, Lev" <[email-masked]>
Date: Mon, 23 May 2011 08:27:45 -0400

Richard,

> only one domain. Is that out of scope?

Single domain use cases are definitely in scope; but they are very similar 
(conceptually) to existing commercial crypto APIs. The ability to separate 
domains is what sets CICM apart.

See: 
"2.3. Single Security Domain" in CICM Logical Model
http://tools.ietf.org/html/draft-lanz-cicm-lm-00#section-2.3

"18. Single-Domain" in CICM Channel Management
http://tools.ietf.org/html/draft-lanz-cicm-cm-00#section-18

Lev