From openpgp@brainhub.org Tue Jul 16 13:38:43 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 853DE21E8083 for ; Tue, 16 Jul 2013 13:38:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.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 aFgAx0XleuXU for ; Tue, 16 Jul 2013 13:38:38 -0700 (PDT) Received: from qmta14.emeryville.ca.mail.comcast.net (qmta14.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:212]) by ietfa.amsl.com (Postfix) with ESMTP id 5946521E808B for ; Tue, 16 Jul 2013 13:38:36 -0700 (PDT) Received: from omta21.emeryville.ca.mail.comcast.net ([76.96.30.88]) by qmta14.emeryville.ca.mail.comcast.net with comcast id 18K51m0021u4NiLAE8ebwf; Tue, 16 Jul 2013 20:38:35 +0000 Received: from [127.0.0.1] ([69.181.162.123]) by omta21.emeryville.ca.mail.comcast.net with comcast id 18ea1m00b2g33ZR8h8eaJl; Tue, 16 Jul 2013 20:38:35 +0000 Message-ID: <51E5AE7A.9050502@brainhub.org> Date: Tue, 16 Jul 2013 13:35:06 -0700 From: Andrey Jivsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: smime@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1374007115; bh=gxFRuqkIPPTosifKXlCzGT8NwnP3nJo4UnesvUVVdNQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=S1raxT3Xn/ttJA0xNl+7/Wlf6/z81Y3N2LR8/y1s1Ful4MtI1t2emeg61sXSk9Kor UbtdS+uzVpuVHDkiYaAwbBl5UE2dgtqxQxQOf4BhhwzBd43kjsAPDW6iyoCKIrAA2k 65n1JXJO+UvwjOwjC+9ky1b8QASF+WHVaR3wtbp5PPckcJMpNlSrNmDmUjxNJOflil vBnAaO1SCsQZMTnXSEb9puexOtjLALreSbfrxd5/hWO7hL39F4KEweGOQF7QUyU1/+ oZ2Brn6JO7oWbGxpTv6ZUkgWSsgPwxlCuclbhnLjuMBgQzNSIzaUTgD2ypVzhvgDIA 5ocPNXPRtbeGQ== X-Mailman-Approved-At: Tue, 16 Jul 2013 13:44:44 -0700 Subject: [smime] ECPoint and compression 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, 16 Jul 2013 20:38:43 -0000 Hello SMIME list. Is there any interest in having a usable compression format that implementations would find appealing implement/enable? SMIME stands out in my mind because of the storage benefit in case of a short message ECC-encrypted to a large number of recipients. In this common scenario the size of security-related overhead may be comparable or often exceeds the plaintext payload. CMS ECC RFC (http://tools.ietf.org/html/rfc5753) refers to SPKI RFC (http://tools.ietf.org/html/rfc5480) with the following details about ECPoint: > > 2.2 . Subject > Public Key > > > > The subjectPublicKey from SubjectPublicKeyInfo is the ECC public key. > ECC public keys have the following syntax: > > ECPoint ::= OCTET STRING > > Implementations of Elliptic Curve Cryptography according to this > document MUST support the uncompressed form and MAY support the > compressed form of the ECC public key. The hybrid form of the ECC > public key from [X9.62 ] MUST NOT be used. As specified in [SEC1 ]: > > o The elliptic curve public key (a value of type ECPoint that is > an OCTET STRING) is mapped to a subjectPublicKey (a value of > type BIT STRING) as follows: the most significant bit of the > OCTET STRING value becomes the most significant bit of the BIT > STRING value, and so on; the least significant bit of the OCTET > STRING becomes the least significant bit of the BIT STRING. > Conversion routines are found in Sections2.3.1 and2.3.2 of > [SEC1 ]. > > o The first octet of the OCTET STRING indicates whether the key is > compressed or uncompressed. The uncompressed form is indicated > by 0x04 and the compressed form is indicated by either 0x02 or > 0x03 (see 2.3.3 in [SEC1 ]). The public key MUST be rejected if > any other value is included in the first octet. I wrote a proposal for, I will argue, a better format here: http://tools.ietf.org/html/draft-jivsov-ecc-compact IMO the business of 1 bit preservation is an unnecessary complexity, especially in ECDH scenarios. One way to integrate the compact representation above is to say that OCTET STRING above is simply the "x" of the point. Given that this encoding is always 1 byte shorter than the SEC1, this overloading is unambiguous. Is there interest in this proposal? Would it make a difference in the actual usage of the compact representation? ( My other immediate plan with this format is to use it as the format for OpenPGP analog of the ECPoint. ) Thank you. From ayhan.sehrin@verion.com.tr Sat Jul 20 03:33:07 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 85A2F11E8187 for ; Sat, 20 Jul 2013 03:33:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.003 X-Spam-Level: X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MISSING_MIMEOLE=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 P+wdRHP48RY7 for ; Sat, 20 Jul 2013 03:33:02 -0700 (PDT) Received: from serv01.siteground315.com (ns1.siteground315.com [184.154.160.6]) by ietfa.amsl.com (Postfix) with ESMTP id 2AD1111E80E2 for ; Sat, 20 Jul 2013 03:33:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=verion.com.tr; s=dkim; h=Content-Type:MIME-Version:Message-ID:Date:Subject:Cc:To:From; bh=2Mo2Pa/78C9XYtTLoIcqKsFZ1myN6udXFwIdr4YyfV4=; b=lalu0cxtWv3ISCdEb1drqLtbIK4c2iReAuSNdz2Q+iTAzNiD6Ksj5Lvlxw25CazJy7ejZScsddfDuMrsK97xgcA4XU0nyRnwf8E7GYTbMIGFaIw7xqPWtKrlm33/JTrsNL3Yst6AfuVdUAA8JhLm78tAKBDsJfS9urtpmJTdkoo=; Received: from [85.104.46.181] (port=10037 helo=PC) by serv01.siteground315.com with esmtpa (Exim 4.80.1) (envelope-from ) id 1V0UTC-0001yc-Vc; Sat, 20 Jul 2013 05:32:59 -0500 From: "Ayhan Sehrin" To: Date: Sat, 20 Jul 2013 13:33:02 +0300 Message-ID: <06d201ce8534$8512d2c0$8f387840$@verion.com.tr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_06D3_01CE854D.AA622DA0" X-Priority: 1 (Highest) X-MSMail-Priority: High X-Mailer: Microsoft Outlook 14.0 Importance: High Thread-Index: Ac6FMwo4x2RnQ54jTla/mKow1GAf2Q== Content-Language: tr X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - serv01.siteground315.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - verion.com.tr X-Get-Message-Sender-Via: serv01.siteground315.com: none X-Mailman-Approved-At: Sat, 20 Jul 2013 08:19:10 -0700 Subject: [smime] Inquiry on the usage of CAdES in S/MIME structures 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, 20 Jul 2013 10:36:51 -0000 This is a multipart message in MIME format. ------=_NextPart_000_06D3_01CE854D.AA622DA0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear list Members,=20 =20 As Verion Technology Group, a technology provider working on Registered = E-Mail (REM) solutions since 2009, we are currently in the process of = formulating a set of basic implementation principles and tools for REM = Management Domain (MD)=E2=80=99s operative in Turkey. We need to resort = to your experience and know-how on the subject of the S/MIME = specification, and I was kindly prompted by Mr. Blake Ramsdell to = address your list for further comments and insight. The Registered E-Mail Regulatory Authority in Turkey has very recently = mandated the use of the CAdES-A profile within the S/MIME structure and = as we are a bit perplexed on the issue, we would like to inquire your = comments on: - whether it would be logical/feasible/meaningful to use the CAdES-A = profile within an S/MIME structure (for some instances within the REM = workflow CAdES-BES is also required) - whether the above usage would present difficulties/problems in terms = of interoperability of systems (i.e. e-mail clients or BPM/ERP systems, = where the messages are expected to be utilised - e.g. a REM message = received is downloaded and then used as the input of a business process = within a core banking component) especially as regards the subsequent = verification process within these systems and among different REM = Service Providers in Turkey and in Europe (as Turkey has opted in to the = ETSI TS 102640). - whether, from a technical viewpoint, the implementation of an S/MIME = structure with the usage of a CAdES signature presents a problem with = the S/MIME RFC - whether the S/MIME RFC should be expected to natively accomodate CAdES = profiles in the near future=20 We would gladly provide more details on the ETSI 102640 implementation = in Turkey, if it is of essense to the above inquiries.=20 We will be much obliged, should you be able to provide insight. Thank you in advance and warm regards, Ayhan =C5=9EEHR=C4=B0N Man. Director Verion Technology Group Birlik Mah. 435. Cad. 403. Sok. No:3/3 =C3=87ankaya, Ankara - Turkey +90 312 496 3316 (office) +90 533 556 3333 (mobile) =20 NB-REM implementation in Turkey in a tiny nutshell: In the typical REM = implementation in Turkey, an original message is required to be signed = with the sender=E2=80=99s Qualified Electronic Signature, two out of the = currently three REMSPs provide tools for constructing and signing the = sender=E2=80=99s S/MIME structure on the client, receive it over https = (or over a web service for enterprise integration instances) to the = REMSP servers. The third REMSP constructs the MIME message on its own = server, hashes it an sends it for a CAdES signature to the = sender=E2=80=99s client. Evidence is produced by REMSPs during the mail = acceptance, delivery and retrieval milestones and is expected to be = stored in WORM storage or to be archived, XadES-A for evidence, CAdES-A = for all system logs.=20 ------=_NextPart_000_06D3_01CE854D.AA622DA0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Dear list Members,

 

As Verion Technology Group, a technology provider working on = Registered E-Mail (REM) solutions since 2009, we are currently in the = process of formulating a set of basic implementation principles and = tools for REM Management Domain (MD)=E2=80=99s operative in Turkey. We = need to resort to your experience and know-how on the subject of the = S/MIME specification, and I was kindly prompted by Mr. Blake Ramsdell to = address your list for further comments and insight.

The = Registered E-Mail Regulatory Authority in Turkey has very recently = mandated the use of the CAdES-A profile within the S/MIME structure and = as we are a bit perplexed on the issue, we would like to inquire your = comments on:

- whether it would be logical/feasible/meaningful to use the CAdES-A = profile within an S/MIME structure (for some instances within the REM = workflow CAdES-BES is also required)
- whether the above usage would = present difficulties/problems in terms of interoperability of systems = (i.e. e-mail clients or BPM/ERP systems, where the messages are expected = to be utilised - e.g. a REM message received is downloaded and then used = as the input of a business process within a core banking component) = especially as regards the subsequent verification process within these = systems and among different REM Service Providers in Turkey and in = Europe (as Turkey has opted in to the ETSI TS 102640).
- whether, = from a technical viewpoint, the implementation of an S/MIME structure = with the usage of a CAdES signature presents a problem with the S/MIME = RFC

- whether the S/MIME RFC should be expected to natively accomodate = CAdES profiles in the near future


We would gladly provide more details on the ETSI 102640 = implementation in Turkey, if it is of essense to the above inquiries. =
We will be much obliged, should you be able to provide = insight.

Thank you in advance and warm regards,


Ayhan = =C5=9EEHR=C4=B0N
Man. Director
Verion Technology Group
Birlik = Mah. 435. Cad. 403. Sok. No:3/3
=C3=87ankaya, Ankara - = Turkey

+90 312 496 = 3316 (office)
+90 533 556 = 3333 (mobile)

 

NB-REM implementation in Turkey in a tiny nutshell: In the typical = REM implementation in Turkey, an original message is required to be = signed with the sender=E2=80=99s Qualified Electronic Signature, two out = of the currently three REMSPs provide tools for constructing and signing = the sender=E2=80=99s S/MIME structure on the client, receive it over = https (or over a web service for enterprise integration instances) to = the REMSP servers. The third REMSP constructs the MIME message on its = own server, hashes it an sends it for a CAdES signature to the = sender=E2=80=99s client. Evidence is produced by REMSPs during the mail = acceptance, delivery and retrieval milestones and is expected to be = stored in WORM storage or to be archived, XadES-A for evidence, CAdES-A = for all system logs.



------=_NextPart_000_06D3_01CE854D.AA622DA0-- From anders.rundgren@telia.com Sun Jul 21 00:18:00 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 78A5311E80F2 for ; Sun, 21 Jul 2013 00:18:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.949 X-Spam-Level: X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 4s0XBCJxGjKJ for ; Sun, 21 Jul 2013 00:17:55 -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 5FF1D21F8B04 for ; Sun, 21 Jul 2013 00:17:55 -0700 (PDT) Received: from [192.168.0.202] (213.64.1.89) by smtp-out12.han.skanova.net (8.5.133) (authenticated as u36408181) id 51B4DDE70082DBF8; Sun, 21 Jul 2013 09:17:48 +0200 Message-ID: <51EB8B1A.8070108@telia.com> Date: Sun, 21 Jul 2013 09:17:46 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Ayhan Sehrin References: <06d201ce8534$8512d2c0$8f387840$@verion.com.tr> In-Reply-To: <06d201ce8534$8512d2c0$8f387840$@verion.com.tr> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: smime@ietf.org Subject: Re: [smime] Inquiry on the usage of CAdES in S/MIME structures 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: Sun, 21 Jul 2013 07:18:00 -0000 On 2013-07-20 12:33, Ayhan Sehrin wrote: Hi Ayhan, Using CAdES in S/MIME structures should be possible with or without an RFC. Using CAdES together with desktop clients is less feasible and it would probably require a minor miracle fixing it. OTOH, it seems that your REM solution rather builds on web technology so then there are no hurdles at all! Thanx Anders Rundgren > Dear list Members, > > As Verion Technology Group, a technology provider working on Registered E-Mail (REM) solutions since 2009, we are currently in the process of formulating a set of basic implementation principles and tools for REM Management Domain (MD)’s operative in Turkey. We need to resort to your experience and know-how on the subject of the S/MIME specification, and I was kindly prompted by Mr. Blake Ramsdell to address your list for further comments and insight. > > The Registered E-Mail Regulatory Authority in Turkey has very recently mandated the use of the CAdES-A profile within the S/MIME structure and as we are a bit perplexed on the issue, we would like to inquire your comments on: > > - whether it would be logical/feasible/meaningful to use the CAdES-A profile within an S/MIME structure (for some instances within the REM workflow CAdES-BES is also required) > - whether the above usage would present difficulties/problems in terms of interoperability of systems (i.e. e-mail clients or BPM/ERP systems, where the messages are expected to be utilised - e.g. a REM message received is downloaded and then used as the input of a business process within a core banking component) especially as regards the subsequent verification process within these systems and among different REM Service Providers in Turkey and in Europe (as Turkey has opted in to the ETSI TS 102640). > - whether, from a technical viewpoint, the implementation of an S/MIME structure with the usage of a CAdES signature presents a problem with the S/MIME RFC > > - whether the S/MIME RFC should be expected to natively accomodate CAdES profiles in the near future > > > We would gladly provide more details on the ETSI 102640 implementation in Turkey, if it is of essense to the above inquiries. > We will be much obliged, should you be able to provide insight. > > Thank you in advance and warm regards, > > > Ayhan ŞEHRİN > Man. Director > Verion Technology Group > Birlik Mah. 435. Cad. 403. Sok. No:3/3 > Çankaya, Ankara - Turkey > > +90 312 496 3316 (office) > +90 533 556 3333 (mobile) > > NB-REM implementation in Turkey in a tiny nutshell: In the typical REM implementation in Turkey, an original message is required to be signed with the sender’s Qualified Electronic Signature, two out of the currently three REMSPs provide tools for constructing and signing the sender’s S/MIME structure on the client, receive it over https (or over a web service for enterprise integration instances) to the REMSP servers. The third REMSP constructs the MIME message on its own server, hashes it an sends it for a CAdES signature to the sender’s client. Evidence is produced by REMSPs during the mail acceptance, delivery and retrieval milestones and is expected to be stored in WORM storage or to be archived, XadES-A for evidence, CAdES-A for all system logs. > > > > > > _______________________________________________ > smime mailing list > smime@ietf.org > https://www.ietf.org/mailman/listinfo/smime From ayhan.sehrin@verion.com.tr Sun Jul 21 13:06:08 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 2F4F821F9C7B for ; Sun, 21 Jul 2013 13:06:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.873 X-Spam-Level: X-Spam-Status: No, score=-1.873 tagged_above=-999 required=5 tests=[AWL=0.726, 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 HioV8dh68pCm for ; Sun, 21 Jul 2013 13:06:03 -0700 (PDT) Received: from serv01.siteground315.com (ns1.siteground315.com [184.154.160.6]) by ietfa.amsl.com (Postfix) with ESMTP id 7C94B21F991E for ; Sun, 21 Jul 2013 13:06:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=verion.com.tr; s=dkim; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=W5c8qtVZOtsLXc45fjOvJtgbEeLH5oKy5Fls+gzs7i4=; b=hU3S/jFWfeUfj2UDSeSmIpUL4tmC21I1xaC2yuSiCXqE7ML3jookFntEInZv4GBKcwUb0AwbtSuMznrElaJg94qskD0trRVcN747J9VVpoMrgtDo4dddTkiri0VleLvXSC6CC/HiqlUXDKm04N/1HZxIV3SOEPKAgsFgMNcnsgA=; Received: from [85.104.46.181] (port=20821 helo=PC) by serv01.siteground315.com with esmtpa (Exim 4.80.1) (envelope-from ) id 1V0ztH-0000SS-9P; Sun, 21 Jul 2013 15:05:59 -0500 From: "Ayhan Sehrin" To: "'Anders Rundgren'" References: <06d201ce8534$8512d2c0$8f387840$@verion.com.tr> <51EB8B1A.8070108@telia.com> In-Reply-To: <51EB8B1A.8070108@telia.com> Date: Sun, 21 Jul 2013 23:05:58 +0300 Message-ID: <000001ce864d$b91b4920$2b51db60$@verion.com.tr> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFFs5/1He1Arq9fZLojFDl2xZvSTADfQmHzmno5HEA= Content-Language: tr X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - serv01.siteground315.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - verion.com.tr X-Get-Message-Sender-Via: serv01.siteground315.com: none Cc: ugur.dundar@verion.com.tr, bulent.kaptan@verion.com.tr, smime@ietf.org Subject: Re: [smime] Inquiry on the usage of CAdES in S/MIME structures 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: Sun, 21 Jul 2013 20:06:08 -0000 Thanks Anders for the quick info. Could you possibly elaborate just a = little bit? Do you mean that a CAdES-BES (for some purposes -A) signed S/MIME = message should not have any verification and processing problems with = the various e-mail clients and other REM implementations? Kind regards, Ayhan =C5=9Eehrin -----Original Message----- From: Anders Rundgren [mailto:anders.rundgren@telia.com]=20 Sent: Sunday, July 21, 2013 10:18 AM To: Ayhan Sehrin Cc: smime@ietf.org Subject: Re: [smime] Inquiry on the usage of CAdES in S/MIME structures On 2013-07-20 12:33, Ayhan Sehrin wrote: Hi Ayhan, Using CAdES in S/MIME structures should be possible with or without an = RFC. Using CAdES together with desktop clients is less feasible and it would = probably require a minor miracle fixing it. OTOH, it seems that your REM solution rather builds on web technology so = then there are no hurdles at all! Thanx Anders Rundgren > Dear list Members, > > As Verion Technology Group, a technology provider working on = Registered E-Mail (REM) solutions since 2009, we are currently in the = process of formulating a set of basic implementation principles and = tools for REM Management Domain (MD)=E2=80=99s operative in Turkey. We = need to resort to your experience and know-how on the subject of the = S/MIME specification, and I was kindly prompted by Mr. Blake Ramsdell to = address your list for further comments and insight. > > The Registered E-Mail Regulatory Authority in Turkey has very recently = mandated the use of the CAdES-A profile within the S/MIME structure and = as we are a bit perplexed on the issue, we would like to inquire your = comments on: > > - whether it would be logical/feasible/meaningful to use the CAdES-A=20 > profile within an S/MIME structure (for some instances within the REM=20 > workflow CAdES-BES is also required) > - whether the above usage would present difficulties/problems in terms = of interoperability of systems (i.e. e-mail clients or BPM/ERP systems, = where the messages are expected to be utilised - e.g. a REM message = received is downloaded and then used as the input of a business process = within a core banking component) especially as regards the subsequent = verification process within these systems and among different REM = Service Providers in Turkey and in Europe (as Turkey has opted in to the = ETSI TS 102640). > - whether, from a technical viewpoint, the implementation of an S/MIME = > structure with the usage of a CAdES signature presents a problem with=20 > the S/MIME RFC > > - whether the S/MIME RFC should be expected to natively accomodate=20 > CAdES profiles in the near future > > > We would gladly provide more details on the ETSI 102640 implementation = in Turkey, if it is of essense to the above inquiries. > We will be much obliged, should you be able to provide insight. > > Thank you in advance and warm regards, > > > Ayhan =C5=9EEHR=C4=B0N > Man. Director > Verion Technology Group > Birlik Mah. 435. Cad. 403. Sok. No:3/3 =C3=87ankaya, Ankara - Turkey > > +90 312 496 3316 (office) > +90 533 556 3333 (mobile) > > NB-REM implementation in Turkey in a tiny nutshell: In the typical REM = implementation in Turkey, an original message is required to be signed = with the sender=E2=80=99s Qualified Electronic Signature, two out of the = currently three REMSPs provide tools for constructing and signing the = sender=E2=80=99s S/MIME structure on the client, receive it over https = (or over a web service for enterprise integration instances) to the = REMSP servers. The third REMSP constructs the MIME message on its own = server, hashes it an sends it for a CAdES signature to the = sender=E2=80=99s client. Evidence is produced by REMSPs during the mail = acceptance, delivery and retrieval milestones and is expected to be = stored in WORM storage or to be archived, XadES-A for evidence, CAdES-A = for all system logs. > > > > > > _______________________________________________ > smime mailing list > smime@ietf.org > https://www.ietf.org/mailman/listinfo/smime From anders.rundgren@telia.com Sun Jul 21 22:21:33 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 C314321F9302 for ; Sun, 21 Jul 2013 22:21:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.166 X-Spam-Level: X-Spam-Status: No, score=-3.166 tagged_above=-999 required=5 tests=[AWL=0.433, 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 Z+G0Hb-y-bNd for ; Sun, 21 Jul 2013 22:21:22 -0700 (PDT) Received: from smtp-out21.han.skanova.net (smtp-out21.han.skanova.net [195.67.226.208]) by ietfa.amsl.com (Postfix) with ESMTP id 2F31421F8449 for ; Sun, 21 Jul 2013 22:21:21 -0700 (PDT) Received: from [192.168.0.202] (213.64.1.89) by smtp-out21.han.skanova.net (8.5.133) (authenticated as u36408181) id 51AC783600F90878; Mon, 22 Jul 2013 07:21:11 +0200 Message-ID: <51ECC142.9010906@telia.com> Date: Mon, 22 Jul 2013 07:21:06 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Ayhan Sehrin References: <06d201ce8534$8512d2c0$8f387840$@verion.com.tr> <51EB8B1A.8070108@telia.com> <000001ce864d$b91b4920$2b51db60$@verion.com.tr> In-Reply-To: <000001ce864d$b91b4920$2b51db60$@verion.com.tr> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: ugur.dundar@verion.com.tr, bulent.kaptan@verion.com.tr, smime@ietf.org Subject: Re: [smime] Inquiry on the usage of CAdES in S/MIME structures 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, 22 Jul 2013 05:21:33 -0000 On 2013-07-21 22:05, Ayhan Sehrin wrote: > Thanks Anders for the quick info. Could you possibly elaborate just a little bit? > Do you mean that a CAdES-BES (for some purposes -A) signed S/MIME message should > not have any verification and processing problems with the various e-mail clients > and other REM implementations? Hi Ayhan, No, I meant that if REM builds on web-technology you can use whatever signature technology you want but if you need to use standard e-mail clients you will be stuck with S/MIME as it is today. Regards, Anders > Kind regards, > > Ayhan Şehrin > > -----Original Message----- > From: Anders Rundgren [mailto:anders.rundgren@telia.com] > Sent: Sunday, July 21, 2013 10:18 AM > To: Ayhan Sehrin > Cc: smime@ietf.org > Subject: Re: [smime] Inquiry on the usage of CAdES in S/MIME structures > > On 2013-07-20 12:33, Ayhan Sehrin wrote: > > Hi Ayhan, > > Using CAdES in S/MIME structures should be possible with or without an RFC. > > Using CAdES together with desktop clients is less feasible and it would probably require a minor miracle fixing it. > > OTOH, it seems that your REM solution rather builds on web technology so then there are no hurdles at all! > > Thanx > Anders Rundgren > >> Dear list Members, >> >> As Verion Technology Group, a technology provider working on Registered E-Mail (REM) solutions since 2009, we are currently in the process of formulating a set of basic implementation principles and tools for REM Management Domain (MD)’s operative in Turkey. We need to resort to your experience and know-how on the subject of the S/MIME specification, and I was kindly prompted by Mr. Blake Ramsdell to address your list for further comments and insight. >> >> The Registered E-Mail Regulatory Authority in Turkey has very recently mandated the use of the CAdES-A profile within the S/MIME structure and as we are a bit perplexed on the issue, we would like to inquire your comments on: >> >> - whether it would be logical/feasible/meaningful to use the CAdES-A >> profile within an S/MIME structure (for some instances within the REM >> workflow CAdES-BES is also required) >> - whether the above usage would present difficulties/problems in terms of interoperability of systems (i.e. e-mail clients or BPM/ERP systems, where the messages are expected to be utilised - e.g. a REM message received is downloaded and then used as the input of a business process within a core banking component) especially as regards the subsequent verification process within these systems and among different REM Service Providers in Turkey and in Europe (as Turkey has opted in to the ETSI TS 102640). >> - whether, from a technical viewpoint, the implementation of an S/MIME >> structure with the usage of a CAdES signature presents a problem with >> the S/MIME RFC >> >> - whether the S/MIME RFC should be expected to natively accomodate >> CAdES profiles in the near future >> >> >> We would gladly provide more details on the ETSI 102640 implementation in Turkey, if it is of essense to the above inquiries. >> We will be much obliged, should you be able to provide insight. >> >> Thank you in advance and warm regards, >> >> >> Ayhan ŞEHRİN >> Man. Director >> Verion Technology Group >> Birlik Mah. 435. Cad. 403. Sok. No:3/3 Çankaya, Ankara - Turkey >> >> +90 312 496 3316 (office) >> +90 533 556 3333 (mobile) >> >> NB-REM implementation in Turkey in a tiny nutshell: In the typical REM implementation in Turkey, an original message is required to be signed with the sender’s Qualified Electronic Signature, two out of the currently three REMSPs provide tools for constructing and signing the sender’s S/MIME structure on the client, receive it over https (or over a web service for enterprise integration instances) to the REMSP servers. The third REMSP constructs the MIME message on its own server, hashes it an sends it for a CAdES signature to the sender’s client. Evidence is produced by REMSPs during the mail acceptance, delivery and retrieval milestones and is expected to be stored in WORM storage or to be archived, XadES-A for evidence, CAdES-A for all system logs. >> >> >> >> >> >> _______________________________________________ >> smime mailing list >> smime@ietf.org >> https://www.ietf.org/mailman/listinfo/smime > > From bilal.ashraf@ascertia.com Sun Jul 21 22:32: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 D8D2D21E8064 for ; Sun, 21 Jul 2013 22:32:10 -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 VDz4mSNTGveI for ; Sun, 21 Jul 2013 22:32:06 -0700 (PDT) Received: from mail.ascertia.com (www.ascertia.com [94.136.44.32]) by ietfa.amsl.com (Postfix) with ESMTP id 6919C21E80A3 for ; Sun, 21 Jul 2013 22:31:58 -0700 (PDT) Received: from [192.168.0.85] ([202.141.240.172]) by ascertia.com with MailEnable ESMTP; Mon, 22 Jul 2013 06:34:21 +0100 Message-ID: <51ECC315.9000400@ascertia.com> Date: Mon, 22 Jul 2013 10:28:53 +0500 From: Bilal Ashraf User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: ayhan.sehrin@verion.com.tr, smime@ietf.org References: <06d201ce8534$8512d2c0$8f387840$@verion.com.tr> In-Reply-To: <06d201ce8534$8512d2c0$8f387840$@verion.com.tr> Content-Type: multipart/alternative; boundary="------------030008050208090807030403" X-ME-Bayesian: 0.000000 Subject: Re: [smime] Inquiry on the usage of CAdES in S/MIME structures 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, 22 Jul 2013 05:32:11 -0000 This is a multi-part message in MIME format. --------------030008050208090807030403 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Ayhan, Please see my responses below. Hope it is useful for you. Regards, Bilal. On 7/20/2013 3:33 PM, Ayhan Sehrin wrote: > > Dear list Members, > > As Verion Technology Group, a technology provider working on=20 > Registered E-Mail (REM) solutions since 2009, we are currently in the=20 > process of formulating a set of basic implementation principles and=20 > tools for REM Management Domain (MD)'s operative in Turkey. We need to = > resort to your experience and know-how on the subject of the S/MIME=20 > specification, and I was kindly prompted by Mr. Blake Ramsdell to=20 > address your list for further comments and insight. > > The Registered E-Mail Regulatory Authority in Turkey has very recently = > mandated the use of the CAdES-A profile within the S/MIME structure=20 > and as we are a bit perplexed on the issue, we would like to inquire=20 > your comments on: > > - whether it would be logical/feasible/meaningful to use the CAdES-A=20 > profile within an S/MIME structure (for some instances within the REM=20 > workflow CAdES-BES is also required) > Yes, It is possible according to the standard (RFC 3851 and ETSI TS 101=20 733 V1.8.1). > > - whether the above usage would present difficulties/problems in terms = > of interoperability of systems (i.e. e-mail clients or BPM/ERP=20 > systems, where the messages are expected to be utilised - e.g. a REM=20 > message received is downloaded and then used as the input of a=20 > business process within a core banking component) especially as=20 > regards the subsequent verification process within these systems and=20 > among different REM Service Providers in Turkey and in Europe (as=20 > Turkey has opted in to the ETSI TS 102640). > If existing clients/applications has to generate or verify CAdES-A=20 signatures then they need to update their implementations. Also existing = clients/applications don't break if they have CAdES-A signature and=20 don't want to process CAdES-A specific attributes. I don't think of any=20 email client supporting CAdES-A signatures. > > - whether, from a technical viewpoint, the implementation of an S/MIME = > structure with the usage of a CAdES signature presents a problem with=20 > the S/MIME RFC > I don't think so. > > - whether the S/MIME RFC should be expected to natively accomodate=20 > CAdES profiles in the near future > There is a section in ETSI TS 101 733 V1.8.1 about how to use MIME in CAd= ES. > > > We would gladly provide more details on the ETSI 102640 implementation = > in Turkey, if it is of essense to the above inquiries. > > We will be much obliged, should you be able to provide insight. > > Thank you in advance and warm regards, > > > Ayhan S,EHRI.N > Man. Director > Verion Technology Group > Birlik Mah. 435. Cad. 403. Sok. No:3/3 > =C7ankaya, Ankara - Turkey > > +90 312 496 3316 (office) > +90 533 556 3333 (mobile) > > NB-REM implementation in Turkey in a tiny nutshell: In the typical REM = > implementation in Turkey, an original message is required to be signed = > with the sender's Qualified Electronic Signature, two out of the=20 > currently three REMSPs provide tools for constructing and signing the=20 > sender's S/MIME structure on the client, receive it over https (or=20 > over a web service for enterprise integration instances) to the REMSP=20 > servers. The third REMSP constructs the MIME message on its own=20 > server, hashes it an sends it for a CAdES signature to the sender's=20 > client. Evidence is produced by REMSPs during the mail acceptance,=20 > delivery and retrieval milestones and is expected to be stored in WORM = > storage or to be archived, XadES-A for evidence, CAdES-A for all=20 > system logs. > > > > > > _______________________________________________ > smime mailing list > smime@ietf.org > https://www.ietf.org/mailman/listinfo/smime --------------030008050208090807030403 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit
Hi Ayhan,

Please see my responses below. Hope it is useful for you.

Regards,
Bilal.

On 7/20/2013 3:33 PM, Ayhan Sehrin wrote:

Dear list Members,

 

As Verion Technology Group, a technology provider working on Registered E-Mail (REM) solutions since 2009, we are currently in the process of formulating a set of basic implementation principles and tools for REM Management Domain (MD)’s operative in Turkey. We need to resort to your experience and know-how on the subject of the S/MIME specification, and I was kindly prompted by Mr. Blake Ramsdell to address your list for further comments and insight.

The Registered E-Mail Regulatory Authority in Turkey has very recently mandated the use of the CAdES-A profile within the S/MIME structure and as we are a bit perplexed on the issue, we would like to inquire your comments on:

- whether it would be logical/feasible/meaningful to use the CAdES-A profile within an S/MIME structure (for some instances within the REM workflow CAdES-BES is also required)

Yes, It is possible according to the standard (RFC 3851 and ETSI TS 101 733 V1.8.1).

- whether the above usage would present difficulties/problems in terms of interoperability of systems (i.e. e-mail clients or BPM/ERP systems, where the messages are expected to be utilised - e.g. a REM message received is downloaded and then used as the input of a business process within a core banking component) especially as regards the subsequent verification process within these systems and among different REM Service Providers in Turkey and in Europe (as Turkey has opted in to the ETSI TS 102640).

If existing clients/applications has to generate or verify CAdES-A signatures then they need to update their implementations. Also existing clients/applications don't break if they have CAdES-A signature and don't want to process CAdES-A specific attributes. I don't think of any email client supporting CAdES-A signatures.

- whether, from a technical viewpoint, the implementation of an S/MIME structure with the usage of a CAdES signature presents a problem with the S/MIME RFC

I don't think so.

- whether the S/MIME RFC should be expected to natively accomodate CAdES profiles in the near future

There is a section in ETSI TS 101 733 V1.8.1 about how to use MIME in CAdES.


We would gladly provide more details on the ETSI 102640 implementation in Turkey, if it is of essense to the above inquiries.

We will be much obliged, should you be able to provide insight.

Thank you in advance and warm regards,


Ayhan ŞEHRİN
Man. Director
Verion Technology Group
Birlik Mah. 435. Cad. 403. Sok. No:3/3
Çankaya, Ankara - Turkey

+90 312 496 3316 (office)
+90 533 556 3333 (mobile)

 

NB-REM implementation in Turkey in a tiny nutshell: In the typical REM implementation in Turkey, an original message is required to be signed with the sender’s Qualified Electronic Signature, two out of the currently three REMSPs provide tools for constructing and signing the sender’s S/MIME structure on the client, receive it over https (or over a web service for enterprise integration instances) to the REMSP servers. The third REMSP constructs the MIME message on its own server, hashes it an sends it for a CAdES signature to the sender’s client. Evidence is produced by REMSPs during the mail acceptance, delivery and retrieval milestones and is expected to be stored in WORM storage or to be archived, XadES-A for evidence, CAdES-A for all system logs. 





_______________________________________________
smime mailing list
smime@ietf.org
https://www.ietf.org/mailman/listinfo/smime

--------------030008050208090807030403-- From prvs=0916204882=peter.rybar@nbusr.sk Tue Jul 23 03:39:00 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 690B811E81D0 for ; Tue, 23 Jul 2013 03:39:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.693 X-Spam-Level: X-Spam-Status: No, score=-0.693 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 8A9lVKcRFdNu for ; Tue, 23 Jul 2013 03:38:56 -0700 (PDT) Received: from mail.nbusr.sk (mail.nbusr.sk [84.245.65.227]) by ietfa.amsl.com (Postfix) with ESMTP id CE6D811E81A5 for ; Tue, 23 Jul 2013 03:38:52 -0700 (PDT) From: "Peter Rybar" To: "'Ayhan Sehrin'" Date: Tue, 23 Jul 2013 12:38:49 +0200 Message-ID: <201307231038.r6NAcnZl014086@mail.nbusr.sk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01CE87A1.95453BF0" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <06d201ce8534$8512d2c0$8f387840$@verion.com.tr> Thread-Index: Ac6FMwo4x2RnQ54jTla/mKow1GAf2QCW6ozA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 6 X-NAI-Spam-Score: 0.1 X-NAI-Spam-Version: 2.3.0.9362 : core <4647> : streams <1004899> : uri <1484569> Cc: smime@ietf.org Subject: Re: [smime] Inquiry on the usage of CAdES in S/MIME structures 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, 23 Jul 2013 10:39:00 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0006_01CE87A1.95453BF0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Dear Ayhan, =20 Archive format of CMS CAdES-A can be implemented with many versions of = archive time-stamps. =20 Only archive time-stamp version 3 (ATSv3) is fixed for S/MIME usage. The ATSv3 must include the ats-hash-index attribute which shall be = carried as an unsigned attribute of the signature of the = archive-time-stamp-v3 Attribute (see clause 6.4.3 ETSI TS 101 733 V2.2.1 = (2013-04)).=20 =20 The ats-hash-index unsigned attribute provides an unambiguous imprint of = the essential components of a CAdES signature for use in the archive = time-stamp (see 6.4.3). These essential components are elements of the = following ASN.1 SET OF structures: unsignedAttrs, = SignedData.certificates, and SignedData.crls.=20 =20 The redundant CAdES attributes are not required to be included in CMS = when ATSv3 is used e.g. now are used CMS fields like the SignedData.crls = component as defined in RFC 3852 [4] which can include OCSP and/or CRL = revocation information.=20 Use of the ats-hash-index attribute makes it possible to add additional = certificate / revocation information / unsigned attribute within = SignedData.certificates/ SignedData.crls/ unsigned attributes of the = CAdES signature (for instance counter signatures), after an archive = time-stamp has been applied to a signature. Its use also allows the = inclusion of components required by parallel signatures at a later time. =20 Previous archive time-stamp versions before version 3 have some problems = e.g. with adding S/MIME unsigned attribute after archive time-stamp or = problems with parallel CMS signatures when one of parallel signatures = contains archive timestamp. =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 Previous versions of CAdES specification have defined many redundant = attributes. The usage of redundant attributes was deprecated in the last profile. =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 It means the use of the CAdES-A profile within the S/MIME structure is = possible without know problems only when ATSv3 is included. =20 More information is from the page 15. It is about: ETSI ESI deprecates = long-term formats http://files.lockitin.webnode.sk/200000078-00104010a3/12th%20Edition%20of= %20the%20Conference%20June%2004-06th%202012%20Poland.ppt=20 =20 Best regards, Peter Rybar National Security Authority Information Security and Electronic Signature Department Budatinska 30, 850 07 Bratislava 57, Slovak Republic tel.: +421 2 6869 2163 mob.: +421 902 891 155 fax: +421 2 6869 1701 e-mail: peter.rybar@nbusr.sk e-mail: peterryb@gmail.com =20 =20 _____ =20 From: smime-bounces@ietf.org [mailto:smime-bounces@ietf.org] On Behalf = Of Ayhan Sehrin Sent: Saturday, July 20, 2013 12:33 PM To: smime@ietf.org Subject: [smime] Inquiry on the usage of CAdES in S/MIME structures Importance: High =20 Dear list Members,=20 =20 As Verion Technology Group, a technology provider working on Registered = E-Mail (REM) solutions since 2009, we are currently in the process of = formulating a set of basic implementation principles and tools for REM = Management Domain (MD)=E2=80=99s operative in Turkey. We need to resort = to your experience and know-how on the subject of the S/MIME = specification, and I was kindly prompted by Mr. Blake Ramsdell to = address your list for further comments and insight. The Registered E-Mail Regulatory Authority in Turkey has very recently = mandated the use of the CAdES-A profile within the S/MIME structure and = as we are a bit perplexed on the issue, we would like to inquire your = comments on: - whether it would be logical/feasible/meaningful to use the CAdES-A = profile within an S/MIME structure (for some instances within the REM = workflow CAdES-BES is also required) - whether the above usage would present difficulties/problems in terms = of interoperability of systems (i.e. e-mail clients or BPM/ERP systems, = where the messages are expected to be utilised - e.g. a REM message = received is downloaded and then used as the input of a business process = within a core banking component) especially as regards the subsequent = verification process within these systems and among different REM = Service Providers in Turkey and in Europe (as Turkey has opted in to the = ETSI TS 102640). - whether, from a technical viewpoint, the implementation of an S/MIME = structure with the usage of a CAdES signature presents a problem with = the S/MIME RFC - whether the S/MIME RFC should be expected to natively accomodate CAdES = profiles in the near future=20 We would gladly provide more details on the ETSI 102640 implementation = in Turkey, if it is of essense to the above inquiries.=20 We will be much obliged, should you be able to provide insight. Thank you in advance and warm regards, Ayhan =C5=9EEHR=C4=B0N Man. Director Verion Technology Group Birlik Mah. 435. Cad. 403. Sok. No:3/3 =C3=87ankaya, Ankara - Turkey +90 312 496 3316 (office) +90 533 556 3333 (mobile) =20 NB-REM implementation in Turkey in a tiny nutshell: In the typical REM = implementation in Turkey, an original message is required to be signed = with the sender=E2=80=99s Qualified Electronic Signature, two out of the = currently three REMSPs provide tools for constructing and signing the = sender=E2=80=99s S/MIME structure on the client, receive it over https = (or over a web service for enterprise integration instances) to the = REMSP servers. The third REMSP constructs the MIME message on its own = server, hashes it an sends it for a CAdES signature to the = sender=E2=80=99s client. Evidence is produced by REMSPs during the mail = acceptance, delivery and retrieval milestones and is expected to be = stored in WORM storage or to be archived, XadES-A for evidence, CAdES-A = for all system logs.=20 =20 ------=_NextPart_000_0006_01CE87A1.95453BF0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Dear = Ayhan,

 =

Archive format = of CMS CAdES-A can be implemented with many versions of archive = time-stamps.

 =

Only archive = time-stamp version 3 (ATSv3) is fixed for S/MIME = usage.

The ATSv3 must = include the ats-hash-index attribute which shall be carried as an unsigned attribute of the signature of the archive-time-stamp-v3 Attribute (see clause = 6.4.3 ETSI TS 101 733 V2.2.1 (2013-04)).

 =

The = ats-hash-index unsigned attribute provides an unambiguous imprint of the essential = components of a CAdES signature for use in the archive time-stamp (see 6.4.3). = These essential components are elements of the following ASN.1 SET OF = structures: unsignedAttrs, SignedData.certificates, and SignedData.crls. =

 =

The redundant = CAdES attributes are not required to be included in CMS when ATSv3 is used e.g. now are = used CMS fields like the SignedData.crls component as defined in RFC 3852 [4] = which can include OCSP and/or CRL revocation information. =

Use of the = ats-hash-index attribute makes it possible to add additional certificate / revocation information / unsigned attribute within SignedData.certificates/ SignedData.crls/ unsigned attributes of the CAdES signature (for = instance counter signatures), after an archive time-stamp has been applied to a = signature. Its use also allows the inclusion of components required by parallel = signatures at a later time.

 =

Previous archive time-stamp versions before version 3 have some problems e.g. with adding = S/MIME unsigned attribute after archive time-stamp or problems with parallel = CMS signatures when one of parallel signatures contains archive = timestamp.

 =

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

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

 =

Previous = versions of CAdES specification have defined many redundant = attributes.

The usage of = redundant attributes was deprecated in the last = profile.

 =

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

http://www.etsi.org/deliver/etsi_ts/103100_103= 199/103173/02.02.01_60/ts_103173v020201p.pdf =C2=A0

 =

It means the use = of the CAdES-A profile within the S/MIME structure is possible without know = problems only when ATSv3 is included.

 =

More information = is from the page 15. It is about: ETSI ESI deprecates long-term = formats

http://= files.lockitin.webnode.sk/200000078-00104010a3/12th%20Edition%20of%20the%= 20Conference%20June%2004-06th%202012%20Poland.ppt

 =

Best = regards,

Peter = Rybar

National = Security Authority

Information = Security and Electronic Signature Department

Budatinska 30, = 850 07 Bratislava 57, Slovak Republic=

tel.: +421 2 = 6869 2163

mob.: +421 902 = 891 155

fax: +421 2 6869 = 1701

e-mail: peter.rybar@nbusr.sk

e-mail: peterryb@gmail.com

 =

 =

From: smime-bounces@ietf.org [mailto:smime-bounces@ietf.org] On Behalf Of Ayhan Sehrin
Sent: Saturday, July 20, = 2013 12:33 PM
To: smime@ietf.org
Subject: [smime] Inquiry = on the usage of CAdES in S/MIME structures
Importance: = High

 

Dear list = Members,

 <= /o:p>

As Verion Technology Group, a technology provider working = on Registered E-Mail (REM) solutions since 2009, we are currently in the = process of formulating a set of basic implementation principles and tools for = REM Management Domain (MD)=E2=80=99s operative in Turkey. We need to resort = to your experience and know-how on the subject of the S/MIME specification, and = I was kindly prompted by Mr. Blake Ramsdell to address your list for further = comments and insight.

The Registered E-Mail Regulatory Authority in Turkey has very recently = mandated the use of the CAdES-A profile within the S/MIME structure and as we are = a bit perplexed on the issue, we would like to inquire your comments = on:

- whether = it would be logical/feasible/meaningful to use the CAdES-A profile within an = S/MIME structure (for some instances within the REM workflow CAdES-BES is also required)
- whether the above usage would present difficulties/problems in terms = of interoperability of systems (i.e. e-mail clients or BPM/ERP systems, = where the messages are expected to be utilised - e.g. a REM message received is downloaded and then used as the input of a business process within a = core banking component) especially as regards the subsequent verification = process within these systems and among different REM Service Providers in Turkey = and in Europe (as Turkey has opted in to the ETSI TS 102640).
- whether, from a technical viewpoint, the implementation of an S/MIME structure with the usage of a CAdES signature presents a problem with = the S/MIME RFC

- whether = the S/MIME RFC should be expected to natively accomodate CAdES profiles in the near = future


We would gladly provide more details on the ETSI 102640 implementation = in Turkey, if it is of essense to the above inquiries.
We will be much obliged, should you be able to provide insight.

Thank you in advance and warm regards,


Ayhan =C5=9EEHR=C4=B0N
Man. Director
Verion Technology Group
Birlik Mah. 435. Cad. 403. Sok. No:3/3
=C3=87ankaya, Ankara - = Turkey

+90 312 496 = 3316 (office)
+90 533 556 = 3333 (mobile)

 <= /o:p>

NB-REM implementation in Turkey in a tiny nutshell: In the typical REM = implementation in Turkey, an original message is required to be signed with the = sender=E2=80=99s Qualified Electronic Signature, two out of the currently three REMSPs = provide tools for constructing and signing the sender=E2=80=99s S/MIME structure = on the client, receive it over https (or over a web service for enterprise integration instances) to the REMSP servers. The third REMSP constructs the MIME = message on its own server, hashes it an sends it for a CAdES signature to the = sender=E2=80=99s client. Evidence is produced by REMSPs during the mail acceptance, = delivery and retrieval milestones and is expected to be stored in WORM storage or to = be archived, XadES-A for evidence, CAdES-A for all system logs. =

 

------=_NextPart_000_0006_01CE87A1.95453BF0-- From ayhan.sehrin@verion.com.tr Tue Jul 23 06:22:18 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 C30C711E8106 for ; Tue, 23 Jul 2013 06:22:14 -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 iV6NPAk48ma0 for ; Tue, 23 Jul 2013 06:22:05 -0700 (PDT) Received: from serv01.siteground315.com (ns1.siteground315.com [184.154.160.6]) by ietfa.amsl.com (Postfix) with ESMTP id CDF5311E80DF for ; Tue, 23 Jul 2013 06:22:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=verion.com.tr; s=dkim; h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=h4vEeUA0EX2C4S3Yq7pM4v0Gn2+TIy6RF3HmtJnA/bg=; b=HDjLIWBTt2vdNVdJeECyMjxygT0vMZuS8yJ4HgyLmIM44/lC29dUPMr/V1oQUeyWiRsNqn9uzoCky5kHsfJOIPvqf+ZjGnYoGlLExx9zeQTFoUSC2kXJONUEV3gF8VuFWUWsSWy4CF3p1G9l2rdnWDrskBtOMQYRAJ7sCJN+zmY=; Received: from [95.9.177.86] (port=50825 helo=PC) by serv01.siteground315.com with esmtpa (Exim 4.80.1) (envelope-from ) id 1V1cXJ-00041I-85; Tue, 23 Jul 2013 08:21:54 -0500 From: "Ayhan Sehrin" To: "'Peter Rybar'" References: <06d201ce8534$8512d2c0$8f387840$@verion.com.tr> <201307231049.r6NAcnBI014087@mail.nbusr.sk> In-Reply-To: <201307231049.r6NAcnBI014087@mail.nbusr.sk> Date: Tue, 23 Jul 2013 16:21:53 +0300 Message-ID: <003201ce87a7$9a0b40c0$ce21c240$@verion.com.tr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0033_01CE87C0.BF5FA4B0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFfvcvPlyBu5Sj7acCC8IRYbUNYBppPsGRQ Content-Language: tr X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - serv01.siteground315.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - verion.com.tr X-Get-Message-Sender-Via: serv01.siteground315.com: none Cc: smime@ietf.org Subject: Re: [smime] Inquiry on the usage of CAdES in S/MIME structures 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, 23 Jul 2013 13:22:18 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0033_01CE87C0.BF5FA4B0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 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 =20 From: Peter Rybar [mailto:peter.rybar@nbusr.sk]=20 Sent: Tuesday, July 23, 2013 1:39 PM To: 'Ayhan Sehrin' Cc: smime@ietf.org Subject: RE: [smime] Inquiry on the usage of CAdES in S/MIME structures =20 Dear Ayhan, =20 Archive format of CMS CAdES-A can be implemented with many versions of = archive time-stamps. =20 Only archive time-stamp version 3 (ATSv3) is fixed for S/MIME usage. The ATSv3 must include the ats-hash-index attribute which shall be = carried as an unsigned attribute of the signature of the = archive-time-stamp-v3 Attribute (see clause 6.4.3 ETSI TS 101 733 V2.2.1 = (2013-04)).=20 =20 The ats-hash-index unsigned attribute provides an unambiguous imprint of = the essential components of a CAdES signature for use in the archive = time-stamp (see 6.4.3). These essential components are elements of the = following ASN.1 SET OF structures: unsignedAttrs, = SignedData.certificates, and SignedData.crls.=20 =20 The redundant CAdES attributes are not required to be included in CMS = when ATSv3 is used e.g. now are used CMS fields like the SignedData.crls = component as defined in RFC 3852 [4] which can include OCSP and/or CRL = revocation information.=20 Use of the ats-hash-index attribute makes it possible to add additional = certificate / revocation information / unsigned attribute within = SignedData.certificates/ SignedData.crls/ unsigned attributes of the = CAdES signature (for instance counter signatures), after an archive = time-stamp has been applied to a signature. Its use also allows the = inclusion of components required by parallel signatures at a later time. =20 Previous archive time-stamp versions before version 3 have some problems = e.g. with adding S/MIME unsigned attribute after archive time-stamp or = problems with parallel CMS signatures when one of parallel signatures = contains archive timestamp. =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 Previous versions of CAdES specification have defined many redundant = attributes. The usage of redundant attributes was deprecated in the last profile. =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 It means the use of the CAdES-A profile within the S/MIME structure is = possible without know problems only when ATSv3 is included. =20 More information is from the page 15. It is about: ETSI ESI deprecates = long-term formats http://files.lockitin.webnode.sk/200000078-00104010a3/12th%20Edition%20of= %20the%20Conference%20June%2004-06th%202012%20Poland.ppt=20 =20 Best regards, Peter Rybar National Security Authority Information Security and Electronic Signature Department Budatinska 30, 850 07 Bratislava 57, Slovak Republic tel.: +421 2 6869 2163 mob.: +421 902 891 155 fax: +421 2 6869 1701 e-mail: peter.rybar@nbusr.sk e-mail: peterryb@gmail.com =20 =20 _____ =20 From: smime-bounces@ietf.org [mailto:smime-bounces@ietf.org] On Behalf = Of Ayhan Sehrin Sent: Saturday, July 20, 2013 12:33 PM To: smime@ietf.org Subject: [smime] Inquiry on the usage of CAdES in S/MIME structures Importance: High =20 Dear list Members,=20 =20 As Verion Technology Group, a technology provider working on Registered = E-Mail (REM) solutions since 2009, we are currently in the process of = formulating a set of basic implementation principles and tools for REM = Management Domain (MD)=E2=80=99s operative in Turkey. We need to resort = to your experience and know-how on the subject of the S/MIME = specification, and I was kindly prompted by Mr. Blake Ramsdell to = address your list for further comments and insight. The Registered E-Mail Regulatory Authority in Turkey has very recently = mandated the use of the CAdES-A profile within the S/MIME structure and = as we are a bit perplexed on the issue, we would like to inquire your = comments on: - whether it would be logical/feasible/meaningful to use the CAdES-A = profile within an S/MIME structure (for some instances within the REM = workflow CAdES-BES is also required) - whether the above usage would present difficulties/problems in terms = of interoperability of systems (i.e. e-mail clients or BPM/ERP systems, = where the messages are expected to be utilised - e.g. a REM message = received is downloaded and then used as the input of a business process = within a core banking component) especially as regards the subsequent = verification process within these systems and among different REM = Service Providers in Turkey and in Europe (as Turkey has opted in to the = ETSI TS 102640). - whether, from a technical viewpoint, the implementation of an S/MIME = structure with the usage of a CAdES signature presents a problem with = the S/MIME RFC - whether the S/MIME RFC should be expected to natively accomodate CAdES = profiles in the near future=20 We would gladly provide more details on the ETSI 102640 implementation = in Turkey, if it is of essense to the above inquiries.=20 We will be much obliged, should you be able to provide insight. Thank you in advance and warm regards, Ayhan =C5=9EEHR=C4=B0N Man. Director Verion Technology Group Birlik Mah. 435. Cad. 403. Sok. No:3/3 =C3=87ankaya, Ankara - Turkey +90 312 496 3316 (office) +90 533 556 3333 (mobile) =20 NB-REM implementation in Turkey in a tiny nutshell: In the typical REM = implementation in Turkey, an original message is required to be signed = with the sender=E2=80=99s Qualified Electronic Signature, two out of the = currently three REMSPs provide tools for constructing and signing the = sender=E2=80=99s S/MIME structure on the client, receive it over https = (or over a web service for enterprise integration instances) to the = REMSP servers. The third REMSP constructs the MIME message on its own = server, hashes it an sends it for a CAdES signature to the = sender=E2=80=99s client. Evidence is produced by REMSPs during the mail = acceptance, delivery and retrieval milestones and is expected to be = stored in WORM storage or to be archived, XadES-A for evidence, CAdES-A = for all system logs.=20 =20 ------=_NextPart_000_0033_01CE87C0.BF5FA4B0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Dear Peter,

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

Kind regards,

 

Ayhan =C5=9Eehrin

 

 

From:= Peter = Rybar [mailto:peter.rybar@nbusr.sk]
Sent: Tuesday, July 23, = 2013 1:39 PM
To: 'Ayhan Sehrin'
Cc: = smime@ietf.org
Subject: RE: [smime] Inquiry on the usage of = CAdES in S/MIME structures

 

De= ar Ayhan,

 

Ar= chive format of CMS CAdES-A can be implemented with many versions of = archive time-stamps.

 

On= ly archive time-stamp version 3 (ATSv3) is fixed for S/MIME = usage.

Th= e ATSv3 must include the ats-hash-index attribute which shall be carried = as an unsigned attribute of the signature of the = archive-time-stamp-v3 Attribute (see clause 6.4.3 ETSI TS 101 733 V2.2.1 = (2013-04)).

 

Th= e ats-hash-index unsigned attribute provides an unambiguous imprint of = the essential components of a CAdES signature for use in the archive = time-stamp (see 6.4.3). These essential components are elements of the = following ASN.1 SET OF structures: unsignedAttrs, = SignedData.certificates, and SignedData.crls.

 

Th= e redundant CAdES attributes are not required to be included in CMS when = ATSv3 is used e.g. now are used CMS fields like the SignedData.crls = component as defined in RFC 3852 [4] which can include OCSP and/or CRL = revocation information.

Us= e of the ats-hash-index attribute makes it possible to add additional = certificate / revocation information / unsigned attribute within = SignedData.certificates/ SignedData.crls/ unsigned attributes of the = CAdES signature (for instance counter signatures), after an archive = time-stamp has been applied to a signature. Its use also allows the = inclusion of components required by parallel signatures at a later = time.

 

Pr= evious archive time-stamp versions before version 3 have some problems = e.g. with adding S/MIME unsigned attribute after archive time-stamp or = problems with parallel CMS signatures when one of parallel signatures = contains archive timestamp.

 

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

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

 

Pr= evious versions of CAdES specification have defined many redundant = attributes.

Th= e usage of redundant attributes was deprecated in the last = profile.

 

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

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

 

It= means the use of the CAdES-A profile within the S/MIME structure is = possible without know problems only when ATSv3 is = included.

 

Mo= re information is from the page 15. It is about: ETSI ESI deprecates = long-term formats

http://= files.lockitin.webnode.sk/200000078-00104010a3/12th%20Edition%20of%20the%= 20Conference%20June%2004-06th%202012%20Poland.ppt =

 

Be= st regards,

Pe= ter Rybar

Na= tional Security Authority

In= formation Security and Electronic Signature = Department

Bu= datinska 30, 850 07 Bratislava 57, Slovak = Republic

te= l.: +421 2 6869 2163

mo= b.: +421 902 891 155

fa= x: +421 2 6869 1701

e-= mail: peter.rybar@nbusr.sk<= /span>

e-= mail: peterryb@gmail.com

 

 

From:= smime-bounces@ietf.org [mailto:smime-bounces@ietf.org]= On Behalf Of Ayhan Sehrin
Sent: Saturday, July 20, = 2013 12:33 PM
To: smime@ietf.org
Subject: = [smime] Inquiry on the usage of CAdES in S/MIME = structures
Importance: High

 

Dear list Members,

 

As Verion Technology Group, a technology provider working on = Registered E-Mail (REM) solutions since 2009, we are currently in the = process of formulating a set of basic implementation principles and = tools for REM Management Domain (MD)=E2=80=99s operative in Turkey. We = need to resort to your experience and know-how on the subject of the = S/MIME specification, and I was kindly prompted by Mr. Blake Ramsdell to = address your list for further comments and insight.

The = Registered E-Mail Regulatory Authority in Turkey has very recently = mandated the use of the CAdES-A profile within the S/MIME structure and = as we are a bit perplexed on the issue, we would like to inquire your = comments on:

- whether it would be logical/feasible/meaningful to use the CAdES-A = profile within an S/MIME structure (for some instances within the REM = workflow CAdES-BES is also required)
- whether the above usage would = present difficulties/problems in terms of interoperability of systems = (i.e. e-mail clients or BPM/ERP systems, where the messages are expected = to be utilised - e.g. a REM message received is downloaded and then used = as the input of a business process within a core banking component) = especially as regards the subsequent verification process within these = systems and among different REM Service Providers in Turkey and in = Europe (as Turkey has opted in to the ETSI TS 102640).
- whether, = from a technical viewpoint, the implementation of an S/MIME structure = with the usage of a CAdES signature presents a problem with the S/MIME = RFC

- whether the S/MIME RFC should be expected to natively accomodate = CAdES profiles in the near future


We would gladly provide more details on the ETSI 102640 = implementation in Turkey, if it is of essense to the above inquiries. =
We will be much obliged, should you be able to provide = insight.

Thank you in advance and warm regards,


Ayhan = =C5=9EEHR=C4=B0N
Man. Director
Verion Technology Group
Birlik = Mah. 435. Cad. 403. Sok. No:3/3
=C3=87ankaya, Ankara - = Turkey

+90 312 496 = 3316 (office)
+90 533 556 = 3333 (mobile)

 

NB-REM implementation in Turkey in a tiny nutshell: In the typical = REM implementation in Turkey, an original message is required to be = signed with the sender=E2=80=99s Qualified Electronic Signature, two out = of the currently three REMSPs provide tools for constructing and signing = the sender=E2=80=99s S/MIME structure on the client, receive it over = https (or over a web service for enterprise integration instances) to = the REMSP servers. The third REMSP constructs the MIME message on its = own server, hashes it an sends it for a CAdES signature to the = sender=E2=80=99s client. Evidence is produced by REMSPs during the mail = acceptance, delivery and retrieval milestones and is expected to be = stored in WORM storage or to be archived, XadES-A for evidence, CAdES-A = for all system logs.

 

------=_NextPart_000_0033_01CE87C0.BF5FA4B0-- From kasamatsu.kohei@po.ntts.co.jp Mon Jul 29 23:11:00 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 C07CE21F9E9C for ; Mon, 29 Jul 2013 23:11:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.417 X-Spam-Level: ** X-Spam-Status: No, score=2.417 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_50=0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 LjNuFb6O0rhz for ; Mon, 29 Jul 2013 23:10:55 -0700 (PDT) Received: from mail12.ics.ntts.co.jp (mail12.ics.ntts.co.jp [210.232.35.65]) by ietfa.amsl.com (Postfix) with ESMTP id CBAB121F9E9F for ; Mon, 29 Jul 2013 23:10:49 -0700 (PDT) Received: from sadoku34.silk.ntts.co.jp (sadoku34 [10.7.18.34]) by mail12.ics.ntts.co.jp (8.14.4/8.14.4/NTTSOFT) with ESMTP id r6U6Amgk004209 for ; Tue, 30 Jul 2013 15:10:48 +0900 (JST) Received: (from root@localhost) by sadoku34.silk.ntts.co.jp (8.13.8/NTTSOFT) id r6U6Amft025575 for smime@ietf.org; Tue, 30 Jul 2013 15:10:48 +0900 (JST) Received: from ccmds32.silk.ntts.co.jp [10.107.0.32] by sadoku34.silk.ntts.co.jp with SMTP id RAA25574; Tue, 30 Jul 2013 15:10:48 +0900 Received: from mail147.silk.ntts.co.jp (ccmds32.silk.ntts.co.jp [127.0.0.1]) by ccmds32.silk.ntts.co.jp (8.14.3/8.14.3) with ESMTP id r6U6AmhU003728; Tue, 30 Jul 2013 15:10:48 +0900 Received: from mail147.silk.ntts.co.jp (localhost.localdomain [127.0.0.1]) by mail147.silk.ntts.co.jp (8.14.5/8.14.5/NTTSOFT) with ESMTP id r6U6Akks012991; Tue, 30 Jul 2013 15:10:46 +0900 Received: from ccmds32 (mail145.silk.ntts.co.jp [10.107.0.145]) by mail147.silk.ntts.co.jp (8.14.5/8.14.5/NTTSOFT) with SMTP id r6U6AkVr012988; Tue, 30 Jul 2013 15:10:46 +0900 Message-ID: <51F758D9.1080302@po.ntts.co.jp> Date: Tue, 30 Jul 2013 15:10:33 +0900 From: Kohei Kasamatsu User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: smime@ietf.org Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-CC-Mail-RelayStamp: CC-Mail-V4.3-Client X-CC-Mail-RelayStamp: CC-Mail-V4.3-Server Subject: [smime] A bit better operational practice? 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, 30 Jul 2013 06:11:00 -0000 Hi, SMIME list There are many of MUA implementations for S/MIME and some banks or corporations are using digital signature for their messages. But in such cases, there are several points would hopefully be care in technical aspects of S/MIME. Displaying assurance of organization of signer, keys and certificates management criteria in MUA and CRL delivery into MUA are crucial issues to enhace usage or deployment of acutual use of S/MIME. I would think about drafting a document as follows: ----- MUA and for qualified signatures: - certificate selection in MUA - for unified display (like green bar in browser) of showing messages in MUA with valid/non-valid signatures - operational pracice for digital signatures (e.g. key length, validity, key store) Certificates for S/MIME: - operational pracice for digital signatures (e.g. key length, validity, key store, revocation control) - certificate policy or singing policy for signer(S/MIME) e.g.) Bank, corporation, goverment and/or for qualified signature etc.(other items in my mind) ----- Are they impossible to be toss as a draft? If you have had considered such point of operational issues, I would hope to share and get your reply. (or talk to me either, in Berlin) -- Kohei Kasamatsu NTT Software Corporation TEL: +81 45 212 7908 FAX: +81 45 212 9800 E-mail: kasamatsu.kohei@po.ntts.co.jp From anders.rundgren@telia.com Mon Jul 29 23:27:47 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 5F57F21E804D for ; Mon, 29 Jul 2013 23:27:47 -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 LEvHOEI262x7 for ; Mon, 29 Jul 2013 23:27:42 -0700 (PDT) Received: from smtp-out21.han.skanova.net (smtp-out21.han.skanova.net [195.67.226.208]) by ietfa.amsl.com (Postfix) with ESMTP id D163321F9BF7 for ; Mon, 29 Jul 2013 23:27:41 -0700 (PDT) Received: from [192.168.0.200] (213.64.1.89) by smtp-out21.han.skanova.net (8.5.133) (authenticated as u36408181) id 51AC7836011A617D; Tue, 30 Jul 2013 08:27:31 +0200 Message-ID: <51F75CCF.6030102@telia.com> Date: Tue, 30 Jul 2013 08:27:27 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Kohei Kasamatsu References: <51F758D9.1080302@po.ntts.co.jp> In-Reply-To: <51F758D9.1080302@po.ntts.co.jp> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: smime@ietf.org Subject: Re: [smime] A bit better operational practice? 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, 30 Jul 2013 06:27:47 -0000 On 2013-07-30 08:10, Kohei Kasamatsu wrote: > Hi, SMIME list > > > There are many of MUA implementations for S/MIME and some banks or > corporations are using digital signature for their messages. > But in such cases, there are several points would hopefully be care in > technical aspects of S/MIME. > > Displaying assurance of organization of signer, keys and certificates > management criteria in MUA and CRL delivery into MUA are crucial > issues to enhace usage or deployment of acutual use of S/MIME. > > I would think about drafting a document as follows: > ----- > MUA and for qualified signatures: > - certificate selection in MUA > - for unified display (like green bar in browser) of showing > messages in MUA with valid/non-valid signatures > - operational pracice for digital signatures > (e.g. key length, validity, key store) > > Certificates for S/MIME: > - operational pracice for digital signatures > (e.g. key length, validity, key store, revocation control) > - certificate policy or singing policy for signer(S/MIME) > e.g.) Bank, corporation, goverment and/or for qualified signature > > etc.(other items in my mind) > ----- > > Are they impossible to be toss as a draft? > > If you have had considered such point of operational issues, > I would hope to share and get your reply. > (or talk to me either, in Berlin) Personally I consider S/MIME a useless standard, there's to my knowledge no plans making it better either. The parameters you mention has no meaning except to crypto-nerds. I would recommend banks and governments turn to web-based solutions because they provide an interactive component which among many things can pre-select the proper certificate. Here is something I'm working with to make the web an alternative to S/MIME: http://webpki.org/papers/PKI/pki-webcrypto.pdf Anders > From tmiller@mitre.org Tue Jul 30 05:31:53 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 1958C21F9E2B for ; Tue, 30 Jul 2013 05:31:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 kvPMYBOBMl6r for ; Tue, 30 Jul 2013 05:31:47 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 6C2BF21F90DC for ; Tue, 30 Jul 2013 05:31:47 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 982731F0A9D; Tue, 30 Jul 2013 08:31:46 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 7C15A1F0A76; Tue, 30 Jul 2013 08:31:46 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.23]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.02.0342.003; Tue, 30 Jul 2013 08:31:45 -0400 From: "Miller, Timothy J." To: Kohei Kasamatsu , "smime@ietf.org" Thread-Topic: [smime] A bit better operational practice? Thread-Index: AQHOjOuThHh3MKMS3kuPqRb+FkKe7Jl9JgZ0gAABovg= Date: Tue, 30 Jul 2013 12:31:44 +0000 Message-ID: <195DB2510AAA004391F58E28FCE2120026C78B6B@IMCMBX01.MITRE.ORG> References: <51F758D9.1080302@po.ntts.co.jp> In-Reply-To: <51F758D9.1080302@po.ntts.co.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mimectl: Produced By Microsoft Exchange V14.2.247.1 x-originating-ip: [129.83.31.52] Content-Type: multipart/alternative; boundary="_000_195DB2510AAA004391F58E28FCE2120026C78B6BIMCMBX01MITREOR_" MIME-Version: 1.0 Subject: Re: [smime] A bit better operational practice? 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, 30 Jul 2013 12:31:53 -0000 --_000_195DB2510AAA004391F58E28FCE2120026C78B6BIMCMBX01MITREOR_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Are you proposing a BCP or a new RFC or bis? Your list it sounds like a BC= P to me. -- T ________________________________ From: smime-bounces@ietf.org [smime-bounces@ietf.org] on behalf of Kohei Ka= samatsu [kasamatsu.kohei@po.ntts.co.jp] Sent: Tuesday, July 30, 2013 01:10 To: smime@ietf.org Subject: [smime] A bit better operational practice? Hi, SMIME list There are many of MUA implementations for S/MIME and some banks or corporations are using digital signature for their messages. But in such cases, there are several points would hopefully be care in technical aspects of S/MIME. Displaying assurance of organization of signer, keys and certificates management criteria in MUA and CRL delivery into MUA are crucial issues to enhace usage or deployment of acutual use of S/MIME. I would think about drafting a document as follows: ----- MUA and for qualified signatures: - certificate selection in MUA - for unified display (like green bar in browser) of showing messages in MUA with valid/non-valid signatures - operational pracice for digital signatures (e.g. key length, validity, key store) Certificates for S/MIME: - operational pracice for digital signatures (e.g. key length, validity, key store, revocation control) - certificate policy or singing policy for signer(S/MIME) e.g.) Bank, corporation, goverment and/or for qualified signature etc.(other items in my mind) ----- Are they impossible to be toss as a draft? If you have had considered such point of operational issues, I would hope to share and get your reply. (or talk to me either, in Berlin) -- Kohei Kasamatsu NTT Software Corporation TEL: +81 45 212 7908 FAX: +81 45 212 9800 E-mail: kasamatsu.kohei@po.ntts.co.jp _______________________________________________ smime mailing list smime@ietf.org https://www.ietf.org/mailman/listinfo/smime --_000_195DB2510AAA004391F58E28FCE2120026C78B6BIMCMBX01MITREOR_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable

Are you proposing a BCP or a new RFC or bis?  Your list it sounds l= ike a BCP to me.

 

-- T

 

From: smime-bounces@ietf.org [smime-bounces@ietf.org] on behalf = of Kohei Kasamatsu [kasamatsu.kohei@po.ntts.co.jp]
Sent: Tuesday, July 30, 2013 01:10
To: smime@ietf.org
Subject: [smime] A bit better operational practice?

Hi, SMIME list


There are many of MUA implementations for S/MIME and some banks or
corporations are using digital signature for their messages.
But in such cases, there are several points would hopefully be care in
technical aspects of S/MIME.

Displaying assurance of organization of signer, keys and certificates
management criteria in MUA and CRL delivery into MUA are crucial
issues to enhace usage or deployment of acutual use of S/MIME.

I would think about drafting a document as follows:
-----
 MUA and for qualified signatures:
  - certificate selection in MUA
  - for unified display (like green bar in browser) of showing
    messages in MUA with valid/non-valid signatures
  - operational pracice for digital signatures
    (e.g. key length, validity, key store)

 Certificates for S/MIME:
  - operational pracice for digital signatures
    (e.g. key length, validity, key store, revocation contro= l)
  - certificate policy or singing policy for signer(S/MIME)
   e.g.) Bank, corporation, goverment and/or for qualified signat= ure

 etc.(other items in my mind)
-----

Are they impossible to be toss as a draft?

If you have had considered such point of operational issues,
I would hope to share and get your reply.
(or talk to me either, in Berlin)
--
Kohei Kasamatsu

NTT Software Corporation
TEL: +81 45 212 7908 FAX: +81 45 212 9800
E-mail: kasamatsu.kohei@po.ntts.co.jp

_______________________________________________
smime mailing list
smime@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/smime
--_000_195DB2510AAA004391F58E28FCE2120026C78B6BIMCMBX01MITREOR_-- From kasamatsu.kohei@po.ntts.co.jp Wed Jul 31 07:26:48 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 78D9821F8BB7 for ; Wed, 31 Jul 2013 07:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.163 X-Spam-Level: * X-Spam-Status: No, score=1.163 tagged_above=-999 required=5 tests=[AWL=1.253, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 DnOkgvSw2Bp3 for ; Wed, 31 Jul 2013 07:26:42 -0700 (PDT) Received: from mail12.ics.ntts.co.jp (mail12.ics.ntts.co.jp [210.232.35.65]) by ietfa.amsl.com (Postfix) with ESMTP id E6AEA21F86B1 for ; Wed, 31 Jul 2013 07:26:15 -0700 (PDT) Received: from sadoku34.silk.ntts.co.jp (sadoku34 [10.7.18.34]) by mail12.ics.ntts.co.jp (8.14.4/8.14.4/NTTSOFT) with ESMTP id r6VEQDIn001954; Wed, 31 Jul 2013 23:26:13 +0900 (JST) Received: (from root@localhost) by sadoku34.silk.ntts.co.jp (8.13.8/NTTSOFT) id r6VEQDac015732; Wed, 31 Jul 2013 23:26:13 +0900 (JST) Received: from ccmds32.silk.ntts.co.jp [10.107.0.32] by sadoku34.silk.ntts.co.jp with SMTP id ZAA15731; Wed, 31 Jul 2013 23:26:13 +0900 Received: from mail147.silk.ntts.co.jp (ccmds32.silk.ntts.co.jp [127.0.0.1]) by ccmds32.silk.ntts.co.jp (8.14.3/8.14.3) with ESMTP id r6VEQDG4010304; Wed, 31 Jul 2013 23:26:13 +0900 Received: from mail147.silk.ntts.co.jp (localhost.localdomain [127.0.0.1]) by mail147.silk.ntts.co.jp (8.14.5/8.14.5/NTTSOFT) with ESMTP id r6VEQ9ht006512; Wed, 31 Jul 2013 23:26:09 +0900 Received: from ccmds32 (mail145.silk.ntts.co.jp [10.107.0.145]) by mail147.silk.ntts.co.jp (8.14.5/8.14.5/NTTSOFT) with SMTP id r6VEQ9Oe006509; Wed, 31 Jul 2013 23:26:09 +0900 Message-ID: <51F91E59.60104@po.ntts.co.jp> Date: Wed, 31 Jul 2013 23:25:29 +0900 From: Kohei Kasamatsu User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Anders Rundgren References: <51F758D9.1080302@po.ntts.co.jp> <51F75CCF.6030102@telia.com> In-Reply-To: <51F75CCF.6030102@telia.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-CC-Mail-RelayStamp: CC-Mail-V4.3-Client X-CC-Mail-RelayStamp: CC-Mail-V4.3-Server Cc: smime@ietf.org Subject: Re: [smime] A bit better operational practice? 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: Wed, 31 Jul 2013 14:26:48 -0000 Hi Anders. Thank you for your comments. > Personally I consider S/MIME a useless standard, there's to my knowledge no > plans making it better either. S/MIME is already used by Some banks and corporations and is actually useful for guaranteeing integlity of their messages. I would like to contribute to parties who are using or providing S/MIME. > The parameters you mention has no meaning except to crypto-nerds. Thank you for the precious opinion. I also think that too detailed information on parameters of cryptgraphic primitives does not have no meaning. However, signature generated by compromised key cannot guarantee integrity of message. I think that it is valuable to gather and organize minimum required information about it. What do you think about it? > Here is something I'm working with to make the web an alternative to S/MIME: > http://webpki.org/papers/PKI/pki-webcrypto.pdf Thank you for interesting information. Best regards, Kohei (2013/07/30 15:27), Anders Rundgren wrote: > On 2013-07-30 08:10, Kohei Kasamatsu wrote: >> Hi, SMIME list >> >> >> There are many of MUA implementations for S/MIME and some banks or >> corporations are using digital signature for their messages. >> But in such cases, there are several points would hopefully be care in >> technical aspects of S/MIME. >> >> Displaying assurance of organization of signer, keys and certificates >> management criteria in MUA and CRL delivery into MUA are crucial >> issues to enhace usage or deployment of acutual use of S/MIME. >> >> I would think about drafting a document as follows: >> ----- >> MUA and for qualified signatures: >> - certificate selection in MUA >> - for unified display (like green bar in browser) of showing >> messages in MUA with valid/non-valid signatures >> - operational pracice for digital signatures >> (e.g. key length, validity, key store) >> >> Certificates for S/MIME: >> - operational pracice for digital signatures >> (e.g. key length, validity, key store, revocation control) >> - certificate policy or singing policy for signer(S/MIME) >> e.g.) Bank, corporation, goverment and/or for qualified signature >> >> etc.(other items in my mind) >> ----- >> >> Are they impossible to be toss as a draft? >> >> If you have had considered such point of operational issues, >> I would hope to share and get your reply. >> (or talk to me either, in Berlin) > > Personally I consider S/MIME a useless standard, there's to my knowledge no > plans making it better either. > > The parameters you mention has no meaning except to crypto-nerds. > > I would recommend banks and governments turn to web-based solutions > because they provide an interactive component which among many > things can pre-select the proper certificate. > > Here is something I'm working with to make the web an alternative to S/MIME: > http://webpki.org/papers/PKI/pki-webcrypto.pdf > > Anders > > > >> > > _______________________________________________ > smime mailing list > smime@ietf.org > https://www.ietf.org/mailman/listinfo/smime > From kasamatsu.kohei@po.ntts.co.jp Wed Jul 31 07:32:49 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 77A7421F9C76 for ; Wed, 31 Jul 2013 07:32:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.746 X-Spam-Level: X-Spam-Status: No, score=0.746 tagged_above=-999 required=5 tests=[AWL=0.836, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 EnD9RbQBAnul for ; Wed, 31 Jul 2013 07:32:43 -0700 (PDT) Received: from mail12.ics.ntts.co.jp (mail12.ics.ntts.co.jp [210.232.35.65]) by ietfa.amsl.com (Postfix) with ESMTP id 45BB421F8495 for ; Wed, 31 Jul 2013 07:31:55 -0700 (PDT) Received: from sadoku34.silk.ntts.co.jp (sadoku34 [10.7.18.34]) by mail12.ics.ntts.co.jp (8.14.4/8.14.4/NTTSOFT) with ESMTP id r6VEVqpm018055; Wed, 31 Jul 2013 23:31:52 +0900 (JST) Received: (from root@localhost) by sadoku34.silk.ntts.co.jp (8.13.8/NTTSOFT) id r6VEVqVL015941; Wed, 31 Jul 2013 23:31:52 +0900 (JST) Received: from ccmds32.silk.ntts.co.jp [10.107.0.32] by sadoku34.silk.ntts.co.jp with SMTP id ZAA15940; Wed, 31 Jul 2013 23:31:52 +0900 Received: from mail147.silk.ntts.co.jp (ccmds32.silk.ntts.co.jp [127.0.0.1]) by ccmds32.silk.ntts.co.jp (8.14.3/8.14.3) with ESMTP id r6VEVqK9011203; Wed, 31 Jul 2013 23:31:52 +0900 Received: from mail147.silk.ntts.co.jp (localhost.localdomain [127.0.0.1]) by mail147.silk.ntts.co.jp (8.14.5/8.14.5/NTTSOFT) with ESMTP id r6VEVmgU006885; Wed, 31 Jul 2013 23:31:48 +0900 Received: from ccmds32 (mail145.silk.ntts.co.jp [10.107.0.145]) by mail147.silk.ntts.co.jp (8.14.5/8.14.5/NTTSOFT) with SMTP id r6VEVmG7006882; Wed, 31 Jul 2013 23:31:48 +0900 Message-ID: <51F91FC5.8090409@po.ntts.co.jp> Date: Wed, 31 Jul 2013 23:31:33 +0900 From: Kohei Kasamatsu User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Miller, Timothy J." References: <51F758D9.1080302@po.ntts.co.jp> <195DB2510AAA004391F58E28FCE2120026C78B6B@IMCMBX01.MITRE.ORG> In-Reply-To: <195DB2510AAA004391F58E28FCE2120026C78B6B@IMCMBX01.MITRE.ORG> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-CC-Mail-RelayStamp: CC-Mail-V4.3-Client X-CC-Mail-RelayStamp: CC-Mail-V4.3-Server Cc: "smime@ietf.org" Subject: Re: [smime] A bit better operational practice? 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: Wed, 31 Jul 2013 14:32:49 -0000 Hi Miller, Thank you for your email. I plan to propose a BCP or an informational RFC. (If possible, proposing a BCP is best as me.) Best regards, Kohei (2013/07/30 21:31), Miller, Timothy J. wrote: > Are you proposing a BCP or a new RFC or bis? Your list it sounds like a BCP to me. > > > > -- T > > > > ________________________________ > From: smime-bounces@ietf.org [smime-bounces@ietf.org] on behalf of Kohei Kasamatsu [kasamatsu.kohei@po.ntts.co.jp] > Sent: Tuesday, July 30, 2013 01:10 > To: smime@ietf.org > Subject: [smime] A bit better operational practice? > > Hi, SMIME list > > > There are many of MUA implementations for S/MIME and some banks or > corporations are using digital signature for their messages. > But in such cases, there are several points would hopefully be care in > technical aspects of S/MIME. > > Displaying assurance of organization of signer, keys and certificates > management criteria in MUA and CRL delivery into MUA are crucial > issues to enhace usage or deployment of acutual use of S/MIME. > > I would think about drafting a document as follows: > ----- > MUA and for qualified signatures: > - certificate selection in MUA > - for unified display (like green bar in browser) of showing > messages in MUA with valid/non-valid signatures > - operational pracice for digital signatures > (e.g. key length, validity, key store) > > Certificates for S/MIME: > - operational pracice for digital signatures > (e.g. key length, validity, key store, revocation control) > - certificate policy or singing policy for signer(S/MIME) > e.g.) Bank, corporation, goverment and/or for qualified signature > > etc.(other items in my mind) > ----- > > Are they impossible to be toss as a draft? > > If you have had considered such point of operational issues, > I would hope to share and get your reply. > (or talk to me either, in Berlin) > -- > Kohei Kasamatsu > > NTT Software Corporation > TEL: +81 45 212 7908 FAX: +81 45 212 9800 > E-mail: kasamatsu.kohei@po.ntts.co.jp > > _______________________________________________ > smime mailing list > smime@ietf.org > https://www.ietf.org/mailman/listinfo/smime >