Does CICM only provide (specify) the "red" side API in = a multilevel system?

From clinn@harris.com Wed Jun 2 14:00:45 2010 Return-Path: X-Original-To: cicm@core3.amsl.com Delivered-To: cicm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA9393A6A4F for ; Wed, 2 Jun 2010 14:00:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.751 X-Spam-Level: * X-Spam-Status: No, score=1.751 tagged_above=-999 required=5 tests=[AWL=-1.750, BAYES_99=3.5, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nnMkMxKyFune for ; Wed, 2 Jun 2010 14:00:44 -0700 (PDT) Received: from mlbe2k1.cs.myharris.net (mlbe2k1.cs.myharris.net [137.237.90.88]) by core3.amsl.com (Postfix) with ESMTP id BFCD63A6A4D for ; Wed, 2 Jun 2010 14:00:44 -0700 (PDT) Received: from mail pickup service by mlbe2k1.cs.myharris.net with Microsoft SMTPSVC; Wed, 2 Jun 2010 17:00:28 -0400 Received: from roce2k4.cs.myharris.net ([147.177.32.37]) by mlbe2k1.cs.myharris.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Jun 2010 17:00:25 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB0296.9EC15C29" Date: Wed, 2 Jun 2010 17:00:41 -0400 Message-ID: <4586CEA3C168F64BA2E01DF8B18821AF05C4E75A@roce2k4.cs.myharris.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Does CICM only provide (specify) the "red" side API in a multilevel system? Thread-Index: AcsClqlCklUl2Q1cSmuDsyq2ADOjnQ== From: "Linn, Charles" To: X-OriginalArrivalTime: 02 Jun 2010 21:00:25.0452 (UTC) FILETIME=[9F8032C0:01CB0296] Subject: [cicm] Does CICM only provide (specify) the "red" side API in a multilevel system? X-BeenThere: cicm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: CICM Discussion List List-Id: CICM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jun 2010 21:00:45 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB0296.9EC15C29 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Forgive the ignorant newbie question! For this post, my frame of reference is a red/black traditional cryptosystem. Imagine for the sake of discussion you have two general purpose processors with a hardware (or otherwise abstracted) crypto subsystem between the two. Therefore all traffic for this example crosses security domains, vs. being a coprocessor style interface. In all the section 3 examples, the CICM API is only shown on the "red" side of the CSS. Indeed, when I look at a Decrypt::Stream, I don't see where the caller provides the data to be decrypted, instead seeing only how a buffer is supplied to receive the data. This leads us (Anthony DiBernardo first noticed this) to conclude that perhaps it is not the intent of CICM to specify a black side API. Contrast this with, for example, the original SCA security API (the present RSS is ITAR, and hence off bounds to this forum), which has both red and black side interfaces. Am I missing something? Thanks, Chuck Linn & Anthony DiBernardo ------_=_NextPart_001_01CB0296.9EC15C29 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Does CICM only provide (specify) the "red" side API in = a multilevel system?

Forgive the ignorant newbie = question!

For this post, my frame of reference is = a red/black traditional cryptosystem. Imagine for the sake of = discussion you have two general purpose processors with a hardware (or = otherwise abstracted) crypto subsystem between the two. Therefore = all traffic for this example crosses security domains, vs. being a = coprocessor style interface.

In all the section 3 examples, the CICM = API is only shown on the "red" side of the CSS. Indeed, = when I look at a Decrypt::Stream, I don't see where the caller provides = the data to be decrypted, instead seeing only how a buffer is supplied = to receive the data. This leads us (Anthony DiBernardo first = noticed this) to conclude that perhaps it is not the intent of CICM to = specify a black side API. Contrast this with, for example, the = original SCA security API (the present RSS is ITAR, and hence off bounds = to this forum), which has both red and black side interfaces.

Am I missing something?

Thanks,
Chuck Linn & Anthony = DiBernardo

------_=_NextPart_001_01CB0296.9EC15C29-- From lnovikov@mitre.org Thu Jun 3 08:17:17 2010 Return-Path: X-Original-To: cicm@core3.amsl.com Delivered-To: cicm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 455CC3A69DC for ; Thu, 3 Jun 2010 08:17:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3pM3tZ6GET-T for ; Thu, 3 Jun 2010 08:17:15 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id C5C163A69D6 for ; Thu, 3 Jun 2010 08:17:15 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o53FH11K027348 for ; Thu, 3 Jun 2010 11:17:01 -0400 Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o53FH17u027331 for ; Thu, 3 Jun 2010 11:17:01 -0400 Received: from IMCMBX3.MITRE.ORG ([129.83.29.210]) by imchub2.MITRE.ORG ([129.83.29.74]) with mapi; Thu, 3 Jun 2010 11:17:01 -0400 From: "Novikov, Lev" To: CICM Discussion List Date: Thu, 3 Jun 2010 11:15:43 -0400 Thread-Topic: Does CICM only provide (specify) the "red" side API in a multilevel system? Thread-Index: AcsClqlCklUl2Q1cSmuDsyq2ADOjnQAlg+xw Message-ID: References: <4586CEA3C168F64BA2E01DF8B18821AF05C4E75A@roce2k4.cs.myharris.net> In-Reply-To: <4586CEA3C168F64BA2E01DF8B18821AF05C4E75A@roce2k4.cs.myharris.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [cicm] Does CICM only provide (specify) the "red" side API in a multilevel system? X-BeenThere: cicm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: CICM Discussion List List-Id: CICM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2010 15:17:17 -0000 Chuck, Anthony, > Forgive the ignorant newbie question! Not ignorant at all! Excellent question. > In all the section 3 examples, the CICM API is only shown=20 > on the "red" side of the CSS.=A0 Indeed, when I look at=20 > a Decrypt::Stream, I don't see where the caller=20 > provides the data to be decrypted, instead seeing only=20 > how a buffer is supplied to receive the data.=A0=20 > ... perhaps it is not the intent of CICM to specify a black side API. Indeed you are correct (but perhaps this needs to be changed). Our design was motivated by the understanding that the transfer of data from the black side to the module or vice-versa was simply "data transfer" and not a crypto operation=20 (i.e. outside the scope of CICM). > Contrast this with, for example, the original SCA security API=20 > (the present RSS is ITAR, and hence off bounds to this forum),=20 > which has both red and black side interfaces. So now the question is: Do we need to fix this? Perhaps we could consider some sort of "get/put" channels that could be used to received/supply data to the module=20 on the black side. If so, we should start discussing the ramifications to channel definitions because currently we do not explicitly define the "side" of any channel (you can use any channel on any side that has software to support that channel). Lev From dlanz@mitre.org Mon Jun 7 10:22:13 2010 Return-Path: X-Original-To: cicm@core3.amsl.com Delivered-To: cicm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F21763A6DB6 for ; Mon, 7 Jun 2010 10:22:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cqv1prCXh-Gb for ; Mon, 7 Jun 2010 10:22:10 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id E219728C52D for ; Mon, 7 Jun 2010 08:55:40 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o57FtdaN030671 for ; Mon, 7 Jun 2010 11:55:39 -0400 Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o57FtdJc030665 for ; Mon, 7 Jun 2010 11:55:39 -0400 Received: from IMCMBX1.MITRE.ORG ([129.83.29.204]) by imchub2.MITRE.ORG ([129.83.29.74]) with mapi; Mon, 7 Jun 2010 11:55:39 -0400 From: "Lanz, Dan" To: "The Common Interface to Cryptographic Modules discussion list is focused on APIs for High assurance cryptographic modules." Date: Mon, 7 Jun 2010 11:55:36 -0400 Thread-Topic: [cicm] Logical Model, PKCS#11 & FIPS-140-2 Thread-Index: Acr44KuxHQDLdOJMQZiFXwxeFPerwANZS5AQ Message-ID: <3FF9F74E63A7484EB3B88F04329CBEDC02B1ABF566@IMCMBX1.MITRE.ORG> References:

<4BF3A800.6090005@inria.fr> In-Reply-To: <4BF3A800.6090005@inria.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [cicm] Logical Model, PKCS#11 & FIPS-140-2 X-BeenThere: cicm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: CICM Discussion List List-Id: CICM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2010 17:22:13 -0000 Ludovic, Your concern regarding allocation of functions to only the domain (red or b= lack) in which they are "required" is one that the CICM development team co= nsidered extensively last year. The chosen approach was to not constrain f= unctions to one domain or the other. Instead, we allowed the developer to = allocate where specific functions were needed, with the caveat that the dev= eloper had to explicitly state what functions were implemented (see CICM "C= onformance" section). However, upon further review, the Conformance sectio= n does not require the developer to state in which domain a particular func= tion was implemented. This was a significant oversight. However, since you've raised the issue, we should explore this further. Sh= ould the specification state explicitly whether a function is a red functio= n, a black function, or both? Or should this not be explicitly stated (ins= tead, presumably, the specification would only require a developer to state= in the conformance statement where a function was implemented--red, black,= or both)? Or is there another better approach? This question will take some thought. Consider the ::import_key function. = CICM allows both red and black key to be imported via this interface. Man= y modules will disallow the importation of red key on the black side, or ma= y disallow the importation of red key altogether. Should ::import_key be b= roken up into red and black domain versions, to allow its use to be constra= ined to only one domain? There are a number of functions with similar circ= umstances. This is significant architecturally to the interface so comments/suggestion= s from the community would be very helpful. Dan -----Original Message----- From: cicm-bounces@ietf.org [mailto:cicm-bounces@ietf.org] On Behalf Of Lud= ovic Jacquin Sent: Wednesday, May 19, 2010 4:58 AM To: The Common Interface to Cryptographic Modules discussion list is focuse= d on APIs for High assurance cryptographic modules. Subject: Re: [cicm] Logical Model, PKCS#11 & FIPS-140-2 Hello Lev, > Indeed, that is a critical component of domain separation. However, > since CICM doesn't specify hardware requirements (it's a software=20 > interface), perhaps we should only mention that in passing when > dealing with the logical model. >=20 > * Is that sufficient, does anything else need to be specified? Yes, we agree and maybe it can be mentioned in an introductory/context part. As we concentrate on high assurance and interface definition, this kind of discussion may contain a TODO and a NOT TODO list for developers because bad implementations or usage can significantly weaken the whole system. Another point: Charles recently highlighted the fact that having a single large IDL file was not recommended. There's another motivation, beyond dead code considerations. Because of our domain separation constraint, we largely prefer to have separate subsets of functionalities. In our case, the cryptographic module is at the boundary between the black domain (that manages ciphered packets, in the unsafe area) and the red domain (that manages cleartext packts, in the safe area). And the two security domains cannot communicate with each other directly since the cryptographic module creates a breaking point between them. Therefore the API (and thus the IDL) should be divided into parts that represent the subsets of functionalities required by each security domain. Cheers, Ludovic and Vincent _______________________________________________ cicm mailing list cicm@ietf.org https://www.ietf.org/mailman/listinfo/cicm From prvs=377546e64f=jherzog@ll.mit.edu Tue Jun 8 09:26:31 2010 Return-Path: X-Original-To: cicm@core3.amsl.com Delivered-To: cicm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 488B63A69D0 for ; Tue, 8 Jun 2010 09:26:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.247 X-Spam-Level: X-Spam-Status: No, score=-3.247 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, SARE_OBFU_ALL=0.751, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pCvbaCNVBMSz for ; Tue, 8 Jun 2010 09:26:28 -0700 (PDT) Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by core3.amsl.com (Postfix) with ESMTP id EAA3B3A6917 for ; Tue, 8 Jun 2010 09:26:24 -0700 (PDT) Received: from LLE2K7-HUB02.mitll.ad.local (LLE2K7-HUB02.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id o58GKEMY027511 for ; Tue, 8 Jun 2010 12:26:14 -0400 From: "Herzog, Jonathan - 0668 - MITLL" To: "cicm@ietf.org" Date: Tue, 8 Jun 2010 12:26:10 -0400 Thread-Topic: OID for algorithm identifiers? Thread-Index: AcsHJ03D6Zexz+HmeUWW1hgStnDphQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.0.0.090609 acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3358844770_26466005" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-06-08_05:2010-02-06, 2010-06-08, 2010-06-08 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1005130000 definitions=main-1006080101 Subject: [cicm] OID for algorithm identifiers? X-BeenThere: cicm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: CICM Discussion List List-Id: CICM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2010 16:26:31 -0000 --B_3358844770_26466005 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Perusing the CICM spec (http://tools.ietf.org/html/draft-lanz-cicm-00; please let me know if there is a more recent version) I notice that it apparently uses chracter-strings for identifying algorithms (Section 3.2.2.5). Really? Is there a structure to this name-space? Who manages it? The CMS standard (Cryptographic Message Syntax, RFCs 5652 and 5754 among many others) have settled on using OIDs for algorithm-identification, which seems much saner. Not only are OIDs in a hierarchical ID-space, allowing control over the name-space to be allocated and delegated among many organizations, but it would allow CICM a greater compatibility with CMS and its messages. Or is there a downside to OIDs that I don't yet see? Thanks. -- Jonathan Herzog voice: (781) 981-2356 Technical Staff fax: (781) 981-7687 Cyber Systems and Technology Group email: jherzog@ll.mit.edu MIT Lincoln Laboratory www: http://www.ll.mit.edu/CST/ 244 Wood Street Lexington, MA 02420-9185 --B_3358844770_26466005 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUOwYJKoZIhvcNAQcCoIIULDCCFCgCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC Eh4wggTSMIIDuqADAgECAgoVTNyWAAAAACIfMA0GCSqGSIb3DQEBBQUAMFExCzAJBgNVBAYT AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzAR BgNVBAMTCk1JVExMIENBLTEwHhcNMTAwNTI1MjA0NTM4WhcNMTEwNTI1MjA0NTM4WjBkMQsw CQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMG UGVvcGxlMSMwIQYDVQQDExpIZXJ6b2cuSm9uYXRoYW4uQy41MDAxMTMwNTCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAPd5q+Wus6uhELFbSF/QWnccM6Y2mxfKbw5qDEj/2YW1 q53DSdY+8YgRnIoWKrA2kM/foSSE8YuyDDVMeX5xbTkER2YJDgi0dVERXNAJSdz5J7+l6EOH 6jzg5kjAfPNnPZf/AGzuzf9u6/J/1dCKeEacPNap6w15OlB/9cx5bLBppVZ4NEUkRLkMvfMT 8c2y6+XDjFi8B7OTizWHBr9CpQ+q6dQz8yd6qZVP/tD9o8mGxsl0rSf4ftyseZjlhSweI/Bw 8ixvdGR5WY2V6PRa0qBbm1SSv5nVcyLl3dNC3ZdXwssYUQ/XpZKU3O8TiybBMwgovBqqOnkL r89UR/d7tz8CAwEAAaOCAZcwggGTMA4GA1UdDwEB/wQEAwIGwDAdBgNVHQ4EFgQUT4xuvgsU eh/6Pb8quT4Jlvb5rmowHwYDVR0jBBgwFoAUlFrGWMm2JpugCXuoL2SQw4kCbiowMwYDVR0f BCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNybC9MTENBMTBiBggrBgEF BQcBAQRWMFQwLQYIKwYBBQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXR0by9MTENB MTAjBggrBgEFBQcwAYYXaHR0cDovL29jc3AubGwubWl0LmVkdS8wDAYDVR0TAQH/BAIwADA9 BgkrBgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+K cwIBZAIBBTAiBgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAP MA0GCyqGSIb3EgIBAwEIMB0GA1UdEQQWMBSBEmpoZXJ6b2dAbGwubWl0LmVkdTANBgkqhkiG 9w0BAQUFAAOCAQEASOmqHtXOhpc7Nx4f5SM39k85rWUkC5fFGWiBRotMxtBI7DusI1+m37/1 osxN9DhHn+kqO+qdHTbe49tZax/hRmh+q+NYIIpG5KGszZAHj7EJNFj2YZqbrNawcjVKMyuC jD6cywMpxzXeZjzraqCMA4kxIJLS7mdZ8FO21B5r+wTteHZIS4TDhSkQiIt76nvaw4faU2Ld WDYUHtXwZnumOQ1iwE8QQahK89OXu61Z4CouspOo+3KlqYjOi/d89mauafRagArCR5jMMR// FxXnl4BX/wijACLkmQhhVNvaLhGVi+yy7vO0hRpt3/97C0u8YF3ou3fz5V7XtRyinSjgjzCC BCcwggMPoAMCAQICAQMwDQYJKoZIhvcNAQEFBQAwVDELMAkGA1UEBhMCVVMxHzAdBgNVBAoT Fk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQGA1UEAxMNTUlUTEwg Um9vdCBDQTAeFw0wODEwMTUxMjAwMDBaFw0xNDEwMTUyMzU5NTlaMFExCzAJBgNVBAYTAlVT MR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNV BAMTCk1JVExMIENBLTEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDR6ztRCggS Jl8DROVlA6fjEplja+BpV0dCgFg5xmYf465vFglkYEd1Zf4o0Smssrl9k1iwyKLN6nBNL1v/ WzOfaluDR+BzF/NQbi56xA29miegrCXCwj1/FNmtvwwc0ys/+cy7ODT2GMF0TM2c074dkBgl l73l0MiquuZnS5TM57NLOrtSKNP8VsrGP5jrTdL82taOIzbERQlSNe5KXr38jTzOAp3HyLbm 0UG3TQTB0U/bxF8upQjQ7ZOACqAKAlJm50EzowQi95XCaa2jCPfooDP6Q8CJLkytcv3j3UxX M7NQY9fc2xLvJS0jw/5Kxq166l2Vm7h9L0o9mYb0Jt9ZAgMBAAGjggEFMIIBATASBgNVHRMB Af8ECDAGAQH/AgEAMB0GA1UdDgQWBBSUWsZYybYmm6AJe6gvZJDDiQJuKjAfBgNVHSMEGDAW gBRnqnrP9AqmuXK1iqDSnfIQw0PtKTAOBgNVHQ8BAf8EBAMCAYYwPQYIKwYBBQUHAQEEMTAv MC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8/TExSQ0EwMwYDVR0f BCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNybD9MTFJDQTAnBgNVHSAE IDAeMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0GCSqGSIb3DQEBBQUAA4IBAQBW emGmX0dh9Hk0VAbdYg4eE4WYGEHNEop0NPQTxe6KMztJ3assGoj8ulU0Q9ZqVYZac/iQGdFZ MdZQcbJRTo7TYYdnGMuchPBfgJzRG+IRaSyprulB4MNk+gvdh6CFaewy55wbuP9WP6zbGKK2 UPTFSrvL/8US/y0dzQEYO2uks4tgagNZVoK68fX3nbbQ7Nj7tXGKkoEcj0YvGRk11VZ8bU7s NuPkElLH6xNBpEgNIY5Tb3pKIRsCbH1VtylMjk+bvr6g1mN6ckZvPA1FrBGQiC+QKWNCDiO2 o9J1g2BsgaRBMjqcsnCgorUccE8UGzFIGOhmYPukvkCdwDM6A2GIMIIEQDCCAyigAwIBAgIE PsRfVjANBgkqhkiG9w0BAQUFADA9MQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNv bG4gTGFib3JhdG9yeTENMAsGA1UECxMEbGxjYTAeFw0wODEwMDkxODQ3NDVaFw0xMTExMDMw NDAwMDBaMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5 MQwwCgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDFTikXWLImsvmtir9cEAqD3eQJMBMbsHDQ0YWkQnUDdeyvpQgi r3/VUkE6ALAOqtWwArWVHDL+WSsfM+ShuIyvXDONDbxJH/2yDmQByasyoFhtzfTaq3AIYpnF 012ECHadQ4I7XQAylSwI12mKQ9j26RPyWwD56iszhDWtz8vQnoAdGm05Tsi4MF1mP6101vuC /4YqSevrCP2baxUZrChobsACqGxa9BQz+riH8fkWliXCdUASHYDOGqIb1vCXq4kkjMn/y5Ra V02RXDPUjl9H+8JrGItchbihTJ0G5EpMb56QSjEca4PvfLHkm2xJyJLwdAvagQzy2/5UAL5q VuqDAgMBAAGjggEvMIIBKzAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBhjA8Bggr BgEFBQcBAQQwMC4wLAYIKwYBBQUHMAKGIGh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXR0bz9M TENBMIGJBgNVHR8EgYEwfzBUoFKgUKROMEwxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQg TGluY29sbiBMYWJvcmF0b3J5MQ0wCwYDVQQLEwRsbGNhMQ0wCwYDVQQDEwRDUkwxMCegJaAj hiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvY3JsL2NybC5jcmwwHwYDVR0jBBgwFoAUQojpumqd 0mMlazmqCugCj2cNA3EwHQYDVR0OBBYEFGeqes/0Cqa5crWKoNKd8hDDQ+0pMA0GCSqGSIb3 DQEBBQUAA4IBAQA6BPTctusZX6KcStYDrvAVmjjl+QlgsZWSJ6cIdwFRM8xAQMRJSDFfMvuX WNdu+7M9Mksfea+GBs/E7jWohsj5GavJQeMFydsnDD+s4N0aB5MPnHrPcbmm4HiM1bQHhUJN 9/+i9yQRUN+VapdKpXqzj77yM1B8xG4TL52m2wgavQ6It9gSAVVVqDkucZyrzd1x97ueqxLQ d7KPTD+bvlVhUanJxurkUQ+QskqSazW0y3vJ01FdsNxEFoxOD/AMijYXoBISd/Y5hyiPVK2v V463CRF1b4+wytJP0K3Cv3fNSrkp5DZXXMFBBh64WaU9CbedZXOXzjZcXV0RwTp63rRvMIIE 1TCCA72gAwIBAgIKFU5e0QAAAAAiIDANBgkqhkiG9w0BAQUFADBRMQswCQYDVQQGEwJVUzEf MB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQD EwpNSVRMTCBDQS0xMB4XDTEwMDUyNTIwNDcxN1oXDTExMDUyNTIwNDcxN1owZDELMAkGA1UE BhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3Bs ZTEjMCEGA1UEAxMaSGVyem9nLkpvbmF0aGFuLkMuNTAwMTEzMDUwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQCtC8sNdkCteQagOVEnQQs45uLqsmaOfjqTywNWuvaVj0F8Jsek 8bOcuK4rlB1PrBk0Q+s/N4FVcGEn6BEDWRIDFaETVr1jweTEyRUtqngTIvpbpeixV37BcFkV nbV2VrZC5oaa0c0bkxXkuE0lohQS5AIBXQRADEJVnfXIM44yvsmoT7J5rdGwjIg4QJ2YA07p o0JkbndcylcjU0zW2Lv432MEZrX/o+T0rraFAhT8A+8De9CIo0LJkXCKcNwk6LwuNKQS0qee zDo5wRiqZaht3ftiAuOImOxN44hxnDa2cHVbOFQ+pevN08gH7d39CVHUbHMCPnuIBoQNu61I 2+ItAgMBAAGjggGaMIIBljAOBgNVHQ8BAf8EBAMCBSAwHQYDVR0OBBYEFEuYUJcIJTs8b2SW TJN28DD/qqsNMB8GA1UdIwQYMBaAFJRaxljJtiaboAl7qC9kkMOJAm4qMDMGA1UdHwQsMCow KKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTEwYgYIKwYBBQUHAQEE VjBUMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTEwIwYI KwYBBQUHMAGGF2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvMAwGA1UdEwEB/wQCMAAwPQYJKwYB BAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8dhevQcIPr7SACAWQC AQQwJQYDVR0lBB4wHAYEVR0lAAYIKwYBBQUHAwQGCisGAQQBgjcKAwQwGAYDVR0gBBEwDzAN BgsqhkiG9xICAQMBCDAdBgNVHREEFjAUgRJqaGVyem9nQGxsLm1pdC5lZHUwDQYJKoZIhvcN AQEFBQADggEBAAmf5m3W0Di4aQhLS1e2xejG3MQPQJvWL3dHbnHYG+NDVFWcuqyE5t73eb7n V2UyGRVHDt6MyIquedAPPm86FSPZ6CUGGj5imp9pAu7C+xESBMY4z0k5htK/h5vlSB9X/i3J bXI8KBOioH1QYenMfrvTISmk/+5ABHsMDOpK7//bX66DP+iopoIiWJktY+dfiak7uTZhuYEO mICq4QlP9dDqdPiQGje4Y8xZ45YL6+2Im5GIzuIac/r51YTBuCk+TxTZIITMx+Fr50Ur6s4d OnvApxMR7iZX6oKnmVfXrjFMMQxR1TN5ISUnIoMyID3yCiInqQh6G3WPCAhwa/qG/moxggHl MIIB4QIBATBfMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0 b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTECChVM3JYAAAAAIh8wCQYF Kw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBRewSyzrJdOpdUKYI0U22hsVlaz0DAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMDA2MDgxNjI2MTBaMA0GCSqG SIb3DQEBAQUABIIBAG5HukaWCl7+lf9lmugWCfdgP88YQg/qA21Hs3jPVU/hlh6igSEBtBiy vE55npk0HtuQgVWu1nm3Iz9wilTOn2aRl6krzm0asFXC+hTLeaxebQKdAa5gGjaBq5TXQjcq 1jyW2ra7DDpMGSbiiV3nIo/nFuZRHCB3S07pj8egpST6J0+BSUsGsef60Plv1JmdiWU75R/U 1k6LFCfude9QCzUg92rn/XJKslkef98zJdXVuwa7e/EVJD7MigYDp0us71StGSzrMDAgEb/1 OlPufQ0QY0QOFTn6fUC5RD+srffGvAlKxSccFrQwHc9H0e6Iyphl1mSQX5BMc2jwWtytueE= --B_3358844770_26466005-- From prvs=37752238e7=uri@ll.mit.edu Tue Jun 8 09:28:55 2010 Return-Path: X-Original-To: cicm@core3.amsl.com Delivered-To: cicm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0D793A679F for ; Tue, 8 Jun 2010 09:28:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.847 X-Spam-Level: X-Spam-Status: No, score=-5.847 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_OBFU_ALL=0.751, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZzuPSoDyOgCk for ; Tue, 8 Jun 2010 09:28:55 -0700 (PDT) Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by core3.amsl.com (Postfix) with ESMTP id A482A3A68C3 for ; Tue, 8 Jun 2010 09:28:54 -0700 (PDT) Received: from LLE2K7-HUB02.mitll.ad.local (LLE2K7-HUB02.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id o58GKEOX027511 for ; Tue, 8 Jun 2010 12:28:52 -0400 From: "Blumenthal, Uri - 0668 - MITLL" To: CICM Discussion List Date: Tue, 8 Jun 2010 12:28:39 -0400 Thread-Topic: [cicm] OID for algorithm identifiers? Thread-Index: AcsHJ03D6Zexz+HmeUWW1hgStnDphQAAFjTD Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.4.0.100208 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-06-08_05:2010-02-06, 2010-06-08, 2010-06-08 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1005130000 definitions=main-1006080101 Subject: Re: [cicm] OID for algorithm identifiers? X-BeenThere: cicm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: CICM Discussion List List-Id: CICM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2010 16:28:56 -0000 The only downside (AFAIK) is OID size. Considering many advantages OID offer, I'd say they should be used here. Thanks! --=20 Regards, Uri On 6/8/10 12:26 , "Herzog, Jonathan - 0668 - MITLL" wrote: >=20 > Perusing the CICM spec (http://tools.ietf.org/html/draft-lanz-cicm-00; > please let me know if there is a more recent version) I notice that it > apparently uses chracter-strings for identifying algorithms (Section > 3.2.2.5). Really? Is there a structure to this name-space? Who manages it= ? >=20 > The CMS standard (Cryptographic Message Syntax, RFCs 5652 and 5754 among > many others) have settled on using OIDs for algorithm-identification, whi= ch > seems much saner. Not only are OIDs in a hierarchical ID-space, allowing > control over the name-space to be allocated and delegated among many > organizations, but it would allow CICM a greater compatibility with CMS a= nd > its messages. >=20 > Or is there a downside to OIDs that I don't yet see? >=20 > Thanks. > =20 >=20 From lnovikov@mitre.org Wed Jun 9 13:31:18 2010 Return-Path: X-Original-To: cicm@core3.amsl.com Delivered-To: cicm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 927A03A67A5 for ; Wed, 9 Jun 2010 13:31:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 154JiGm1peMy for ; Wed, 9 Jun 2010 13:31:13 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id D6D203A67AD for ; Wed, 9 Jun 2010 13:31:11 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o59KVCHq027410 for ; Wed, 9 Jun 2010 16:31:13 -0400 Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o59KVCXj027402 for ; Wed, 9 Jun 2010 16:31:12 -0400 Received: from IMCMBX3.MITRE.ORG ([129.83.29.206]) by imchub1.MITRE.ORG ([129.83.29.73]) with mapi; Wed, 9 Jun 2010 16:31:12 -0400 From: "Novikov, Lev" To: CICM Discussion List Date: Wed, 9 Jun 2010 16:29:14 -0400 Thread-Topic: [cicm] OID for algorithm identifiers? Thread-Index: AcsHJ03D6Zexz+HmeUWW1hgStnDphQAAFjTDADor69A= Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [cicm] OID for algorithm identifiers? X-BeenThere: cicm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: CICM Discussion List List-Id: CICM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2010 20:31:18 -0000 On 2010-06-08 12:29, Uri Blumenthal wrote:=20 > The only downside (AFAIK) is OID size. Considering many advantages OID > offer, I'd say they should be used here. On 2010-06-08 12:26, Jonathan Herzog wrote: > [...] uses character-strings for identifying algorithms (Section > 3.2.2.5). Really? Is there a structure to this name-space? Who manages it= ? > > The CMS standard (Cryptographic Message Syntax, RFCs 5652 and 5754 among > many others) have settled on using OIDs for algorithm-identification, whi= ch > seems much saner. Not only are OIDs in a hierarchical ID-space, allowing > control over the name-space to be allocated and delegated among many > organizations, but it would allow CICM a greater compatibility with CMS a= nd > its messages. These are good points. Do people know if the algorithms used in high assurance environments (e.g.,= Suite A in the US, or equivalent in other countries) are identified using = OIDs? If not, we might need some way to distinguish between algorithms identified= using OIDs and those identified as plain strings. Or we could find out how= to leverage the hierarchal nature of OIDs to help specify what the OID "sh= ould be" (or at least avoid conflict with the algorithms used by other orga= nizations). Other ideas? Lev From dol@cryptocom.ru Wed Jun 9 23:51:59 2010 Return-Path: X-Original-To: cicm@core3.amsl.com Delivered-To: cicm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F37E23A68E4 for ; Wed, 9 Jun 2010 23:51:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.471 X-Spam-Level: * X-Spam-Status: No, score=1.471 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Edm9o5VTO+wj for ; Wed, 9 Jun 2010 23:51:58 -0700 (PDT) Received: from mx.cryptocom.ru (mx.cryptocom.ru [89.188.97.107]) by core3.amsl.com (Postfix) with ESMTP id 1C7543A68BF for ; Wed, 9 Jun 2010 23:51:57 -0700 (PDT) Received: from [10.51.22.241] (reedcat.lan.cryptocom.ru [10.51.22.241]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.cryptocom.ru (Postfix) with ESMTP id 1D800465BB for ; Thu, 10 Jun 2010 10:51:57 +0400 (MSD) Message-ID: <4C108B8E.2020802@cryptocom.ru> Date: Thu, 10 Jun 2010 10:51:58 +0400 From: Basil Dolmatov User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100423 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: cicm@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [cicm] OID for algorithm identifiers? X-BeenThere: cicm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: CICM Discussion List List-Id: CICM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2010 06:51:59 -0000 10.06.2010 00:29, Novikov, Lev пишет: > On 2010-06-08 12:29, Uri Blumenthal wrote: >> The only downside (AFAIK) is OID size. Considering many advantages OID >> offer, I'd say they should be used here. > > On 2010-06-08 12:26, Jonathan Herzog wrote: >> [...] uses character-strings for identifying algorithms (Section >> 3.2.2.5). Really? Is there a structure to this name-space? Who manages it? >> >> The CMS standard (Cryptographic Message Syntax, RFCs 5652 and 5754 among >> many others) have settled on using OIDs for algorithm-identification, which >> seems much saner. Not only are OIDs in a hierarchical ID-space, allowing >> control over the name-space to be allocated and delegated among many >> organizations, but it would allow CICM a greater compatibility with CMS and >> its messages. > > These are good points. > > Do people know if the algorithms used in high assurance environments (e.g., Suite A in the US, or equivalent in other countries) are identified using OIDs? > > If not, we might need some way to distinguish between algorithms identified using OIDs and those identified as plain strings. Or we could find out how to leverage the hierarchal nature of OIDs to help specify what the OID "should be" (or at least avoid conflict with the algorithms used by other organizations). > > Other ideas? > Better use OIDs, maybe having some means for creating plain string "aliases" for referring given OIDs dol@ From prvs=37774d2c9b=uri@ll.mit.edu Thu Jun 10 04:10:12 2010 Return-Path: X-Original-To: cicm@core3.amsl.com Delivered-To: cicm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 251C33A6A03 for ; Thu, 10 Jun 2010 04:10:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.923 X-Spam-Level: X-Spam-Status: No, score=-4.923 tagged_above=-999 required=5 tests=[AWL=-0.925, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pU3Q9J82YadL for ; Thu, 10 Jun 2010 04:10:08 -0700 (PDT) Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by core3.amsl.com (Postfix) with ESMTP id DACF63A6955 for ; Thu, 10 Jun 2010 04:10:07 -0700 (PDT) Received: from LLE2K7-HUB01.mitll.ad.local (LLE2K7-HUB01.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id o5AB0to7001314 for ; Thu, 10 Jun 2010 07:10:06 -0400 From: "Blumenthal, Uri - 0668 - MITLL" To: "'cicm@ietf.org'" Date: Thu, 10 Jun 2010 07:09:54 -0400 Thread-Topic: [cicm] OID for algorithm identifiers? Thread-Index: AcsIaW9LNiiEmz4uSWqW8hFhEnjwKwAJATAk Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-06-10_02:2010-02-06, 2010-06-10, 2010-06-09 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1005130000 definitions=main-1006100045 Message-Id: <20100610111007.DACF63A6955@core3.amsl.com> Subject: Re: [cicm] OID for algorithm identifiers? X-BeenThere: cicm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: CICM Discussion List List-Id: CICM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2010 11:10:12 -0000 WWVzIQ0KDQpSZWdhcmRzLA0KVXJpDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCkZy b206IGNpY20tYm91bmNlc0BpZXRmLm9yZyA8Y2ljbS1ib3VuY2VzQGlldGYub3JnPg0KVG86IGNp Y21AaWV0Zi5vcmcgPGNpY21AaWV0Zi5vcmc+DQpTZW50OiBUaHUgSnVuIDEwIDAyOjUxOjU4IDIw MTAKU3ViamVjdDogUmU6IFtjaWNtXSBPSUQgZm9yIGFsZ29yaXRobSBpZGVudGlmaWVycz8NCg0K CgoxMC4wNi4yMDEwIDAwOjI5LCBOb3Zpa292LCBMZXYg0L/QuNGI0LXRgjoKPiBPbiAyMDEwLTA2 LTA4IDEyOjI5LCBVcmkgQmx1bWVudGhhbCB3cm90ZToKPj4gVGhlIG9ubHkgZG93bnNpZGUgKEFG QUlLKSBpcyBPSUQgc2l6ZS4gQ29uc2lkZXJpbmcgbWFueSBhZHZhbnRhZ2VzIE9JRAo+PiBvZmZl ciwgSSdkIHNheSB0aGV5IHNob3VsZCBiZSB1c2VkIGhlcmUuCj4KPiBPbiAyMDEwLTA2LTA4IDEy OjI2LCBKb25hdGhhbiBIZXJ6b2cgd3JvdGU6Cj4+IFsuLi5dIHVzZXMgY2hhcmFjdGVyLXN0cmlu Z3MgZm9yIGlkZW50aWZ5aW5nIGFsZ29yaXRobXMgKFNlY3Rpb24KPj4gMy4yLjIuNSkuIFJlYWxs eT8gSXMgdGhlcmUgYSBzdHJ1Y3R1cmUgdG8gdGhpcyBuYW1lLXNwYWNlPyBXaG8gbWFuYWdlcyBp dD8KPj4KPj4gVGhlIENNUyBzdGFuZGFyZCAoQ3J5cHRvZ3JhcGhpYyBNZXNzYWdlIFN5bnRheCwg UkZDcyA1NjUyIGFuZCA1NzU0IGFtb25nCj4+IG1hbnkgb3RoZXJzKSBoYXZlIHNldHRsZWQgb24g dXNpbmcgT0lEcyBmb3IgYWxnb3JpdGhtLWlkZW50aWZpY2F0aW9uLCB3aGljaAo+PiBzZWVtcyBt dWNoIHNhbmVyLiBOb3Qgb25seSBhcmUgT0lEcyBpbiBhIGhpZXJhcmNoaWNhbCBJRC1zcGFjZSwg YWxsb3dpbmcKPj4gY29udHJvbCBvdmVyIHRoZSBuYW1lLXNwYWNlIHRvIGJlIGFsbG9jYXRlZCBh bmQgZGVsZWdhdGVkIGFtb25nIG1hbnkKPj4gb3JnYW5pemF0aW9ucywgYnV0IGl0IHdvdWxkIGFs bG93IENJQ00gYSBncmVhdGVyIGNvbXBhdGliaWxpdHkgd2l0aCBDTVMgYW5kCj4+IGl0cyBtZXNz YWdlcy4KPgo+IFRoZXNlIGFyZSBnb29kIHBvaW50cy4KPgo+IERvIHBlb3BsZSBrbm93IGlmIHRo ZSBhbGdvcml0aG1zIHVzZWQgaW4gaGlnaCBhc3N1cmFuY2UgZW52aXJvbm1lbnRzIChlLmcuLCBT dWl0ZSBBIGluIHRoZSBVUywgb3IgZXF1aXZhbGVudCBpbiBvdGhlciBjb3VudHJpZXMpIGFyZSBp ZGVudGlmaWVkIHVzaW5nIE9JRHM/Cj4KPiBJZiBub3QsIHdlIG1pZ2h0IG5lZWQgc29tZSB3YXkg dG8gZGlzdGluZ3Vpc2ggYmV0d2VlbiBhbGdvcml0aG1zIGlkZW50aWZpZWQgdXNpbmcgT0lEcyBh bmQgdGhvc2UgaWRlbnRpZmllZCBhcyBwbGFpbiBzdHJpbmdzLiBPciB3ZSBjb3VsZCBmaW5kIG91 dCBob3cgdG8gbGV2ZXJhZ2UgdGhlIGhpZXJhcmNoYWwgbmF0dXJlIG9mIE9JRHMgdG8gaGVscCBz cGVjaWZ5IHdoYXQgdGhlIE9JRCAic2hvdWxkIGJlIiAob3IgYXQgbGVhc3QgYXZvaWQgY29uZmxp Y3Qgd2l0aCB0aGUgYWxnb3JpdGhtcyB1c2VkIGJ5IG90aGVyIG9yZ2FuaXphdGlvbnMpLgo+Cj4g T3RoZXIgaWRlYXM/Cj4KQmV0dGVyIHVzZSBPSURzLCBtYXliZSBoYXZpbmcgc29tZSBtZWFucyBm b3IgY3JlYXRpbmcgcGxhaW4gc3RyaW5nIAoiYWxpYXNlcyIgZm9yIHJlZmVycmluZyBnaXZlbiBP SURzCgpkb2xACgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f XwpjaWNtIG1haWxpbmcgbGlzdApjaWNtQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vY2ljbQo= From lnovikov@mitre.org Wed Jun 16 07:53:37 2010 Return-Path: X-Original-To: cicm@core3.amsl.com Delivered-To: cicm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E4AB3A68ED for ; Wed, 16 Jun 2010 07:53:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ww3iFUyDl2cc for ; Wed, 16 Jun 2010 07:53:36 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id D0FF53A691B for ; Wed, 16 Jun 2010 07:53:36 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o5GErf2m028889 for ; Wed, 16 Jun 2010 10:53:41 -0400 Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o5GErf10028886 for ; Wed, 16 Jun 2010 10:53:41 -0400 Received: from IMCMBX3.MITRE.ORG ([129.83.29.206]) by imchub2.MITRE.ORG ([129.83.29.74]) with mapi; Wed, 16 Jun 2010 10:53:41 -0400 From: "Novikov, Lev" To: CICM Discussion List Date: Wed, 16 Jun 2010 10:51:31 -0400 Thread-Topic: [cicm] OID for algorithm identifiers? Thread-Index: AcsIaXCZMIl0YhCjRwSwo0qpM+EENAE9/joQ Message-ID: References: <4C108B8E.2020802@cryptocom.ru> In-Reply-To: <4C108B8E.2020802@cryptocom.ru> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [cicm] OID for algorithm identifiers? X-BeenThere: cicm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: CICM Discussion List List-Id: CICM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2010 14:53:37 -0000 T24gVGh1LCAyMDEwLTA2LTEwIDAyOjUyIEJhc2lsIERvbG1hdG92IHdyb3RlOg0KPiBCZXR0ZXIg dXNlIE9JRHMsIG1heWJlIGhhdmluZyBzb21lIG1lYW5zIGZvciBjcmVhdGluZyBwbGFpbiBzdHJp bmcgDQo+ICJhbGlhc2VzIiBmb3IgcmVmZXJyaW5nIGdpdmVuIE9JRHMNCg0KSW5zdGVhZCBvZiBh bGlhc2VzLCBJIHByb3Bvc2UgdGhlIGZvbGxvd2luZzoNCg0KMS4gQWxnb3JpdGhtcyBTSE9VTEQg YmUgbmFtZWQgdXNpbmcgdGhlaXIgT0lEIHByZWZpeGVkIHdpdGggIm9pZDoiDQoyLiBXaGVyZSBh biBPSUQgaXMgdW5hdmFpbGFibGUsIGFsZ29yaXRobXMgU0hPVUxEIGJlIG5hbWVkIHdpdGggIm5h bWU6IiANCglmb2xsb3dlZCBieSBhIGh1bWFuLXJlYWRhYmxlIGFsZ29yaXRobSBuYW1lIGFuZCBt b2RlIHNlcGFyYXRlZCB3aXRoIGRhc2hlcy4NCgkoVGhpcyBpcyB0aGUgY3VycmVudCBtZXRob2Qg b2YgbmFtaW5nIGFsZ29yaXRobXMgaW4gU2VjdGlvbiA0LjEuMykNCg0KRVhBTVBMRToNClNIQS0y NTY6DQoJIm9pZDoyLjE2Ljg0MC4xLjEwMS4zLjQuMi4xIiAocHJlZmVycmVkKQ0KT1IJIm5hbWU6 U0hBLTI1NiIgKGFjY2VwdGFibGUpDQoNClJlZ2FyZGxlc3Mgb2Ygd2hpY2ggbWV0aG9kIGlzIHVz ZWQsIHRoZSBleGFjdCBzdHJpbmdzIGF2YWlsYWJsZSBmb3IgdXNlDQpNVVNUIGJlIGRvY3VtZW50 ZWQgaW4gdGhlIEltcGxlbWVudGF0aW9uIENvbmZvcm1hbmNlIFN0YXRlbWVudCAoSUNTKS4NCg0K SG93IGRvZXMgdGhhdCBzb3VuZD8NCg0KTGV2DQo= From jfitton@rochester.rr.com Wed Jun 16 11:24:28 2010 Return-Path: X-Original-To: cicm@core3.amsl.com Delivered-To: cicm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FC9E3A6B7F for ; Wed, 16 Jun 2010 11:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.501 X-Spam-Level: *** X-Spam-Status: No, score=3.501 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fe9zo1fFykXi for ; Wed, 16 Jun 2010 11:24:19 -0700 (PDT) Received: from hrndva-omtalb.mail.rr.com (hrndva-omtalb.mail.rr.com [71.74.56.124]) by core3.amsl.com (Postfix) with ESMTP id AC0D53A6B85 for ; Wed, 16 Jun 2010 11:24:19 -0700 (PDT) X-Authority-Analysis: v=1.1 cv=I1wgP7vb7Y9JOn/mmmkmB2mXFOTL2SFQ5cjyLjGRNmo= c=1 sm=0 a=mI6YO6ZdSLUA:10 a=F7Q6sNaYBjnbJoVGTozFug==:17 a=VB-4EEXzNdZSp27r9C0A:9 a=ZA9TPDDiHO-bjmy05dobvJ230agA:4 a=CjuIK1q_8ugA:10 a=SSmOFEACAAAA:8 a=e79IPonrj8Y6qOo5yLcA:9 a=LHdCeG61X7xbQ8fN1YUA:7 a=vBOGxsW6okdHqjufhMxwUf6LcN0A:4 a=F7Q6sNaYBjnbJoVGTozFug==:117 X-Cloudmark-Score: 0 X-Originating-IP: 67.242.165.23 Received: from [67.242.165.23] ([67.242.165.23:1937] helo=JohnsOffice) by hrndva-oedge02.mail.rr.com (envelope-from ) (ecelerity 2.2.2.39 r()) with ESMTP id CD/E6-21121-7D6191C4; Wed, 16 Jun 2010 18:24:24 +0000 X-Vipre-Scanned: 1D5F5BFE0017EF1D5F5D4B-TDI From: "John Fitton" To: Date: Wed, 16 Jun 2010 14:24:21 -0400 Message-ID: <03E2EBA9849D4A99A87E88D329BF0E71@JohnsOffice> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0126_01CB0D5F.9D368040" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Thread-Index: AcsNgSQME8R/rquMRTC1RMlO7383Zg== X-Mailman-Approved-At: Wed, 16 Jun 2010 11:33:05 -0700 Subject: [cicm] Red side versus Black side API X-BeenThere: cicm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: CICM Discussion List List-Id: CICM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2010 18:30:40 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0126_01CB0D5F.9D368040 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit >From a security design perspective one can envision the need to protect all control functions which would seem to favor "red side" control. However in the software radio world some of the waveform (air interface) applications need to have some of the control API's present on the "black side" and others on the "red" with others on both sides. While most control functions are unclassified, some may need to handle classified configuration data. >From my experience base, I believe that the API functions should be agnostic as to whether or not they are red or black side because typically they will be on the side that needs them and this is a function of the security architecture. I think the model to consider is as follows because it eliminates red/black terminology which is typically misused. Consider a MILS (Multiple Independent Levels of Security) environment using a high assurance separation kernel in which all domains share the same processor, each in their own partition, and the OS maintains the required separation between the partitions. One of the partitions could even be a 100% software based crypto. The system would include "Reference Monitor" functions to support cross domain communications to the extent that these are required and allowed. In this environment, the terms red and black are indeed meaningless from an API perspective. In a high assurance environment which employs machine interpretable explicit security policy statements, the security policy for a given application/waveform could define the rule set that specifies which API's are available in what is typically the "plaintext" space vs. the "cipher text" space. I use the word "typically" because the in the JTRS Software Communications Architecture Security Services API (note: the API was subsequently withdrawn from the SCA), if you recall, supported encrypting data and returning the cipher text back to the same side from which the plaintext was submitted. There is also an interesting notion that one could take unclassified data and store it in a protected "red side" database containing classified data by encrypting it from "black to red" and when retrieving it siply decrypt it from "red to black". This process completely avoids the need for bypass and write-up/down operations which are typically hard to do in this kind of situation. John Fitton Harris Fellow, Senior Scientist Harris RF Communications ------=_NextPart_000_0126_01CB0D5F.9D368040 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

From a security design perspective one can envision the need to = protect all control functions which would seem to favor "red side" = control. However in the software radio world some of the waveform (air interface) = applications need to have some of the control API's present on the "black side" and others on the "red" with others on both sides. = While most control functions are unclassified, some may need to handle = classified configuration data.

From my experience base, I believe that the API functions should = be agnostic as to whether or not they are red or black side because = typically they will be on the side that needs them and this is a function of the = security architecture. I think the model to consider is as follows because = it eliminates red/black terminology which is typically misused. =

Consider a MILS (Multiple Independent Levels of Security) = environment using a high assurance separation kernel in which all domains share the = same processor, each in their own partition, and the OS maintains the = required separation between the partitions. One of the partitions could = even be a 100% software based crypto. The system would include "Reference Monitor" functions to support cross domain communications to the = extent that these are required and allowed. In this environment, the terms red = and black are indeed meaningless from an API perspective. =

In a high assurance environment which employs machine = interpretable explicit security policy statements, the security policy for a given application/waveform could define the rule set that specifies which = API's are available in what is typically the "plaintext” space vs. the "cipher text" space.

I use the word "typically" because the in the = JTRS Software Communications Architecture Security Services API (note: the API was = subsequently withdrawn from the SCA), if you recall, supported encrypting data and = returning the cipher text back to the same side from which the plaintext was = submitted. There is also an interesting notion that one could take unclassified = data and store it in a protected "red side" database containing = classified data by encrypting it from "black to red" and when retrieving = it siply decrypt it from "red to black". This process completely = avoids the need for bypass and write-up/down operations which are typically = hard to do in this kind of situation.

John Fitton

Harris Fellow, Senior Scientist

Harris RF Communications

------=_NextPart_000_0126_01CB0D5F.9D368040-- From jfitton@harris.com Wed Jun 16 11:35:38 2010 Return-Path: X-Original-To: cicm@core3.amsl.com Delivered-To: cicm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8CF828C147 for ; Wed, 16 Jun 2010 11:35:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.5 X-Spam-Level: *** X-Spam-Status: No, score=3.5 tagged_above=-999 required=5 tests=[BAYES_99=3.5] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Spl7AFP88mss for ; Wed, 16 Jun 2010 11:35:37 -0700 (PDT) Received: from mlbe2k1.cs.myharris.net (mlbe2k1.cs.myharris.net [137.237.90.88]) by core3.amsl.com (Postfix) with ESMTP id 37FAC28C166 for ; Wed, 16 Jun 2010 11:35:37 -0700 (PDT) Received: from mail pickup service by mlbe2k1.cs.myharris.net with Microsoft SMTPSVC; Wed, 16 Jun 2010 14:35:41 -0400 Received: from roce2k4.cs.myharris.net ([147.177.32.37]) by mlbe2k1.cs.myharris.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Jun 2010 14:35:39 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 16 Jun 2010 14:35:37 -0400 Message-ID: <8CBBCF54EC560B479037451B6F1AA4F5016B64ED@roce2k4.cs.myharris.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [cicm] Does CICM only provide (specify) the "red" side API in a multilevel system? Thread-Index: AcsNgra2lFtoPnG0Sb2mC5zD9Fw/4g== From: "Fitton, John" To: X-OriginalArrivalTime: 16 Jun 2010 18:35:39.0798 (UTC) FILETIME=[B83B1360:01CB0D82] Subject: Re: [cicm] Does CICM only provide (specify) the "red" side API in a multilevel system? X-BeenThere: cicm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: CICM Discussion List List-Id: CICM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2010 18:35:38 -0000 >From a security design perspective one can envision the need to protect = all control functions which would seem to favor "red side" control. = However in the software radio world some of the waveform (air interface) = applications need to have some of the control API's present on the = "black side" and others on the "red" with others on both sides. While = most control functions are unclassified, some may need to handle = classified configuration data. From my experience base, I believe that the API functions should be = agnostic as to whether or not they are red or black side because = typically they will be on the side that needs them and this is a = function of the security architecture. I think the model to consider is = as follows because it eliminates red/black terminology which is = typically misused.=20 Consider a MILS (Multiple Independent Levels of Security) environment = using a high assurance separation kernel in which all domains share the = same processor, each in their own partition, and the OS maintains the = required separation between the partitions. One of the partitions could = even be a 100% software based crypto. The system would include = "Reference Monitor" functions to support cross domain communications to = the extent that these are required and allowed. In this environment, the = terms red and black are indeed meaningless from an API perspective.=20 In a high assurance environment which employs machine interpretable = explicit security policy statements, the security policy for a given = application/waveform could define the rule set that specifies which = API's are available in what is typically the "plaintext" space vs. the = "cipher text" space. I use the word "typically" because the in the JTRS Software = Communications Architecture Security Services API (note: the API was = subsequently withdrawn from the SCA), if you recall, supported = encrypting data and returning the cipher text back to the same side from = which the plaintext was submitted. There is also an interesting notion = that one could take unclassified data and store it in a protected "red = side" database containing classified data by encrypting it from "black = to red" and when retrieving it siply decrypt it from "red to black". = This process completely avoids the need for bypass and write-up/down = operations which are typically hard to do in this kind of situation. =20 John Fitton Harris Fellow, Senior Scientist Harris RF Communications =20 From jfitton@harris.com Wed Jun 16 12:08:31 2010 Return-Path: X-Original-To: cicm@core3.amsl.com Delivered-To: cicm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C034F28C123 for ; Wed, 16 Jun 2010 12:08:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.657 X-Spam-Level: * X-Spam-Status: No, score=1.657 tagged_above=-999 required=5 tests=[AWL=1.843, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qajOTmcrHNeW for ; Wed, 16 Jun 2010 12:08:30 -0700 (PDT) Received: from mlbe2k1.cs.myharris.net (mlbe2k1.cs.myharris.net [137.237.90.88]) by core3.amsl.com (Postfix) with ESMTP id BA02F3A6B96 for ; Wed, 16 Jun 2010 12:08:30 -0700 (PDT) Received: from mail pickup service by mlbe2k1.cs.myharris.net with Microsoft SMTPSVC; Wed, 16 Jun 2010 15:08:30 -0400 Received: from roce2k4.cs.myharris.net ([147.177.32.37]) by mlbe2k1.cs.myharris.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Jun 2010 15:08:28 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 16 Jun 2010 15:08:26 -0400 Message-ID: <8CBBCF54EC560B479037451B6F1AA4F5016B64EE@roce2k4.cs.myharris.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Sorry for double posting Thread-Index: AcsNh0wj6TFCfFiLQjaEBw1YRU1guA== From: "Fitton, John" To: X-OriginalArrivalTime: 16 Jun 2010 19:08:28.0845 (UTC) FILETIME=[4DDFCDD0:01CB0D87] Subject: [cicm] Sorry for double posting X-BeenThere: cicm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: CICM Discussion List List-Id: CICM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2010 19:08:31 -0000 I sent the first from my home e-mail and I thought I had cancelled the = posting. The two are slightly different. From lnovikov@mitre.org Wed Jun 16 12:34:24 2010 Return-Path: X-Original-To: cicm@core3.amsl.com Delivered-To: cicm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2ACC428C16E for ; Wed, 16 Jun 2010 12:34:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x1RoqvvK5H61 for ; Wed, 16 Jun 2010 12:34:18 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 9127528C167 for ; Wed, 16 Jun 2010 12:34:18 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o5GJYNGC028813 for ; Wed, 16 Jun 2010 15:34:23 -0400 Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o5GJYNLF028799 for ; Wed, 16 Jun 2010 15:34:23 -0400 Received: from IMCMBX3.MITRE.ORG ([129.83.29.206]) by imchub1.MITRE.ORG ([129.83.29.73]) with mapi; Wed, 16 Jun 2010 15:34:22 -0400 From: "Novikov, Lev" To: CICM Discussion List Date: Wed, 16 Jun 2010 15:32:28 -0400 Thread-Topic: Channel I/O Thread-Index: AcsNiqgKVEh7aU+GQEi8lBy2F90Tbg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [cicm] Channel I/O X-BeenThere: cicm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: CICM Discussion List List-Id: CICM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2010 19:34:24 -0000 Terminology: - CHANNEL: the most general abstraction for a connection between a module a= nd software. - CONTROLLER: a channel that has management capabilities. - STREAM: a channel that has data-passing (sending, receiving or both) capa= bilities. - CONDUIT: the channel that has both management and data-passing capabiliti= es=20 (the logical union of a controller and stream). (See: Section 2.3.3, http://tools.ietf.org/html/draft-lanz-cicm-00#section-= 2.3.3) I/O, therefore, is done primarily by a stream or a conduit and consists of = two modes: blocking and non-blocking. BLOCKING refers to a mode where the method does = not=20 return until the buffer is full. For example, Decrypt::Stream::decrypt() does not return until the buffer is full (or an error occurs). Similarly, Encrypt::Stream::encrypt() does not return until the operation completes (o= r an error occurs). NON-BLOCKING refers to a mode where a buffer is registered, and periodicall= y polled to determine its status. Decrypt::Stream::decrypt_non_blocking() performs t= he registration/filling while Decrypt::Stream::decrypt_poll() returns the stat= us. Encrypt::Stream::encrypt_non_blocking() and Encrypt::Stream_encrypt_poll()= =20 perform in a similar fashion. * Are these modes sufficient; are others necessary? * Are there any implementation issues with these modes? Lev From lnovikov@mitre.org Wed Jun 16 13:04:17 2010 Return-Path: X-Original-To: cicm@core3.amsl.com Delivered-To: cicm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D163828C18A for ; Wed, 16 Jun 2010 13:04:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.554 X-Spam-Level: X-Spam-Status: No, score=-4.554 tagged_above=-999 required=5 tests=[AWL=0.556, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nCZCv+mZPJU2 for ; Wed, 16 Jun 2010 13:04:17 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id DB9273A6BC3 for ; Wed, 16 Jun 2010 13:04:16 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o5GK4LFC027490 for ; Wed, 16 Jun 2010 16:04:21 -0400 Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o5GK4LdY027487 for ; Wed, 16 Jun 2010 16:04:21 -0400 Received: from IMCMBX3.MITRE.ORG ([129.83.29.206]) by imchub2.MITRE.ORG ([129.83.29.74]) with mapi; Wed, 16 Jun 2010 16:04:21 -0400 From: "Novikov, Lev" To: CICM Discussion List Date: Wed, 16 Jun 2010 16:02:19 -0400 Thread-Topic: Proposed Changes for -01 Draft Thread-Index: AcsNjtNpGZlyhFh1Rzevq7PWU8CNHA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [cicm] Proposed Changes for -01 Draft X-BeenThere: cicm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: CICM Discussion List List-Id: CICM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2010 20:04:17 -0000 We've got about three weeks to put together a -01 draft (due before 2010-07-08 when the current draft expires). Here are the currently proposed changes: - Add OIDs as the primary method for identifying algorithms. - Add complete IDL file as an appendix. - Add terms as an appendix (previously excluded by accident) - Convert diagrams to ASCII art (any volunteers?) - Fix a few typographical errors. Anything else? Now is the time to provide your feedback! Lev From dlanz@mitre.org Wed Jun 16 13:05:24 2010 Return-Path: X-Original-To: cicm@core3.amsl.com Delivered-To: cicm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 936E53A6BC3 for ; Wed, 16 Jun 2010 13:05:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id euAkMxsaIBri for ; Wed, 16 Jun 2010 13:05:23 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 6B40A3A6BBF for ; Wed, 16 Jun 2010 13:05:23 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o5GK5SdC028598 for ; Wed, 16 Jun 2010 16:05:28 -0400 Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o5GK5S0A028592 for ; Wed, 16 Jun 2010 16:05:28 -0400 Received: from IMCMBX1.MITRE.ORG ([129.83.29.204]) by imchub2.MITRE.ORG ([129.83.29.74]) with mapi; Wed, 16 Jun 2010 16:05:28 -0400 From: "Lanz, Dan" To: CICM Discussion List Date: Wed, 16 Jun 2010 16:05:25 -0400 Thread-Topic: [cicm] Does CICM only provide (specify) the "red" side API in a multilevel system? Thread-Index: AcsNgra2lFtoPnG0Sb2mC5zD9Fw/4gACJAnA Message-ID: <3FF9F74E63A7484EB3B88F04329CBEDC02B3FBAEA0@IMCMBX1.MITRE.ORG> References: <8CBBCF54EC560B479037451B6F1AA4F5016B64ED@roce2k4.cs.myharris.net> In-Reply-To: <8CBBCF54EC560B479037451B6F1AA4F5016B64ED@roce2k4.cs.myharris.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [cicm] Does CICM only provide (specify) the "red" side API in a multilevel system? X-BeenThere: cicm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: CICM Discussion List List-Id: CICM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2010 20:05:24 -0000 John, I tend to agree. My concern is that whatever allocation of specific functi= ons to either the "red" or "black" sides we devised would inevitably result= in choices that would not work for certain architectures. I think realisti= cally we would have to allocate a large proportion of the functions to "bot= h" sides, significantly reducing the value of the allocation exercise. As I stated in an earlier post, I think there is a good compromise here. T= he CICM specification requires a crypto vendor shipping a CICM-conformant l= ibrary to list those functions that were implemented to a medium level of g= ranularity (see the CICM "Conformance" section). The compromise is to make= the following changes: 1) increase the granularity of the functions listed= in the conformance section so every CICM function is listed and 2) require= that, in addition to stating whether the function is implemented or not, s= tate whether the function is available on the red, black, or both sides. Does this seem reasonable?=20 Dan -----Original Message----- From: cicm-bounces@ietf.org [mailto:cicm-bounces@ietf.org] On Behalf Of Fit= ton, John Sent: Wednesday, June 16, 2010 2:36 PM To: cicm@ietf.org Subject: Re: [cicm] Does CICM only provide (specify) the "red" side API in = a multilevel system? >From a security design perspective one can envision the need to protect all= control functions which would seem to favor "red side" control. However in= the software radio world some of the waveform (air interface) applications= need to have some of the control API's present on the "black side" and ot= hers on the "red" with others on both sides. While most control functions a= re unclassified, some may need to handle classified configuration data. From my experience base, I believe that the API functions should be agnost= ic as to whether or not they are red or black side because typically they w= ill be on the side that needs them and this is a function of the security a= rchitecture. I think the model to consider is as follows because it elimin= ates red/black terminology which is typically misused.=20 Consider a MILS (Multiple Independent Levels of Security) environment usin= g a high assurance separation kernel in which all domains share the same pr= ocessor, each in their own partition, and the OS maintains the required sep= aration between the partitions. One of the partitions could even be a 100%= software based crypto. The system would include "Reference Monitor" functi= ons to support cross domain communications to the extent that these are req= uired and allowed. In this environment, the terms red and black are indeed = meaningless from an API perspective.=20 In a high assurance environment which employs machine interpretable explici= t security policy statements, the security policy for a given application/w= aveform could define the rule set that specifies which API's are available = in what is typically the "plaintext" space vs. the "cipher text" space. I use the word "typically" because the in the JTRS Software Communication= s Architecture Security Services API (note: the API was subsequently withdr= awn from the SCA), if you recall, supported encrypting data and returning t= he cipher text back to the same side from which the plaintext was submitted= . There is also an interesting notion that one could take unclassified dat= a and store it in a protected "red side" database containing classified dat= a by encrypting it from "black to red" and when retrieving it siply decrypt= it from "red to black". This process completely avoids the need for bypas= s and write-up/down operations which are typically hard to do in this kind = of situation. =20 John Fitton Harris Fellow, Senior Scientist Harris RF Communications =20 _______________________________________________ cicm mailing list cicm@ietf.org https://www.ietf.org/mailman/listinfo/cicm From dlanz@mitre.org Thu Jun 17 09:30:42 2010 Return-Path: X-Original-To: cicm@core3.amsl.com Delivered-To: cicm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 238273A6863 for ; Thu, 17 Jun 2010 09:30:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.554 X-Spam-Level: X-Spam-Status: No, score=-4.554 tagged_above=-999 required=5 tests=[AWL=0.556, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3lZCRyxm86mV for ; Thu, 17 Jun 2010 09:30:41 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 21EEE28C110 for ; Thu, 17 Jun 2010 09:30:34 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o5HGUcJF012674 for ; Thu, 17 Jun 2010 12:30:38 -0400 Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o5HGUcKE012671 for ; Thu, 17 Jun 2010 12:30:38 -0400 Received: from IMCMBX1.MITRE.ORG ([129.83.29.204]) by imchub1.MITRE.ORG ([129.83.29.73]) with mapi; Thu, 17 Jun 2010 12:30:37 -0400 From: "Lanz, Dan" To: CICM Discussion List Date: Thu, 17 Jun 2010 12:30:36 -0400 Thread-Topic: Channel I/O Thread-Index: AcsNiqgKVEh7aU+GQEi8lBy2F90TbgArlZLg Message-ID: <3FF9F74E63A7484EB3B88F04329CBEDC02B3FBB1ED@IMCMBX1.MITRE.ORG> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [cicm] Channel I/O X-BeenThere: cicm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: CICM Discussion List List-Id: CICM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2010 16:30:42 -0000 Another related question is whether the I/O functions have been defined for= maximum performance. Consider CICM::Encrypt::Stream::encrypt(), which acc= epts data for encryption, and CICM::Decrypt::Stream::decrypt(), which recei= ves decrypted data. Are the IDL definitions such that a high performance i= mplementation would be possible? Dan -----Original Message----- From: cicm-bounces@ietf.org [mailto:cicm-bounces@ietf.org] On Behalf Of Nov= ikov, Lev Sent: Wednesday, June 16, 2010 3:32 PM To: CICM Discussion List Subject: [cicm] Channel I/O Terminology: - CHANNEL: the most general abstraction for a connection between a module a= nd software. - CONTROLLER: a channel that has management capabilities. - STREAM: a channel that has data-passing (sending, receiving or both) capa= bilities. - CONDUIT: the channel that has both management and data-passing capabiliti= es=20 (the logical union of a controller and stream). (See: Section 2.3.3, http://tools.ietf.org/html/draft-lanz-cicm-00#section-= 2.3.3) I/O, therefore, is done primarily by a stream or a conduit and consists of = two modes: blocking and non-blocking. BLOCKING refers to a mode where the method does = not=20 return until the buffer is full. For example, Decrypt::Stream::decrypt() does not return until the buffer is full (or an error occurs). Similarly, Encrypt::Stream::encrypt() does not return until the operation completes (o= r an error occurs). NON-BLOCKING refers to a mode where a buffer is registered, and periodicall= y polled to determine its status. Decrypt::Stream::decrypt_non_blocking() performs t= he registration/filling while Decrypt::Stream::decrypt_poll() returns the stat= us. Encrypt::Stream::encrypt_non_blocking() and Encrypt::Stream_encrypt_poll()= =20 perform in a similar fashion. * Are these modes sufficient; are others necessary? * Are there any implementation issues with these modes? Lev _______________________________________________ cicm mailing list cicm@ietf.org https://www.ietf.org/mailman/listinfo/cicm From Joe.Mitola@stevens.edu Thu Jun 17 12:11:01 2010 Return-Path: X-Original-To: cicm@core3.amsl.com Delivered-To: cicm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E729C3A699F for ; Thu, 17 Jun 2010 12:11:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l2+UgGgqnbJj for ; Thu, 17 Jun 2010 12:10:59 -0700 (PDT) Received: from nexus.stevens.edu (nexus.stevens.edu [155.246.14.12]) by core3.amsl.com (Postfix) with ESMTP id 792BB3A691E for ; Thu, 17 Jun 2010 12:10:59 -0700 (PDT) Received: from [155.246.152.137] by nexus.stevens.edu (iPlanet Messaging Server 5.2 HotFix 2.04 (built Feb 8 2005)) with ESMTPSA id <0L460033GAHBM1@nexus.stevens.edu> for cicm@ietf.org; Thu, 17 Jun 2010 15:08:00 -0400 (EDT) Date: Thu, 17 Jun 2010 15:07:58 -0400 From: "Dr. Joe Mitola" In-reply-to: <3FF9F74E63A7484EB3B88F04329CBEDC02B3FBB1ED@IMCMBX1.MITRE.ORG> To: CICM Discussion List Message-id: <4C1A728E.5000108@stevens.edu> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) References: <3FF9F74E63A7484EB3B88F04329CBEDC02B3FBB1ED@IMCMBX1.MITRE.ORG> X-Mailman-Approved-At: Thu, 17 Jun 2010 12:27:50 -0700 Subject: Re: [cicm] Channel I/O X-BeenThere: cicm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: CICM Discussion List List-Id: CICM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2010 19:26:06 -0000 Just my two cents, but: Realization of IO functions depends on the sophistication of the implementer and perhaps on the insights and proclivities of the acquisition and regulatory bodies. IDL definitions can be interpreted as "how" meaning that given IDL, one must use CORBA to realize the interface, and that can be incredibly inefficient. Alternatively, IDL definitions can be interpreted as "what" so that if two applications exist in the same processor or in two different processors that share memory, one may "compile out" the IDL and the CORBA by providing a direct DMA/interrupt based path between the two processors, app to app, with microsecond class latency versus CORBAs order of magnitude or worse overhead. The speeds of the hardware and the IDL are independent as well, so unless the IDL attempts to constrain the implementations aggressively, there is no reason that IDL precludes high performance. However, if institutions (like a defence department) choose to interpret IDL as how versus what, then this unnecessarily constrains realizations. So unless we do something aggressive with IDL to constrain the implementations, there's nothing inherent in CORBA or IDL that forces inefficiency. At least this is the experience of the radio engineering community with the OMG SRA (software radio architecture). joe Dr. Joseph Mitola III, Fellow of the IEEE Distinguished Professor Charles V. Schaefer, Jr. School of Engineering and Science School of Systems and Enterprises Vice President for the Research Enterprise Stevens Institute of Technology Castle Point on Hudson, Hoboken, NJ, USA Cell: 703-314-5709 Lanz, Dan wrote: > Another related question is whether the I/O functions have been defined for maximum performance. Consider CICM::Encrypt::Stream::encrypt(), which accepts data for encryption, and CICM::Decrypt::Stream::decrypt(), which receives decrypted data. Are the IDL definitions such that a high performance implementation would be possible? > > Dan > > -----Original Message----- > From: cicm-bounces@ietf.org [mailto:cicm-bounces@ietf.org] On Behalf Of Novikov, Lev > Sent: Wednesday, June 16, 2010 3:32 PM > To: CICM Discussion List > Subject: [cicm] Channel I/O > > Terminology: > - CHANNEL: the most general abstraction for a connection between a module and software. > - CONTROLLER: a channel that has management capabilities. > - STREAM: a channel that has data-passing (sending, receiving or both) capabilities. > - CONDUIT: the channel that has both management and data-passing capabilities > (the logical union of a controller and stream). > > (See: Section 2.3.3, http://tools.ietf.org/html/draft-lanz-cicm-00#section-2.3.3) > > I/O, therefore, is done primarily by a stream or a conduit and consists of two modes: > blocking and non-blocking. BLOCKING refers to a mode where the method does not > return until the buffer is full. For example, Decrypt::Stream::decrypt() > does not return until the buffer is full (or an error occurs). Similarly, > Encrypt::Stream::encrypt() does not return until the operation completes (or > an error occurs). > > NON-BLOCKING refers to a mode where a buffer is registered, and periodically polled > to determine its status. Decrypt::Stream::decrypt_non_blocking() performs the > registration/filling while Decrypt::Stream::decrypt_poll() returns the status. > Encrypt::Stream::encrypt_non_blocking() and Encrypt::Stream_encrypt_poll() > perform in a similar fashion. > > * Are these modes sufficient; are others necessary? > * Are there any implementation issues with these modes? > > Lev > _______________________________________________ > cicm mailing list > cicm@ietf.org > https://www.ietf.org/mailman/listinfo/cicm > > _______________________________________________ > cicm mailing list > cicm@ietf.org > https://www.ietf.org/mailman/listinfo/cicm > From lnovikov@mitre.org Thu Jun 17 12:35:04 2010 Return-Path: X-Original-To: cicm@core3.amsl.com Delivered-To: cicm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C82C3A6989 for ; Thu, 17 Jun 2010 12:35:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.231 X-Spam-Level: X-Spam-Status: No, score=-4.231 tagged_above=-999 required=5 tests=[AWL=-0.046, BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YE-4IU+78MHD for ; Thu, 17 Jun 2010 12:35:03 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 52FF43A69D1 for ; Thu, 17 Jun 2010 12:35:03 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o5HJZ83B014090 for ; Thu, 17 Jun 2010 15:35:08 -0400 Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o5HJZ8cF014087 for ; Thu, 17 Jun 2010 15:35:08 -0400 Received: from IMCMBX3.MITRE.ORG ([129.83.29.206]) by imchub2.MITRE.ORG ([129.83.29.74]) with mapi; Thu, 17 Jun 2010 15:35:08 -0400 From: "Novikov, Lev" To: CICM Discussion List Date: Thu, 17 Jun 2010 15:32:53 -0400 Thread-Topic: [cicm] Channel I/O Thread-Index: AcsOUzHdA1j+P/6jSBesHM3W6miL2wAAC29w Message-ID: References: <3FF9F74E63A7484EB3B88F04329CBEDC02B3FBB1ED@IMCMBX1.MITRE.ORG> <4C1A728E.5000108@stevens.edu> In-Reply-To: <4C1A728E.5000108@stevens.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [cicm] Channel I/O X-BeenThere: cicm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: CICM Discussion List List-Id: CICM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2010 19:35:04 -0000 On 2010-06-17 15:08, Dr. Joe Mitola wrote: > However, if institutions (like a defence department) choose to interpret= =20 > IDL as how versus what, then this unnecessarily constrains realizations. > So unless we do something aggressive with IDL to constrain the=20 > implementations, there's nothing inherent in CORBA or IDL that forces=20 > inefficiency. That's good news and it matches our original intent in using IDL; we=20 explicitly state that CORBA is not being mandated, but if CORBA is=20 going to be used, the IDL is normative (as in "how"). Otherwise, the=20 IDL simply specifies the "what." Lev From Joe.Mitola@stevens.edu Thu Jun 17 14:02:46 2010 Return-Path: X-Original-To: cicm@core3.amsl.com Delivered-To: cicm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAC4F3A6B2B for ; Thu, 17 Jun 2010 14:02:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.768 X-Spam-Level: X-Spam-Status: No, score=-3.768 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H0IAP+JUKlSa for ; Thu, 17 Jun 2010 14:02:46 -0700 (PDT) Received: from nexus.stevens.edu (nexus.stevens.edu [155.246.14.12]) by core3.amsl.com (Postfix) with ESMTP id E4E603A6B28 for ; Thu, 17 Jun 2010 14:02:45 -0700 (PDT) Received: from [155.246.152.137] by nexus.stevens.edu (iPlanet Messaging Server 5.2 HotFix 2.04 (built Feb 8 2005)) with ESMTPSA id <0L46003LGFSGM1@nexus.stevens.edu> for cicm@ietf.org; Thu, 17 Jun 2010 17:02:41 -0400 (EDT) Date: Thu, 17 Jun 2010 17:02:40 -0400 From: "Dr. Joe Mitola" In-reply-to: To: CICM Discussion List Message-id: <4C1A8D70.2070200@stevens.edu> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) References: <3FF9F74E63A7484EB3B88F04329CBEDC02B3FBB1ED@IMCMBX1.MITRE.ORG> <4C1A728E.5000108@stevens.edu> Subject: Re: [cicm] Channel I/O X-BeenThere: cicm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: CICM Discussion List List-Id: CICM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2010 21:02:46 -0000 The 'what' can be normative, Lev. Better to have the what part normative vs the how part which can be advisory Dr. Joseph Mitola III, Fellow of the IEEE Distinguished Professor Charles V. Schaefer, Jr. School of Engineering and Science School of Systems and Enterprises Vice President for the Research Enterprise Stevens Institute of Technology Castle Point on Hudson, Hoboken, NJ, USA Cell: 703-314-5709 Novikov, Lev wrote: > On 2010-06-17 15:08, Dr. Joe Mitola wrote: > >> However, if institutions (like a defence department) choose to interpret >> IDL as how versus what, then this unnecessarily constrains realizations. >> So unless we do something aggressive with IDL to constrain the >> implementations, there's nothing inherent in CORBA or IDL that forces >> inefficiency. >> > > That's good news and it matches our original intent in using IDL; we > explicitly state that CORBA is not being mandated, but if CORBA is > going to be used, the IDL is normative (as in "how"). Otherwise, the > IDL simply specifies the "what." > > Lev > _______________________________________________ > cicm mailing list > cicm@ietf.org > https://www.ietf.org/mailman/listinfo/cicm > From lnovikov@mitre.org Fri Jun 18 13:04:10 2010 Return-Path: X-Original-To: cicm@core3.amsl.com Delivered-To: cicm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62F363A6919 for ; Fri, 18 Jun 2010 13:04:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.129 X-Spam-Level: X-Spam-Status: No, score=-4.129 tagged_above=-999 required=5 tests=[AWL=-0.130, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sevsDLkakDol for ; Fri, 18 Jun 2010 13:04:09 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 7B3E73A6915 for ; Fri, 18 Jun 2010 13:04:09 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o5IK4Ehp008701 for ; Fri, 18 Jun 2010 16:04:14 -0400 Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o5IK4Ebx008698 for ; Fri, 18 Jun 2010 16:04:14 -0400 Received: from IMCMBX3.MITRE.ORG ([129.83.29.206]) by imchub1.MITRE.ORG ([129.83.29.73]) with mapi; Fri, 18 Jun 2010 16:04:14 -0400 From: "Novikov, Lev" To: CICM Discussion List Date: Fri, 18 Jun 2010 16:02:28 -0400 Thread-Topic: [cicm] Channel I/O Thread-Index: AcsOYHTspysQqsVnSUaQKPgbYQ0u9wAvbT2w Message-ID: References: <3FF9F74E63A7484EB3B88F04329CBEDC02B3FBB1ED@IMCMBX1.MITRE.ORG> <4C1A728E.5000108@stevens.edu> <4C1A8D70.2070200@stevens.edu> In-Reply-To: <4C1A8D70.2070200@stevens.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [cicm] Channel I/O X-BeenThere: cicm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: CICM Discussion List List-Id: CICM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jun 2010 20:04:10 -0000 On Thu, 2010-06-17 at 17:03, Dr. Joe Mitola wrote: > The 'what' can be normative, Lev. Better to have the what part=20 > normative vs the how part which can be advisory Agreed; only the IDL definitions (what) are normative. The specification (Section 1.1) says: The use of IDL in CICM is not intended to either prescribe or preclude a particular communications protocol such as General Inter- ORB Protocol (GIOP) between programs in different address spaces or on different devices. See: http://tools.ietf.org/html/draft-lanz-cicm-00#section-1.1 The "how" is almost considered out-of-scope, but we wanted to make sure that the current definitions don't obstruct the use of high performance implementations (which it shouldn't as you've clarified). Thanks, Lev From Brian.Donnelly@sncorp.com Mon Jun 21 01:39:27 2010 Return-Path: X-Original-To: cicm@core3.amsl.com Delivered-To: cicm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFC013A6845 for ; Mon, 21 Jun 2010 01:39:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YUmqw9fxmw0A for ; Mon, 21 Jun 2010 01:39:23 -0700 (PDT) Received: from mail5.sncorp.com (mail5.sncorp.com [208.1.64.127]) by core3.amsl.com (Postfix) with ESMTP id CCF103A6A03 for ; Mon, 21 Jun 2010 01:39:22 -0700 (PDT) Received: from Masterhub2.sncorp.intranet.com (unknown [10.4.15.102]) by mail5.sncorp.com (Spam & Virus Firewall) with ESMTP id 62DD074C4A for ; Mon, 21 Jun 2010 01:39:29 -0700 (PDT) Received: from Masterhub2.sncorp.intranet.com ([10.4.15.102]) by mail5.sncorp.com with ESMTP id RUwU46M0TmCLwsJe for ; Mon, 21 Jun 2010 01:39:29 -0700 (PDT) From: Brian Donnelly To: cicm@ietf.org Message-ID: Date: Mon, 21 Jun 2010 01:39:27 -0700 X-MIMETrack: Serialize by Router on masterhub2/SNCorp(Release 7.0.3FP1 HF77|May 21, 2008) at 06/21/2010 01:39:29 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: [cicm] Brian Donnelly is out of the office. X-BeenThere: cicm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: CICM Discussion List List-Id: CICM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2010 08:39:27 -0000 I will be out of the office starting 06/19/2010 and will not return until 07/06/2010. Please contact Richard Bradley (510 446 8340) in my absence. From clinn@harris.com Tue Jun 22 10:56:35 2010 Return-Path: X-Original-To: cicm@core3.amsl.com Delivered-To: cicm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 531003A67EC for ; Tue, 22 Jun 2010 10:56:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WEWynvzX1Hif for ; Tue, 22 Jun 2010 10:56:34 -0700 (PDT) Received: from mlbe2k1.cs.myharris.net (mlbe2k1.cs.myharris.net [137.237.90.88]) by core3.amsl.com (Postfix) with ESMTP id 04DC63A687A for ; Tue, 22 Jun 2010 10:56:33 -0700 (PDT) Received: from mail pickup service by mlbe2k1.cs.myharris.net with Microsoft SMTPSVC; Tue, 22 Jun 2010 13:56:40 -0400 Received: from roce2k4.cs.myharris.net ([147.177.32.37]) by mlbe2k1.cs.myharris.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Jun 2010 13:56:39 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 22 Jun 2010 13:56:34 -0400 Message-ID: <4586CEA3C168F64BA2E01DF8B18821AF05E773F4@roce2k4.cs.myharris.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [cicm] Channel I/O Thread-Index: AcsOYHTspysQqsVnSUaQKPgbYQ0u9wAvbT2wAMVKGEA= References: <3FF9F74E63A7484EB3B88F04329CBEDC02B3FBB1ED@IMCMBX1.MITRE.ORG><4C1A728E.5000108@stevens.edu><4C1A8D70.2070200@stevens.edu> From: "Linn, Charles" To: "CICM Discussion List" X-OriginalArrivalTime: 22 Jun 2010 17:56:39.0244 (UTC) FILETIME=[43A160C0:01CB1234] Subject: Re: [cicm] Channel I/O X-BeenThere: cicm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: CICM Discussion List List-Id: CICM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 17:56:35 -0000 An area I can provide some insight, yet not a solution comes from the JTRS realm. Without going into specifics, while a commonly used interface passes data to the API as an octet sequence for encryption / decryption, there are also some implementations out there that use a different zero-copy method (this also plays in with the "high assurance" side of things, but can't discuss why, sorry). Security considerations put aside, zero copy is not only faster, but (when it can be used) allows for nagleing and other network packet techniques, where the packet is constructed "oversize", and grown in place as headers are added, etc. With this technique, rather than an octet sequence, some sort of opaque index is passed. This index is later dereferenced in the implementation to access the data (usually in a shared memory area, etc). -Chuck Linn=20 From clinn@harris.com Tue Jun 22 11:11:01 2010 Return-Path: X-Original-To: cicm@core3.amsl.com Delivered-To: cicm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD5E33A6855 for ; Tue, 22 Jun 2010 11:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kQ2eWw-+V9du for ; Tue, 22 Jun 2010 11:10:57 -0700 (PDT) Received: from mlbe2k2.cs.myharris.net (mlbe2k2.cs.myharris.net [137.237.90.89]) by core3.amsl.com (Postfix) with ESMTP id 225B63A68C0 for ; Tue, 22 Jun 2010 11:10:56 -0700 (PDT) Received: from mail pickup service by mlbe2k2.cs.myharris.net with Microsoft SMTPSVC; Tue, 22 Jun 2010 14:11:02 -0400 Received: from roce2k4.cs.myharris.net ([147.177.32.37]) by mlbe2k2.cs.myharris.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Jun 2010 14:11:02 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 22 Jun 2010 14:10:57 -0400 Message-ID: <4586CEA3C168F64BA2E01DF8B18821AF05E7740E@roce2k4.cs.myharris.net> In-Reply-To: <3FF9F74E63A7484EB3B88F04329CBEDC02B3FBAEA0@IMCMBX1.MITRE.ORG> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [cicm] Does CICM only provide (specify) the "red" side API ina multilevel system? Thread-Index: AcsNgra2lFtoPnG0Sb2mC5zD9Fw/4gACJAnAASpftsA= References: <8CBBCF54EC560B479037451B6F1AA4F5016B64ED@roce2k4.cs.myharris.net> <3FF9F74E63A7484EB3B88F04329CBEDC02B3FBAEA0@IMCMBX1.MITRE.ORG> From: "Linn, Charles" To: "CICM Discussion List" X-OriginalArrivalTime: 22 Jun 2010 18:11:02.0336 (UTC) FILETIME=[4612C400:01CB1236] Subject: Re: [cicm] Does CICM only provide (specify) the "red" side API ina multilevel system? X-BeenThere: cicm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: CICM Discussion List