From stephen.farrell@cs.tcd.ie Mon Sep 2 14:57:13 2013 Return-Path: X-Original-To: smime@ietfa.amsl.com Delivered-To: smime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E65FB21F9DB4; Mon, 2 Sep 2013 14:57:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 v9X5vACuIZMw; Mon, 2 Sep 2013 14:57:04 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 4F25421F9CDF; Mon, 2 Sep 2013 14:57:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 93939BE70; Mon, 2 Sep 2013 22:57:02 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D0NKLV2-xxD1; Mon, 2 Sep 2013 22:57:01 +0100 (IST) Received: from [10.87.48.4] (unknown [86.42.17.45]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 8DA06BE6F; Mon, 2 Sep 2013 22:57:01 +0100 (IST) Message-ID: <522509AC.6040907@cs.tcd.ie> Date: Mon, 02 Sep 2013 22:57:00 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: "saag@ietf.org" , smime@ietf.org X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [smime] some s/mime related drafts I've been asked to AD sponsor X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Sep 2013 21:57:13 -0000 Folks, Sean, Russ and Jim have authored three s/mime related drafts [1,2,3] and asked me to sponsor them for publication. I've read them and they seem like reasonable additions to the set of s/mime RFCs to me, but I'd like to check that nobody has any issue with that before starting IETF LC in a week or so. I'd specifically be interested in hearing from anyone who'd likely implement these. I'll send my own comments (which are minor) during the IETF LC. Thanks, S. [1] http://tools.ietf.org/html/draft-turner-application-cms-media-type [2] http://tools.ietf.org/html/draft-housley-ct-keypackage-receipt-n-error [3] http://tools.ietf.org/html/draft-turner-ct-keypackage-receipt-n-error-algs From paul.hoffman@vpnc.org Mon Sep 2 15:23:38 2013 Return-Path: X-Original-To: smime@ietfa.amsl.com Delivered-To: smime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D540C21F9C4E for ; Mon, 2 Sep 2013 15:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.634 X-Spam-Level: X-Spam-Status: No, score=-102.634 tagged_above=-999 required=5 tests=[AWL=-0.035, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 0uuCWQJYM0CV for ; Mon, 2 Sep 2013 15:23:38 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 6224F21F9C47 for ; Mon, 2 Sep 2013 15:23:38 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.5) with ESMTP id r82MNFub037589 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 2 Sep 2013 15:23:16 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: <522509AC.6040907@cs.tcd.ie> Date: Mon, 2 Sep 2013 15:23:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <522509AC.6040907@cs.tcd.ie> To: smime@ietf.org X-Mailer: Apple Mail (2.1508) Cc: Stephen Farrell Subject: Re: [smime] some s/mime related drafts I've been asked to AD sponsor X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Sep 2013 22:23:38 -0000 S/MIMErs: please take a look at these and let the list know (a) if you = have any concerns, (b) if you might implement them, or both. --Paul Hoffman On Sep 2, 2013, at 2:57 PM, Stephen Farrell = wrote: >=20 > Folks, >=20 > Sean, Russ and Jim have authored three s/mime related drafts [1,2,3] > and asked me to sponsor them for publication. I've read them and > they seem like reasonable additions to the set of s/mime RFCs to > me, but I'd like to check that nobody has any issue with that > before starting IETF LC in a week or so. >=20 > I'd specifically be interested in hearing from anyone who'd > likely implement these. I'll send my own comments (which are > minor) during the IETF LC. >=20 > Thanks, > S. >=20 > [1] http://tools.ietf.org/html/draft-turner-application-cms-media-type > [2] > http://tools.ietf.org/html/draft-housley-ct-keypackage-receipt-n-error > [3] > = http://tools.ietf.org/html/draft-turner-ct-keypackage-receipt-n-error-algs= >=20 > _______________________________________________ > smime mailing list > smime@ietf.org > https://www.ietf.org/mailman/listinfo/smime >=20 From carl@redhoundsoftware.com Mon Sep 2 16:00:10 2013 Return-Path: X-Original-To: smime@ietfa.amsl.com Delivered-To: smime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0929621F9C42 for ; Mon, 2 Sep 2013 16:00:10 -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=[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 zvj8rClcWKM4 for ; Mon, 2 Sep 2013 16:00:02 -0700 (PDT) Received: from mail-qe0-f43.google.com (mail-qe0-f43.google.com [209.85.128.43]) by ietfa.amsl.com (Postfix) with ESMTP id E5C9C21F9C37 for ; Mon, 2 Sep 2013 16:00:01 -0700 (PDT) Received: by mail-qe0-f43.google.com with SMTP id gh4so820863qeb.2 for ; Mon, 02 Sep 2013 16:00:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=3yuCIQ6YovpgwvjWHV+b3JlrRlxNcy+oA7Dp2m7y288=; b=mLSS19V9s7iod//2LICNowTPcplZBR+4UjSj/3FbpEjHyMEK+dtiWJsCP3Akm0QgPy Zpfk5leDCLSIo7vsayjoJXPRaAfLuyUmBYSbG6CH1FgUC2gML6igUgpC8jrNs6uskfCi z5IZPjYRWqbOPLuaFgaYzH0vr0qONBXjUgZRAAT1xZa2hOn7pra4FxEDWR70ik9fs83w 8Iw/J8UTU7hieZkRJ8vQyawb82sEBx6Z3aDjubHewE8ybjWkCJVBhfTcCZp5gWIW3OLA eHmmRmwa0vYsa03fjTQpggHiLVG/Mmz4JKvXRPwUYZyTjArg9sBW66Qa3Ypw/1t79ozw y5Yg== X-Gm-Message-State: ALoCoQmhilgXdBtAtrwwPtkcGZgMY1RScDaPUCtA9c/YWgEQZABtMhuAby+tGoVrUn4EAGdlDz9J X-Received: by 10.49.25.102 with SMTP id b6mr5536926qeg.91.1378162801383; Mon, 02 Sep 2013 16:00:01 -0700 (PDT) Received: from [192.168.2.3] (pool-173-79-121-77.washdc.fios.verizon.net. [173.79.121.77]) by mx.google.com with ESMTPSA id h2sm15102560qev.0.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 02 Sep 2013 16:00:01 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.3.1.130117 Date: Mon, 02 Sep 2013 19:00:00 -0400 From: Carl Wallace To: Paul Hoffman , Message-ID: Thread-Topic: [smime] some s/mime related drafts I've been asked to AD sponsor In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: Stephen Farrell Subject: Re: [smime] some s/mime related drafts I've been asked to AD sponsor X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Sep 2013 23:00:10 -0000 What was the criteria for selecting the items in the innermost content type set included in [1]? For example, why include TrustAnchorList content type from 5914 but not the TAMP content types from 5934? The interop considerations section states ContentInfo is always the outermost structure. Should RFC 4073 be updated to reflect this? On 9/2/13 6:23 PM, "Paul Hoffman" wrote: >S/MIMErs: please take a look at these and let the list know (a) if you >have any concerns, (b) if you might implement them, or both. > >--Paul Hoffman > >On Sep 2, 2013, at 2:57 PM, Stephen Farrell >wrote: > >> >> Folks, >> >> Sean, Russ and Jim have authored three s/mime related drafts [1,2,3] >> and asked me to sponsor them for publication. I've read them and >> they seem like reasonable additions to the set of s/mime RFCs to >> me, but I'd like to check that nobody has any issue with that >> before starting IETF LC in a week or so. >> >> I'd specifically be interested in hearing from anyone who'd >> likely implement these. I'll send my own comments (which are >> minor) during the IETF LC. >> >> Thanks, >> S. >> >> [1] http://tools.ietf.org/html/draft-turner-application-cms-media-type >> [2] >> http://tools.ietf.org/html/draft-housley-ct-keypackage-receipt-n-error >> [3] >> >>http://tools.ietf.org/html/draft-turner-ct-keypackage-receipt-n-error-alg >>s >> >> _______________________________________________ >> smime mailing list >> smime@ietf.org >> https://www.ietf.org/mailman/listinfo/smime >> > >_______________________________________________ >smime mailing list >smime@ietf.org >https://www.ietf.org/mailman/listinfo/smime From turners@ieca.com Mon Sep 2 16:56:02 2013 Return-Path: X-Original-To: smime@ietfa.amsl.com Delivered-To: smime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A72221F9E37 for ; Mon, 2 Sep 2013 16:56:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.824 X-Spam-Level: X-Spam-Status: No, score=-101.824 tagged_above=-999 required=5 tests=[AWL=0.441, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] 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 byF00SPlW2QA for ; Mon, 2 Sep 2013 16:55:56 -0700 (PDT) Received: from gateway08.websitewelcome.com (gateway08.websitewelcome.com [69.41.247.18]) by ietfa.amsl.com (Postfix) with ESMTP id 71E5221F9A97 for ; Mon, 2 Sep 2013 16:55:55 -0700 (PDT) Received: by gateway08.websitewelcome.com (Postfix, from userid 5007) id A7939359C8B86; Mon, 2 Sep 2013 18:55:54 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway08.websitewelcome.com (Postfix) with ESMTP id 906DC359C8B41 for ; Mon, 2 Sep 2013 18:55:54 -0500 (CDT) Received: from [96.231.225.44] (port=52889 helo=thunderfish.local) by gator3286.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1VGdyL-0004b9-Vb; Mon, 02 Sep 2013 18:55:54 -0500 Message-ID: <52252589.4050501@ieca.com> Date: Mon, 02 Sep 2013 19:55:53 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Carl Wallace References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [96.231.225.44]:52889 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 3 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Cc: Stephen Farrell , Paul Hoffman , smime@ietf.org Subject: Re: [smime] some s/mime related drafts I've been asked to AD sponsor X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Sep 2013 23:56:02 -0000 On 9/2/13 7:00 PM, Carl Wallace wrote: > What was the criteria for selecting the items in the innermost content > type set included in [1]? For example, why include TrustAnchorList > content type from 5914 but not the TAMP content types from 5934? I didn't include the TAMP content types from RFC 5934 because they already had content types defined. Maybe they should be added though. > The interop considerations section states ContentInfo is always the > outermost structure. Should RFC 4073 be updated to reflect this? I'm checking with Russ but I didn't think that ContentCollection would be used without a ContentInfo wrapper. spt > On 9/2/13 6:23 PM, "Paul Hoffman" wrote: > >> S/MIMErs: please take a look at these and let the list know (a) if you >> have any concerns, (b) if you might implement them, or both. >> >> --Paul Hoffman >> >> On Sep 2, 2013, at 2:57 PM, Stephen Farrell >> wrote: >> >>> >>> Folks, >>> >>> Sean, Russ and Jim have authored three s/mime related drafts [1,2,3] >>> and asked me to sponsor them for publication. I've read them and >>> they seem like reasonable additions to the set of s/mime RFCs to >>> me, but I'd like to check that nobody has any issue with that >>> before starting IETF LC in a week or so. >>> >>> I'd specifically be interested in hearing from anyone who'd >>> likely implement these. I'll send my own comments (which are >>> minor) during the IETF LC. >>> >>> Thanks, >>> S. >>> >>> [1] http://tools.ietf.org/html/draft-turner-application-cms-media-type >>> [2] >>> http://tools.ietf.org/html/draft-housley-ct-keypackage-receipt-n-error >>> [3] >>> >>> http://tools.ietf.org/html/draft-turner-ct-keypackage-receipt-n-error-alg >>> s >>> >>> _______________________________________________ >>> smime mailing list >>> smime@ietf.org >>> https://www.ietf.org/mailman/listinfo/smime >>> >> >> _______________________________________________ >> smime mailing list >> smime@ietf.org >> https://www.ietf.org/mailman/listinfo/smime > > > _______________________________________________ > smime mailing list > smime@ietf.org > https://www.ietf.org/mailman/listinfo/smime > From prvs=09616be90b=peter.rybar@nbusr.sk Fri Sep 6 04:08:42 2013 Return-Path: X-Original-To: smime@ietfa.amsl.com Delivered-To: smime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C994A21F9A6A for ; Fri, 6 Sep 2013 04:08:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.512 X-Spam-Level: * X-Spam-Status: No, score=1.512 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DEAR_SOMETHING=1.605, GB_I_INVITATION=-2, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, 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 2PALr6B3TKC6 for ; Fri, 6 Sep 2013 04:08:38 -0700 (PDT) Received: from mail.nbusr.sk (mail.nbusr.sk [84.245.65.227]) by ietfa.amsl.com (Postfix) with ESMTP id 29ED621F9E4F for ; Fri, 6 Sep 2013 04:08:36 -0700 (PDT) Message-Id: <201309061108.r86B8XmD057906@mail.nbusr.sk> From: "Peter Rybar" To: "'Ayhan Sehrin'" , smime@ietf.org Date: Fri, 6 Sep 2013 13:08:32 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01CEAB02.3035A770" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Thread-Index: Ac6qCakhhEet1U9yTEqeogYY3nwJaAAAJOPQAACfK/AAOFhwEA== X-NAI-Spam-Flag: NO X-NAI-Spam-Level: ** X-NAI-Spam-Threshold: 6 X-NAI-Spam-Score: 2.5 X-NAI-Spam-Version: 2.3.0.9362 : core <4692> : inlines <71> : streams <1032614> : uri <1528746> Cc: 'Peter Rybar' Subject: [smime] FW: [E-SIGNATURES_NEWS] Invitation to the CAdES remote Plugtests event , 02-13 December 2013 X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 11:08:42 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0003_01CEAB02.3035A770 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Ayhan and SMIME members, =20 ETSI will organize the remote interoperability PlugtestsTM event for CMS = signatures and CMS with Advanced Electronic Signature (ETSI TS 101 733) = V2.2.1 attributes. This event will run remotely from 2nd to 13th December 2013. The event is free of charge and is open to both ETSI members and = non-members. (Supporters European Commission) =20 http://www.etsi.org/CAdES-2013 =20 Especially Archive format with Archive timestamp version 3 (ATSv3) will = be tested.=20 =20 ATSv3 is radical simplification, because CMS contains only: 1. Signature time-stamp and=20 2. one or more ATSv3,=20 It is because redundant and complicated CAdES attributes were deprecated = (can be included or ignored) and only CMS attributes are used for = certificate, CRL and OCSP response storage. =20 Archive timestamp version 3 is defined in ETSI TS 101 733 V2.2.1 = (2013-04) http://www.etsi.org/deliver/etsi_ts/101700_101799/101733/02.02.01_60/ts_1= 01733v020201p.pdf=20 =20 CAdES Baseline Profile ETSI TS 103 173 V2.2.1 (2013-04) http://www.etsi.org/deliver/etsi_ts/103100_103199/103173/02.02.01_60/ts_1= 03173v020201p.pdf =20 =20 =20 Best regards, Peter Rybar =20 _____ =20 From: Ayhan Sehrin [mailto:ayhan.sehrin@verion.com.tr]=20 Sent: Tuesday, July 23, 2013 3:22 PM To: 'Peter Rybar' Cc: smime@ietf.org Subject: RE: [smime] Inquiry on the usage of CAdES in S/MIME structures =20 Dear Peter, Thank you very much for the elaborate reply. Our team will be carefully = reviewing your input and comments. Kind regards, =20 Ayhan =C5=9Eehrin =20 =E2=80=A6 =20 _____ =20 From: Sonia Compans [mailto:Sonia.Compans@ETSI.ORG]=20 Dear Sir, Madam =20 ETSI=E2=80=99s Centre for Testing and Interoperability (CTI) is pleased = to invite you to participate to the next remote interoperability = PlugtestsTM event for CAdES (CMS Advanced Electronic Signature ETSI TS = 101 733). This event will run remotely from 2nd to 13th December 2013. =20 This remote event aims to conduct conformance and interoperability = testing on CAdES signatures (ETSI TS 101 733) V2.2.1 and also on the = CAdES Baseline Profile TS 103 173 V2.2.1. In addition the introduction = of new Archive Time Stamp attribute V3 will be taken into consideration. This Plugtests event will enable participants to conduct 4 types of = tests (Interoperability and Conformance): * Generation and cross-verification (Positive) tests * Only-verification (Negative) tests=20 * Upgrade and Arbitration tests * Conformance testing including new archive-time-stamp-v3" The event is free of charge and is open to both ETSI members and = non-members. =20 As this is a REMOTE event, there will be no need for the participants to = travel to the ETSI premises and all signature exchanges and = verifications will be performed via the dedicated portal = http://xades-portal.etsi.org. =20 The remote testing is not performed in real time and the Plugtests = portal will be available 24h/24 for the full duration of the event to = enable participants from all time zones to generate, upload and verify = the signature at their own convenience.=20 =20 All information related to this event along with registration details = may be found at the following address: http://www.etsi.org/CAdES-2013 or = contact us via email: Plugtests@etsi.org. =20 Yours faithfully, =20 Laurent VELEZ ETSI Technical Expert Centre for Testing and Interoperability (CTI) European Telecommunication Standards Institute (ETSI) Tel: +33 (0)4 92 94 43 21 Mob: +33 (0)6 07 59 08 58 =20 www.etsi.org =20 P Please consider the environmental impact before printing this e-mail =20 ------=_NextPart_000_0003_01CEAB02.3035A770 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Dear Ayhan and = SMIME members,

 =

ETSI will = organize the remote interoperability PlugtestsTM event for CMS signatures and CMS with = Advanced Electronic Signature (ETSI TS = 101 733) V2.2.1 = attributes.

This event will = run remotely from 2nd to 13th December 2013.

The event is free of = charge and is open to both ETSI members and non-members. (Supporters European Commission)

 

http://www.etsi.org/CAdES-2013

 =

Especially = Archive format with Archive timestamp version 3 (ATSv3) will be tested. =

 =

ATSv3 is radical simplification, because CMS contains only:

1. Signature = time-stamp and

2. one or more = ATSv3,

It is because = redundant and complicated CAdES attributes were deprecated (can be included or = ignored) and only CMS attributes are used for certificate, CRL and OCSP response = storage.

 =

Archive = timestamp version 3 is defined in ETSI TS 101 733 V2.2.1 = (2013-04)

http://www.etsi.org/deliver/etsi_ts/= 101700_101799/101733/02.02.01_60/ts_101733v020201p.pdf

 =

CAdES Baseline = Profile ETSI TS 103 173 V2.2.1 (2013-04)

http://www.etsi.org/deliver/etsi_ts/= 103100_103199/103173/02.02.01_60/ts_103173v020201p.pdf  

 =

 =

Best = regards,

Peter = Rybar

 =

From: Ayhan Sehrin [mailto:ayhan.sehrin@verion.com.tr]
Sent: Tuesday, July 23, = 2013 3:22 PM
To: 'Peter Rybar'
Cc: smime@ietf.org
Subject: RE: [smime] = Inquiry on the usage of CAdES in S/MIME structures

 

Dear = Peter,

Thank you very much for the = elaborate reply. Our team will be carefully reviewing your input and = comments.

Kind = regards,

 <= /p>

Ayhan = =C5=9Eehrin

 <= /p>

=E2=80=A6

 =

From: Sonia Compans [mailto:Sonia.Compans@ETSI.ORG]

Dear Sir, Madam

 

ETSI=E2=80=99s Centre for Testing and Interoperability (CTI) is = pleased to invite you to participate to the next remote interoperability = PlugtestsTM event for CAdES (CMS = Advanced Electronic Signature ETSI TS 101 733). This event will run = remotely from 2nd to 13th December = 2013.

 

This remote event aims to conduct conformance = and interoperability testing on CAdES signatures (ETSI TS 101 733) = V2.2.1 and also on the CAdES Baseline Profile TS 103 173 V2.2.1. In addition the introduction of new Archive Time Stamp attribute V3 will be taken into consideration.

This Plugtests event will enable participants to conduct 4 types of tests (Interoperability and = Conformance):

=C2=B7         Generation and cross-verification (Positive) tests

  • Only-verification (Negative) tests
  • Upgrade and Arbitration  tests
  • Conformance testing including new = archive-time-stamp-v3"

The event is free of = charge and is open to both ETSI members and = non-members.

 

As this is a REMOTE event, there will be no need for the participants to travel to the ETSI = premises and all signature exchanges and verifications will be performed via the = dedicated portal http://xades-portal.etsi.org.

 

The remote testing is not performed in real time and the = Plugtests portal will be available 24h/24 for the full duration of the event to = enable participants from all time zones to generate, upload and verify the = signature at their own convenience.

 

All information related to this = event along with registration details may be found at the following address: http://www.etsi.org/CAdES-2013 or contact us via email: Plugtests@etsi.org.

 

Yours = faithfully,

 

Laurent VELEZ

ETSI Technical = Expert

Centre for = Testing and Interoperability (CTI)

European Telecommunication Standards Institute (ETSI)

Tel: +33 (0)4 92 = 94 43 21

Mob: +33 (0)6 07 = 59 08 58

 

www.etsi.org

P = Please consider the environmental impact before printing this = e-mail

 

------=_NextPart_000_0003_01CEAB02.3035A770-- From anders.rundgren@telia.com Fri Sep 6 04:29:04 2013 Return-Path: X-Original-To: smime@ietfa.amsl.com Delivered-To: smime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4D8C21E80D3 for ; Fri, 6 Sep 2013 04:29:04 -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=[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 rqTVcus-5Dz4 for ; Fri, 6 Sep 2013 04:28:59 -0700 (PDT) Received: from smtp-out12.han.skanova.net (smtp-out12.han.skanova.net [195.67.226.212]) by ietfa.amsl.com (Postfix) with ESMTP id 9742421E80AF for ; Fri, 6 Sep 2013 04:28:57 -0700 (PDT) Received: from [192.168.0.2] (37.250.35.171) by smtp-out12.han.skanova.net (8.5.133) (authenticated as u36408181) id 521DAB170027BB65 for smime@ietf.org; Fri, 6 Sep 2013 13:28:54 +0200 Message-ID: <5229BC6C.8060607@telia.com> Date: Fri, 06 Sep 2013 13:28:44 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: smime@ietf.org X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [smime] JCS - JSON Clear Text Signature Scheme X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 11:29:04 -0000 New name and updated documentation. https://openkeystore.googlecode.com/svn/resources/trunk/docs/JSON-Clear-Text-Signature-Scheme.pdf Enjoy! Anders From barryleiba@gmail.com Fri Sep 6 07:19:26 2013 Return-Path: X-Original-To: smime@ietfa.amsl.com Delivered-To: smime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B4B011E817F; Fri, 6 Sep 2013 07:19:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.008 X-Spam-Level: X-Spam-Status: No, score=-102.008 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 e7pyNHSIdl74; Fri, 6 Sep 2013 07:19:25 -0700 (PDT) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id EF7AD11E8159; Fri, 6 Sep 2013 07:19:24 -0700 (PDT) Received: by mail-la0-f52.google.com with SMTP id ev20so2826843lab.11 for ; Fri, 06 Sep 2013 07:19:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=IMIVNbRVuhCbk2HcnuzmY4HKHrmeVOafaoK6xaCewo0=; b=FU/cOvn86t8YxD0Kk2yNleII9kx8gtgsS2qG6cWuQyGB8M9jiWckAI2N3lg+dagRdL sm6kzeXwiZVTGe4p7hG2cp2O31w8/DgwsK/di9KCI3f+r1800EYFS32N6fh5gKhGMvxH 7yfjVJBHKflI3TQXqT1ytjTSiHnVfqu6cK9+SkOXYlOtttWetYQ/DTH8k/PuAoqSmin7 2efxZSm6KXIXzmo3tXphTska3c//ZAwtO0M+GXIN4LYhLxU1GSDjHTsh5r3ggDndGP76 qNlu2vXmhpa6xTyNJ8NcZvsRpfKU97H1wZC62uXlRPLMEfRCQP+Lmg7yrmbe10m8h3Hr ZEkw== MIME-Version: 1.0 X-Received: by 10.152.2.74 with SMTP id 10mr1688041las.36.1378477163863; Fri, 06 Sep 2013 07:19:23 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.112.130.39 with HTTP; Fri, 6 Sep 2013 07:19:23 -0700 (PDT) Date: Fri, 6 Sep 2013 10:19:23 -0400 X-Google-Sender-Auth: 40_MrTzOtw2qaspW6Q-6nVfuQlY Message-ID: From: Barry Leiba To: "saag@ietf.org" , smime@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [smime] Fixing the definition of the smime-type parameter by creating a registry X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 14:19:26 -0000 In the handling of draft-ietf-pkix-est, it came up that there really ought to be a registry for values of the "smime-type" content-type parameter. Sean and I discussed it, and I put together a quick document (see below) to create the registry and do the magic. We should have a brief discussion of it here before Sean AD-sponsors it and sends it out for last call. In particular, we decided to propose "RFC Required" for the registration policy. Is that the right policy? Does anyone have other comments about the registry or the document? Please, a few reviews and comments will be needed before we can proceed. And it' short. So have at it. Barry > From: > Date: Wed, Aug 28, 2013 at 10:38 AM > Subject: New Version Notification for draft-leiba-smime-type-registry-00.txt > To: Barry Leiba > > A new version of I-D, draft-leiba-smime-type-registry-00.txt > has been successfully submitted by Barry Leiba and posted to the > IETF repository. > > Filename: draft-leiba-smime-type-registry > Revision: 00 > Title: Creation of a registry for smime-type parameter values > Creation date: 2013-08-28 > Group: Individual Submission > Number of pages: 4 > URL: > http://www.ietf.org/internet-drafts/draft-leiba-smime-type-registry-00.txt > Status: http://datatracker.ietf.org/doc/draft-leiba-smime-type-registry > Htmlized: http://tools.ietf.org/html/draft-leiba-smime-type-registry-00 > > > Abstract: > Secure/Multipurpose Internet Mail Extensions (S/MIME) defined the > Content-Type parameter "smime-type". As the list of defined values > for that parameter has increased, it has become clear that a registry > is needed to document those values. This document creates that > registry, registers the current values, and specifies the policies > for registration of new values. From paul.hoffman@vpnc.org Fri Sep 6 08:41:58 2013 Return-Path: X-Original-To: smime@ietfa.amsl.com Delivered-To: smime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2951B11E81B4; Fri, 6 Sep 2013 08:41:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.631 X-Spam-Level: X-Spam-Status: No, score=-102.631 tagged_above=-999 required=5 tests=[AWL=-0.032, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 tpYNRAxCA97V; Fri, 6 Sep 2013 08:41:57 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id B6CBC11E8122; Fri, 6 Sep 2013 08:41:57 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.5) with ESMTP id r86FfnEp019072 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 6 Sep 2013 08:41:50 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: Date: Fri, 6 Sep 2013 08:41:51 -0700 Content-Transfer-Encoding: 7bit Message-Id: <8DD1936A-C373-4961-BAAD-103604011C2A@vpnc.org> References: To: Barry Leiba X-Mailer: Apple Mail (2.1508) Cc: "saag@ietf.org" , smime@ietf.org Subject: Re: [smime] Fixing the definition of the smime-type parameter by creating a registry X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 15:41:58 -0000 On Sep 6, 2013, at 7:19 AM, Barry Leiba wrote: > In the handling of draft-ietf-pkix-est, it came up that there really > ought to be a registry for values of the "smime-type" content-type > parameter. Sean and I discussed it, and I put together a quick > document (see below) to create the registry and do the magic. We > should have a brief discussion of it here before Sean AD-sponsors it > and sends it out for last call. > > In particular, we decided to propose "RFC Required" for the > registration policy. Is that the right policy? Does anyone have > other comments about the registry or the document? > > Please, a few reviews and comments will be needed before we can > proceed. And it' short. So have at it. The idea of having a registry seems fine, and "RFC Required" seems fine. --Paul Hoffman From dev+ietf@seantek.com Sat Sep 7 07:46:14 2013 Return-Path: X-Original-To: smime@ietfa.amsl.com Delivered-To: smime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 085B521F9E02; Sat, 7 Sep 2013 07:46:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 FmsEwFCOc6iG; Sat, 7 Sep 2013 07:45:47 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 11E7921F9D15; Sat, 7 Sep 2013 07:45:43 -0700 (PDT) Received: from [192.168.123.7] (unknown [76.173.239.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 10B15509B8; Sat, 7 Sep 2013 10:45:38 -0400 (EDT) Message-ID: <522B3C20.105@seantek.com> Date: Sat, 07 Sep 2013 07:45:52 -0700 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: smime@ietf.org, saag@ietf.org References: <8DD1936A-C373-4961-BAAD-103604011C2A@vpnc.org> In-Reply-To: <8DD1936A-C373-4961-BAAD-103604011C2A@vpnc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 07 Sep 2013 09:04:53 -0700 Subject: Re: [smime] Fixing the definition of the smime-type parameter by creating a registry X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Sep 2013 14:46:14 -0000 On 9/6/2013 8:41 AM, Paul Hoffman wrote: > On Sep 6, 2013, at 7:19 AM, Barry Leiba wrote: > >> In the handling of draft-ietf-pkix-est, it came up that there really >> ought to be a registry for values of the "smime-type" content-type >> parameter. Sean and I discussed it, and I put together a quick >> document (see below) to create the registry and do the magic. We >> should have a brief discussion of it here before Sean AD-sponsors it >> and sends it out for last call. >> >> In particular, we decided to propose "RFC Required" for the >> registration policy. Is that the right policy? Does anyone have >> other comments about the registry or the document? >> >> Please, a few reviews and comments will be needed before we can >> proceed. And it' short. So have at it. > The idea of having a registry seems fine, and "RFC Required" seems fine. The idea of having a registry seems fine, and "RFC Required" seems fine. However, as an active developer in this area, I am weary of having more registries to consult for things that rarely if ever change. I am not in favor of a registry without more evidence that there are significantly more diverse CMS payloads that are expected to be carried in MIME-related bodies. I do have a suggestion: The current registry in draft-leiba-smime-type-registry only has two columns: smime-type value and Reference. Actually, it should have six columns, the additional four columns being: CMS Type, CMS Type (OID), Inner Content, and Inner Content (OID). For example, enveloped-data would be CMS Type: EnvelopedData; CMS Type (OID): 1.2.840.113549.1.7.3; Inner Content: id-data; Inner Content (OID): 1.2.840.113549.1.7.1. This additional information would make the registry more useful. Sean From barryleiba.mailing.lists@gmail.com Sat Sep 7 10:09:57 2013 Return-Path: X-Original-To: smime@ietfa.amsl.com Delivered-To: smime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95C9421E80A9; Sat, 7 Sep 2013 10:09:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.007 X-Spam-Level: X-Spam-Status: No, score=-102.007 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 iAkFFY8goULf; Sat, 7 Sep 2013 10:09:57 -0700 (PDT) Received: from mail-vb0-x235.google.com (mail-vb0-x235.google.com [IPv6:2607:f8b0:400c:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 9F75721E8063; Sat, 7 Sep 2013 10:09:56 -0700 (PDT) Received: by mail-vb0-f53.google.com with SMTP id i3so2932047vbh.40 for ; Sat, 07 Sep 2013 10:09:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=9DImSLLcG8W6xaI2EAkHEuugdn6FbWOWqiRlHwWdZdI=; b=w4DBOJ6o464p90mxqiPeuy1h30Gyi8eabRgQ+FA7ycZGUa+Bc8pnw6Id2UjkG8ltDM D6rh+O+PacjVLSJCxaycIlYJbftcUKPdVco7vbe9B/lRBRQ06Z9qP2RMdAbxxZ+YCNm8 ehyWp/L5Xg/GubO1cdG6edFJEhTVyygupaKaOLO68PnRHxhbJFQnRvMG9TIpvDPjH4y3 3w/SJkLmeO91+TQyvgYXNyqapiHaCWqZnVzcwU+ogqVnYCU7eJzYHrfLBdbp9z7buEtI ayax9BtFmDazkS1fo2rrwdrcR4Kci/fM+pAPthBfyS2+LJoow4wmZc9wwxqHQ3NGVvoi geLw== MIME-Version: 1.0 X-Received: by 10.52.116.74 with SMTP id ju10mr7050749vdb.20.1378573795052; Sat, 07 Sep 2013 10:09:55 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.58.215.16 with HTTP; Sat, 7 Sep 2013 10:09:54 -0700 (PDT) In-Reply-To: <522B3C20.105@seantek.com> References: <8DD1936A-C373-4961-BAAD-103604011C2A@vpnc.org> <522B3C20.105@seantek.com> Date: Sat, 7 Sep 2013 13:09:54 -0400 X-Google-Sender-Auth: GAeWTF82wYfbBBAYuLA_JhJTo4k Message-ID: From: Barry Leiba To: Sean Leonard Content-Type: text/plain; charset=ISO-8859-1 Cc: saag , smime@ietf.org Subject: Re: [smime] [saag] Fixing the definition of the smime-type parameter by creating a registry X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Sep 2013 17:09:57 -0000 Hi, Sean, and thanks for the comments. > The idea of having a registry seems fine, and "RFC Required" seems fine. > However, as an active developer in this area, I am weary of having more > registries to consult for things that rarely if ever change. I am not in > favor of a registry without more evidence that there are significantly more > diverse CMS payloads that are expected to be carried in MIME-related bodies. In general, we often think we don't need a registry. And then we add new values. But we still think we don't need a registry. And then we add new values again. This is the third time we've added values for smime-type. I think that says that we need a registry. Better to consult a registry, where all the values are listed in one place, than to have to find the three different RFCs where values are defined (and to know that you have to find those three), and then to look through them to see the valid values. I bet someone will say that we've defined all the smime-type values that we will, and *now* it's stable and we don't need to add any more. I bet we said that after the second time, as well. > I do have a suggestion: > The current registry in draft-leiba-smime-type-registry only has two > columns: smime-type value and Reference. > > Actually, it should have six columns, the additional four columns being: CMS > Type, CMS Type (OID), Inner Content, and Inner Content (OID). For example, > enveloped-data would be CMS Type: EnvelopedData; CMS Type (OID): > 1.2.840.113549.1.7.3; Inner Content: id-data; Inner Content (OID): > 1.2.840.113549.1.7.1. This additional information would make the registry > more useful. I thought about that, and started to write the document that way. Then I had these thoughts: 1. Not all those columns apply to all the values. How do those columns apply to CMC-Request, CMC-Response, and server-generated-key ? What about "certs-only? 1.5. When there are registry columns that often don't apply, people registering new values get confused about how to do their registrations, and what to specify (or not) for those columns. 2. All that information is documented in the reference document for the value, when that information applies. 3. One really needs to go to the reference document to understand how to use the values anyway. Rather than making the registry more complicated, I'd rather have the values documented with a good reference pointer, and leave it at that. Do others think that additional columns in the registry add enough value to put them there, despite those points above? Barry From paul.hoffman@vpnc.org Sat Sep 7 11:09:41 2013 Return-Path: X-Original-To: smime@ietfa.amsl.com Delivered-To: smime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB81911E8176; Sat, 7 Sep 2013 11:09:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.628 X-Spam-Level: X-Spam-Status: No, score=-102.628 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 gVJPX8QsW33P; Sat, 7 Sep 2013 11:09:41 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 3209411E8174; Sat, 7 Sep 2013 11:09:41 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.5) with ESMTP id r87I9X46073970 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 7 Sep 2013 11:09:34 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: Date: Sat, 7 Sep 2013 11:09:33 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8DD1936A-C373-4961-BAAD-103604011C2A@vpnc.org> <522B3C20.105@seantek.com> To: Barry Leiba X-Mailer: Apple Mail (2.1508) Cc: saag , Sean Leonard , smime@ietf.org Subject: Re: [smime] [saag] Fixing the definition of the smime-type parameter by creating a registry X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Sep 2013 18:09:41 -0000 On Sep 7, 2013, at 10:09 AM, Barry Leiba = wrote: > Hi, Sean, and thanks for the comments. >=20 >> The idea of having a registry seems fine, and "RFC Required" seems = fine. >> However, as an active developer in this area, I am weary of having = more >> registries to consult for things that rarely if ever change. I am not = in >> favor of a registry without more evidence that there are = significantly more >> diverse CMS payloads that are expected to be carried in MIME-related = bodies. >=20 > In general, we often think we don't need a registry. And then we add > new values. But we still think we don't need a registry. And then we > add new values again. This is the third time we've added values for > smime-type. I think that says that we need a registry. Better to > consult a registry, where all the values are listed in one place, than > to have to find the three different RFCs where values are defined (and > to know that you have to find those three), and then to look through > them to see the valid values. >=20 > I bet someone will say that we've defined all the smime-type values > that we will, and *now* it's stable and we don't need to add any more. >=20 > I bet we said that after the second time, as well. +1 to what Barry said. Developers don't need to check the registry if = they already know all the values they care about; registries are for = developers who want to know what they don't already know. >> I do have a suggestion: >> The current registry in draft-leiba-smime-type-registry only has two >> columns: smime-type value and Reference. >>=20 >> Actually, it should have six columns, the additional four columns = being: CMS >> Type, CMS Type (OID), Inner Content, and Inner Content (OID). For = example, >> enveloped-data would be CMS Type: EnvelopedData; CMS Type (OID): >> 1.2.840.113549.1.7.3; Inner Content: id-data; Inner Content (OID): >> 1.2.840.113549.1.7.1. This additional information would make the = registry >> more useful. >=20 > I thought about that, and started to write the document that way. > Then I had these thoughts: >=20 > 1. Not all those columns apply to all the values. How do those > columns apply to CMC-Request, CMC-Response, and server-generated-key ? > What about "certs-only? >=20 > 1.5. When there are registry columns that often don't apply, people > registering new values get confused about how to do their > registrations, and what to specify (or not) for those columns. >=20 > 2. All that information is documented in the reference document for > the value, when that information applies. >=20 > 3. One really needs to go to the reference document to understand how > to use the values anyway. >=20 > Rather than making the registry more complicated, I'd rather have the > values documented with a good reference pointer, and leave it at that. >=20 > Do others think that additional columns in the registry add enough > value to put them there, despite those points above? There is a negative value to duplicating information from RFCs in the = registry. Registries should have the absolute minimum amount of = duplicated information from the RFCs. Any developer who cares at all a = protocol will already be looking in the RFC. A developer who only cares = to know what code points are taken doesn't need the rest. This should = not make anyone "weary". --Paul Hoffman= From turners@ieca.com Mon Sep 16 17:14:38 2013 Return-Path: X-Original-To: smime@ietfa.amsl.com Delivered-To: smime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 757DA11E823C for ; Mon, 16 Sep 2013 17:14:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.26 X-Spam-Level: X-Spam-Status: No, score=-102.26 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] 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 i9nnwlE4ItN9 for ; Mon, 16 Sep 2013 17:14:33 -0700 (PDT) Received: from gateway08.websitewelcome.com (gateway08.websitewelcome.com [69.41.248.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6373B11E81D1 for ; Mon, 16 Sep 2013 17:14:33 -0700 (PDT) Received: by gateway08.websitewelcome.com (Postfix, from userid 5007) id 3523B512EF700; Mon, 16 Sep 2013 19:14:33 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway08.websitewelcome.com (Postfix) with ESMTP id E8C2C512EF643 for ; Mon, 16 Sep 2013 19:14:32 -0500 (CDT) Received: from [96.231.225.44] (port=53008 helo=thunderfish.local) by gator3286.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1VLiw3-0008R7-KS; Mon, 16 Sep 2013 19:14:31 -0500 Message-ID: <52379EE6.3030106@ieca.com> Date: Mon, 16 Sep 2013 20:14:30 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Carl Wallace References: <52252589.4050501@ieca.com> In-Reply-To: <52252589.4050501@ieca.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [96.231.225.44]:53008 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 4 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Cc: smime@ietf.org, Paul Hoffman , Stephen Farrell Subject: Re: [smime] some s/mime related drafts I've been asked to AD sponsor X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 00:14:38 -0000 On 9/2/13 7:55 PM, Sean Turner wrote: > On 9/2/13 7:00 PM, Carl Wallace wrote: >> What was the criteria for selecting the items in the innermost content >> type set included in [1]? For example, why include TrustAnchorList >> content type from 5914 but not the TAMP content types from 5934? > > I didn't include the TAMP content types from RFC 5934 because they > already had content types defined. Maybe they should be added though. > >> The interop considerations section states ContentInfo is always the >> outermost structure. Should RFC 4073 be updated to reflect this? > > I'm checking with Russ but I didn't think that ContentCollection would > be used without a ContentInfo wrapper. BTW - I checked with Russ and ContentInfo was always expected to be the outermost wrapper. > spt > >> On 9/2/13 6:23 PM, "Paul Hoffman" wrote: >> >>> S/MIMErs: please take a look at these and let the list know (a) if you >>> have any concerns, (b) if you might implement them, or both. >>> >>> --Paul Hoffman >>> >>> On Sep 2, 2013, at 2:57 PM, Stephen Farrell >>> wrote: >>> >>>> >>>> Folks, >>>> >>>> Sean, Russ and Jim have authored three s/mime related drafts [1,2,3] >>>> and asked me to sponsor them for publication. I've read them and >>>> they seem like reasonable additions to the set of s/mime RFCs to >>>> me, but I'd like to check that nobody has any issue with that >>>> before starting IETF LC in a week or so. >>>> >>>> I'd specifically be interested in hearing from anyone who'd >>>> likely implement these. I'll send my own comments (which are >>>> minor) during the IETF LC. >>>> >>>> Thanks, >>>> S. >>>> >>>> [1] http://tools.ietf.org/html/draft-turner-application-cms-media-type >>>> [2] >>>> http://tools.ietf.org/html/draft-housley-ct-keypackage-receipt-n-error >>>> [3] >>>> >>>> http://tools.ietf.org/html/draft-turner-ct-keypackage-receipt-n-error-alg >>>> >>>> s >>>> >>>> _______________________________________________ >>>> smime mailing list >>>> smime@ietf.org >>>> https://www.ietf.org/mailman/listinfo/smime >>>> >>> >>> _______________________________________________ >>> smime mailing list >>> smime@ietf.org >>> https://www.ietf.org/mailman/listinfo/smime >> >> >> _______________________________________________ >> smime mailing list >> smime@ietf.org >> https://www.ietf.org/mailman/listinfo/smime >> > _______________________________________________ > smime mailing list > smime@ietf.org > https://www.ietf.org/mailman/listinfo/smime > From turners@ieca.com Tue Sep 17 10:59:17 2013 Return-Path: X-Original-To: smime@ietfa.amsl.com Delivered-To: smime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 539CA11E82B7 for ; Tue, 17 Sep 2013 10:59:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.26 X-Spam-Level: X-Spam-Status: No, score=-102.26 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] 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 rKbLO5rO9nLn for ; Tue, 17 Sep 2013 10:59:10 -0700 (PDT) Received: from gateway07.websitewelcome.com (gateway07.websitewelcome.com [69.56.236.22]) by ietfa.amsl.com (Postfix) with ESMTP id C8C2C11E82AC for ; Tue, 17 Sep 2013 10:58:22 -0700 (PDT) Received: by gateway07.websitewelcome.com (Postfix, from userid 5007) id 9804161F9D121; Tue, 17 Sep 2013 12:58:09 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway07.websitewelcome.com (Postfix) with ESMTP id 6298561F9D027 for ; Tue, 17 Sep 2013 12:58:09 -0500 (CDT) Received: from [96.231.225.44] (port=55399 helo=thunderfish.local) by gator3286.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1VLzXX-0006hP-99 for smime@ietf.org; Tue, 17 Sep 2013 12:58:19 -0500 Message-ID: <5238983A.7050002@ieca.com> Date: Tue, 17 Sep 2013 13:58:18 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: smime@ietf.org References: <20130917174854.27398.53769.idtracker@ietfa.amsl.com> In-Reply-To: <20130917174854.27398.53769.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130917174854.27398.53769.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [96.231.225.44]:55399 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 12 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Subject: [smime] Fwd: I-D Action: draft-turner-application-cms-media-type-07.txt X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 17:59:18 -0000 Updated based on comments from Carl (and thanks for the example) and Stephen. spt -------- Original Message -------- Subject: I-D Action: draft-turner-application-cms-media-type-07.txt Date: Tue, 17 Sep 2013 10:48:54 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The application/cms media type Author(s) : Sean Turner Russell Housley Jim Schaad Filename : draft-turner-application-cms-media-type-07.txt Pages : 11 Date : 2013-09-17 Abstract: This document registers the application/cms media types for use with the corresponding CMS (Cryptographic Message Syntax) content types. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-turner-application-cms-media-type There's also a htmlized version available at: http://tools.ietf.org/html/draft-turner-application-cms-media-type-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-turner-application-cms-media-type-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt