Subject: [cicm] Key Identifers

From: "Nanjundiah, Girish" <[email-masked]>
Date: Thu, 2 Jun 2011 16:17:14 -0700

Hello Everyone,

Sorry if this question is extremely obvious or just hasn't been answered
but I'm a little confused as to how we are meant to access the
CICM::CharString identifier attribute of the CICM::Key class. I'm
assuming attributes are all private or protected, so how is one to
access the identifier? While it is easy to obtain its value with
CICM::Key::export, I can't seem to find a way to set it without adding
another function or a constructor for the CICM::Key class...

Thanks,

-Girish Nanjundiah

---

From: "Novikov, Lev" <[email-masked]>
Date: Fri, 3 Jun 2011 16:33:40 -0400

Girish,

On 2011-06-02 at 19:17, Girish Nanjundiah wrote:
> [...] how we are meant to access the CICM::CharString identifier attribute 
> of the CICM::Key class.

An attribute in IDL gets mapped to _get_{attribute}() and _set_{attribute}() 
methods for the object. For example, the CryptoModule::sym_key_manager 
attribute is a read-only attribute so it becomes:
    
    SymKeyManager* CryptoModule::_get_sym_key_manager(void) {
      return &(this->sym_key_manager);
     };
    
See:
http://code.google.com/p/ietf-cicm/source/browse/cpp/cicm.cpp#47

For your case, you'd want to define something similar.

Let me know if works for your situation.

Lev

---

From: "Fitton, John" <[email-masked]>
Date: Fri, 3 Jun 2011 22:29:29 +0000

I would imagine that one method would be for the entity desiring to obtain key identifiers would be to list the attributes of the keys that it is interested in. By passing in such an attribute list, then a compilation of the key identifiers which satisfy the attribute list could be provided. Proper Least Privilege restrictions would restrict the entity from including any attributes in the request that are not consistent with the applications needs. These "needs" could be listed in a security policy which is enforced by the Security Model. In that way the application could only find out about keys which a constrained to that attribute set.

________________________________
From: Nanjundiah, Girish [[email-masked]]
Sent: Thursday, June 02, 2011 7:17 PM
To: CICM Discussion List
Subject: [cicm] Key Identifers

Hello Everyone,

Sorry if this question is extremely obvious or just hasn’t been answered but I’m a little confused as to how we are meant to access the CICM::CharString identifier attribute of the CICM::Key class. I’m assuming attributes are all private or protected, so how is one to access the identifier? While it is easy to obtain its value with CICM::Key::export, I can’t seem to find a way to set it without adding another function or a constructor for the CICM::Key class…

Thanks,
-Girish Nanjundiah

---

From: [email-masked]
Date: Mon, 6 Jun 2011 09:49:43 -0400

Maybe the spirit of Girish's original question was whether we
implementers are permitted to modify the CICM test harness files
provided to us by MITRE.  It was my understanding (from the kickoff
telecon) that we vendors are only to modify the cicm.cpp and config.h
files, not the cicm.h, encrypt.cpp, and decrypt.cpp files.  (That is,
implementers are to complete the coding of the stubs in cicm.cpp.)  If
that understanding is correct, it limits implementers a bit as to what
functionality can be added.

So maybe the broader question is: are venders permitted/expected to
modify all the test harness files?

Thanks,
  Steve DiMedio
  L3 Communications
  856-338-4204

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Fitton, John
Sent: Friday, June 03, 2011 6:29 PM
To: CICM Discussion List
Subject: Re: [cicm] Key Identifers

I would imagine that one method would be for the entity desiring to
obtain key identifiers would be to list the attributes of the keys that
it is interested in. By passing in such an attribute list, then a
compilation of the key identifiers which satisfy the attribute list
could be provided. Proper Least Privilege restrictions would restrict
the entity from including any attributes in the request that are not
consistent with the applications needs. These "needs" could be listed in
a security policy which is enforced by the Security Model. In that way
the application could only find out about keys which a constrained to
that attribute set.

Hello Everyone,

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

---

From: "Nanjundiah, Girish" <[email-masked]>
Date: Mon, 6 Jun 2011 09:47:29 -0700

That is part of my question, I realize we are not allowed to modify the
header file but if we are to add _set and _get methods for the classes
as Lev said then we do need to modify the header file in order to add
the function signatures.

Thanks,
-Girish

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Monday, June 06, 2011 6:50 AM
To: CICM Discussion List
Subject: Re: [cicm] Key Identifers

Thanks,
  Steve DiMedio
  L3 Communications
  856-338-4204

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

Hello Everyone,

Thanks,
-Girish Nanjundiah

---

From: "Novikov, Lev" <[email-masked]>
Date: Mon, 6 Jun 2011 14:21:49 -0400

Girish,

On 2011-06-06 at 12:47, Girish Nanjundiah wrote:
> [...] if we are to add _set and _get methods for the classes

Correct. The header file is just a barebones version of a CICM driver; 
vendors may need to add more CICM-defined methods to make the whole 
harness work (as a last resort).

Lev