From Alan.Borland@BoldonJames.com Wed Mar 13 03:21:27 2013 Return-Path: X-Original-To: plasma@ietfa.amsl.com Delivered-To: plasma@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C9BA21F8D79 for ; Wed, 13 Mar 2013 03:21:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQbSuK5ujmlb for ; Wed, 13 Mar 2013 03:21:26 -0700 (PDT) Received: from outgoing.boldonjames.com (outgoing.boldonjames.com [195.217.233.97]) by ietfa.amsl.com (Postfix) with ESMTP id 60E8521F8D37 for ; Wed, 13 Mar 2013 03:21:24 -0700 (PDT) Received: from BJEX3.corps.boldonjames.com ([fe80::b85c:343b:66b0:b132]) by bjex3.corps.boldonjames.com ([fe80::b85c:343b:66b0:b132%10]) with mapi id 14.02.0328.009; Wed, 13 Mar 2013 10:21:21 +0000 From: Alan Borland To: "'plasma@ietf.org'" Thread-Topic: Verifying the signature of the LockBox. Thread-Index: Ac4f0qAKuaW+39TnSmuvI2yWCWh8WA== Date: Wed, 13 Mar 2013 10:21:20 +0000 Message-ID: <0E5C08E16910F1409605822C0EC4DB56223562C4@bjex3.corps.boldonjames.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.0.31] x-protectivemarking: [BJ/UNMARKED/EXTERNAL] Content-Type: multipart/alternative; boundary="_000_0E5C08E16910F1409605822C0EC4DB56223562C4bjex3corpsboldo_" MIME-Version: 1.0 Subject: [plasma] Verifying the signature of the LockBox. X-BeenThere: plasma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The PoLicy Augmented S/Mime \(plasma\) bof discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 10:21:27 -0000 --_000_0E5C08E16910F1409605822C0EC4DB56223562C4bjex3corpsboldo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [Boldon James classification: UNMARKED EXTERNAL] When we open a message we have to determine if the message is a traditional= S/MIME message or a Plasma message. This is done by inspecting the CMS en= velopedData layer looking for a Plasma LockBox. If the lockbox is found we = verify the SignedData signature, but this got me thinking. Should we verif= y just the integrity of the signature itself or should we also perform a fu= ll certificate path validation as well? This would mean every user needs = to trust a certificate from the Plasma Server (additional overhead - is thi= s an issue?), but then if the Plasma Server is somehow compromised this wou= ld be a way of returning the error to the client. I couldn't decide either way, at the moment we're doing a full certificate = path validation. Alan. Alan Borland Boldon James Limited, a QinetiQ company Mobile: +44 (0)7810 556709 Direct: +44 (0)1270 507841 Switch: +44 (0)1270 507800 Email: alan.borland@boldonjames.com Email (R): abborland@qinetiq.r.mil.uk Web: www.boldonjames.com --_000_0E5C08E16910F1409605822C0EC4DB56223562C4bjex3corpsboldo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

[Boldon James cla= ssification: UNMARKED EXTERNAL]

When we open a message we have to determine if the m= essage is a traditional S/MIME message or a Plasma message. This is d= one by inspecting the CMS envelopedData layer looking for a Plasma LockBox.= If the lockbox is found we verify the SignedData signature, but this got me thinking. Should we verify jus= t the integrity of the signature itself or should we also perform a full ce= rtificate path validation as well? This would mean every user n= eeds to trust a certificate from the Plasma Server (additional overhead - is this an issue?), but then if the Plasma Server i= s somehow compromised this would be a way of returning the error to the cli= ent.

I couldn't decide either way, at the moment we're do= ing a full certificate path validation.

Alan.

Alan Borland<= /p>

Boldon James Limited, a QinetiQ company

Mobile:   = ;     +44 (0)7810 556709
Direct:         +44 (0)1270 507= 841
Switch:        +44 (0)1270 507800
Email:          alan.borland@boldonjames.com
Email (R):    abborland@qinetiq.r.mil.u= k
Web:           www.boldonjames.com

--_000_0E5C08E16910F1409605822C0EC4DB56223562C4bjex3corpsboldo_-- From ietf@augustcellars.com Wed Mar 13 05:44:43 2013 Return-Path: X-Original-To: plasma@ietfa.amsl.com Delivered-To: plasma@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93E6121F8941 for ; Wed, 13 Mar 2013 05:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NJu0PrXmen1L for ; Wed, 13 Mar 2013 05:44:41 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id AC40821F88F7 for ; Wed, 13 Mar 2013 05:44:41 -0700 (PDT) Received: from Philemon (dhcp-1431.meeting.ietf.org [130.129.20.49]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 0F75738EFC; Wed, 13 Mar 2013 05:44:40 -0700 (PDT) From: "Jim Schaad" To: "'Alan Borland'" , References: <0E5C08E16910F1409605822C0EC4DB56223562C4@bjex3.corps.boldonjames.com> In-Reply-To: <0E5C08E16910F1409605822C0EC4DB56223562C4@bjex3.corps.boldonjames.com> Date: Wed, 13 Mar 2013 08:44:07 -0400 Message-ID: <05bb01ce1fe8$749d1b50$5dd751f0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_05BC_01CE1FC6.ED8DC540" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHVAr/odME5PYMQgzzHL9U11NMvp5iVywMA Content-Language: en-us Subject: Re: [plasma] Verifying the signature of the LockBox. X-BeenThere: plasma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The PoLicy Augmented S/Mime \(plasma\) bof discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 12:44:43 -0000 This is a multipart message in MIME format. ------=_NextPart_000_05BC_01CE1FC6.ED8DC540 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit It is my believe you should perform the full path verification. If you don't then you have no confidence in any of the signed attributes associated with the signature such as the URL for the plasma server and thus go someplace you don't want to and start the plasma protocol. Jim From: plasma-bounces@ietf.org [mailto:plasma-bounces@ietf.org] On Behalf Of Alan Borland Sent: Wednesday, March 13, 2013 6:21 AM To: 'plasma@ietf.org' Subject: [plasma] Verifying the signature of the LockBox. [Boldon James classification: UNMARKED EXTERNAL] When we open a message we have to determine if the message is a traditional S/MIME message or a Plasma message. This is done by inspecting the CMS envelopedData layer looking for a Plasma LockBox. If the lockbox is found we verify the SignedData signature, but this got me thinking. Should we verify just the integrity of the signature itself or should we also perform a full certificate path validation as well? This would mean every user needs to trust a certificate from the Plasma Server (additional overhead - is this an issue?), but then if the Plasma Server is somehow compromised this would be a way of returning the error to the client. I couldn't decide either way, at the moment we're doing a full certificate path validation. Alan. Alan Borland Boldon James Limited, a QinetiQ company Mobile: +44 (0)7810 556709 Direct: +44 (0)1270 507841 Switch: +44 (0)1270 507800 Email: alan.borland@boldonjames.com Email (R): abborland@qinetiq.r.mil.uk Web: www.boldonjames.com ------=_NextPart_000_05BC_01CE1FC6.ED8DC540 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

It is my believe you should perform the full = path verification. If you don’t then you have no confidence = in any of the signed attributes associated with the signature such as = the URL for the plasma server and thus go someplace you don’t want = to and start the plasma protocol.

Jim

From:= = plasma-bounces@ietf.org [mailto:plasma-bounces@ietf.org] On Behalf Of = Alan Borland
Sent: Wednesday, March 13, 2013 6:21 = AM
To: 'plasma@ietf.org'
Subject: [plasma] Verifying = the signature of the LockBox.

[B= oldon James classification: = UNMARKED = EXTERNAL]

When we open a message we have to = determine if the message is a traditional S/MIME message or a Plasma = message. This is done by inspecting the CMS envelopedData layer = looking for a Plasma LockBox. If the lockbox is found we verify the = SignedData signature, but this got me thinking. Should we verify = just the integrity of the signature itself or should we also perform a = full certificate path validation as well? This would mean = every user needs to trust a certificate from the Plasma Server = (additional overhead - is this an issue?), but then if the Plasma Server = is somehow compromised this would be a way of returning the error to the = client.

I couldn't decide either way, at the moment we're doing a = full certificate path validation.

Alan.

A= lan Borland

Boldon James Limited, a QinetiQ company =

Mobile:        +44 (0)7810 = 556709
Direct:         +44 = (0)1270 507841
Switch:        +44 = (0)1270 = 507800
Email:          = alan.borland@boldonjames.com
Email = (R):    abborland@qinetiq.r.mil.uk
Web:   = ;        www.boldonjames.com

<= /html> ------=_NextPart_000_05BC_01CE1FC6.ED8DC540-- From ietf@augustcellars.com Mon Mar 18 16:18:15 2013 Return-Path: X-Original-To: plasma@ietfa.amsl.com Delivered-To: plasma@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D2F421F8BBA for ; Mon, 18 Mar 2013 16:18:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5RXyoPyMMon3 for ; Mon, 18 Mar 2013 16:18:14 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id BECD521F8B65 for ; Mon, 18 Mar 2013 16:18:14 -0700 (PDT) Received: from Philemon (50-39-222-11.bvtn.or.frontiernet.net [50.39.222.11]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 876FC38F04 for ; Mon, 18 Mar 2013 16:18:14 -0700 (PDT) From: "Jim Schaad" To: References: <20130318230654.12822.91956.idtracker@ietfa.amsl.com> In-Reply-To: <20130318230654.12822.91956.idtracker@ietfa.amsl.com> Date: Mon, 18 Mar 2013 16:17:41 -0700 Message-ID: <095401ce242e$ca228ac0$5e67a040$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGW8MVtTe6chNKXfe861QhgGIEJa5kae61Q Content-Language: en-us Subject: [plasma] FW: New Version Notification for draft-schaad-plasma-cms-04.txt X-BeenThere: plasma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The PoLicy Augmented S/Mime \(plasma\) bof discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 23:18:15 -0000 Update draft with a new way to handle encoding recipient infos. Please look at and make sure that it makes sense. Recommendations on = other approaches should be discussed if you feel they are better than = the one offered here. I am not emotionally attached to this encoding = and we discussed a couple of alternatives before choosing this one. Jim > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Monday, March 18, 2013 4:07 PM > To: ietf@augustcellars.com > Subject: New Version Notification for draft-schaad-plasma-cms-04.txt >=20 >=20 > A new version of I-D, draft-schaad-plasma-cms-04.txt > has been successfully submitted by Jim Schaad and posted to the > IETF repository. >=20 > Filename: draft-schaad-plasma-cms > Revision: 04 > Title: Plasma Service Cryptographic Message Syntax (CMS) > Processing > Creation date: 2013-03-18 > Group: Individual Submission > Number of pages: 31 > URL: = http://www.ietf.org/internet-drafts/draft-schaad-plasma-cms- > 04.txt > Status: = http://datatracker.ietf.org/doc/draft-schaad-plasma-cms > Htmlized: http://tools.ietf.org/html/draft-schaad-plasma-cms-04 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-schaad-plasma-cms-04 >=20 > Abstract: > Secure MIME (S/MIME) defined a method of placing security labels on = a > Cryptographic Message Syntax (CMS) object. These labels are placed > as part of the data signed and validated by the parties. This = means > that the message content is visible to the recipient prior to the > label enforcement. A new model for enforcement of policy using a > third party is described in RFC TBD > [I.D-draft-freeman-plasma-requirements]. This is the Policy > Augmented S/MIME (PLASMA) system. This document provides the = details > needed to implement the new Plasma model in the CMS infrastructure. >=20 > An additional benefit of using the Plasma module is that the = server, > based on policy, manages who has access to the message and how the > keys are protected. >=20 > The document details how the client encryption and decryption > processes are performed, defines how to construct the CMS recipient > info structure, a new content to hold the data required for the > Plasma server to store the keys and policy information. The = document > does not cover the protocol between the client and the Plasma = policy > enforcement server. One example of the client/server protocol can = be > found in RFC TBD [plasma-token]. >=20 >=20 >=20 >=20 > The IETF Secretariat