From owner-ietf-smime@mail.imc.org Tue Jul 1 10:30:33 2008 Return-Path: X-Original-To: ietfarch-smime-archive@core3.amsl.com Delivered-To: ietfarch-smime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5E613A6962 for ; Tue, 1 Jul 2008 10:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.307 X-Spam-Level: X-Spam-Status: No, score=-102.307 tagged_above=-999 required=5 tests=[AWL=0.292, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5-N1uWFhdgTn for ; Tue, 1 Jul 2008 10:30:32 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 3DA5C3A6918 for ; Tue, 1 Jul 2008 10:30:31 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m61HFEsG088060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Jul 2008 10:15:14 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m61HFEAF088058; Tue, 1 Jul 2008 10:15:14 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m61HFCmR088040 for ; Tue, 1 Jul 2008 10:15:13 -0700 (MST) (envelope-from root@core3.amsl.com) Received: by core3.amsl.com (Postfix, from userid 0) id 66C9E3A6B99; Tue, 1 Jul 2008 10:15:00 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ietf-smime@imc.org Subject: I-D ACTION:draft-ietf-smime-3851bis-04.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080701171501.66C9E3A6B99@core3.amsl.com> Date: Tue, 1 Jul 2008 10:15:01 -0700 (PDT) Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification Author(s) : B. Ramsdell, S. Turner Filename : draft-ietf-smime-3851bis-04.txt Pages : 46 Date : 2008-7-1 This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 3.2. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 3851. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-3851bis-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-smime-3851bis-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-7-1100110.I-D@ietf.org> --NextPart-- From owner-ietf-smime@mail.imc.org Tue Jul 1 10:38:01 2008 Return-Path: X-Original-To: ietfarch-smime-archive@core3.amsl.com Delivered-To: ietfarch-smime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFC673A6BA1 for ; Tue, 1 Jul 2008 10:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.309 X-Spam-Level: X-Spam-Status: No, score=-102.309 tagged_above=-999 required=5 tests=[AWL=0.290, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fCUhk-Qt8og3 for ; Tue, 1 Jul 2008 10:38:01 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 797F53A6BA8 for ; Tue, 1 Jul 2008 10:38:00 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m61HFGn6088073 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Jul 2008 10:15:16 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m61HFGsc088071; Tue, 1 Jul 2008 10:15:16 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m61HFDgk088041 for ; Tue, 1 Jul 2008 10:15:13 -0700 (MST) (envelope-from root@core3.amsl.com) Received: by core3.amsl.com (Postfix, from userid 0) id 6A9693A6BA1; Tue, 1 Jul 2008 10:15:00 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ietf-smime@imc.org Subject: I-D ACTION:draft-ietf-smime-3278bis-01.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080701171501.6A9693A6BA1@core3.amsl.com> Date: Tue, 1 Jul 2008 10:15:01 -0700 (PDT) Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS) Author(s) : S. Turner, D. Brown Filename : draft-ietf-smime-3278bis-01.txt Pages : 50 Date : 2008-7-1 This document describes how to use Elliptic Curve Cryptography (ECC) public-key algorithms in the Cryptographic Message Syntax (CMS). The ECC algorithms support the creation of digital signatures and the exchange of keys to encrypt or authenticate content. The definition of the algorithm processing is based on the ANSI X9.62 standard, developed by the ANSI X9F1 working group, the IEEE 1363 standard, and the SEC 1 standard. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-3278bis-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-smime-3278bis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-7-1101220.I-D@ietf.org> --NextPart-- From owner-ietf-smime@mail.imc.org Wed Jul 2 13:59:43 2008 Return-Path: X-Original-To: ietfarch-smime-archive@core3.amsl.com Delivered-To: ietfarch-smime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20CDE3A6A32 for ; Wed, 2 Jul 2008 13:59:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ji7rOGyMnJjk for ; Wed, 2 Jul 2008 13:59:37 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 0C91F3A694F for ; Wed, 2 Jul 2008 13:59:36 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m62KcIVs048098 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Jul 2008 13:38:18 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m62KcItY048097; Wed, 2 Jul 2008 13:38:18 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp104.biz.mail.re2.yahoo.com (smtp104.biz.mail.re2.yahoo.com [206.190.52.173]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m62KcHKp048090 for ; Wed, 2 Jul 2008 13:38:17 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 5469 invoked from network); 2 Jul 2008 20:38:16 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@71.191.0.199 with login) by smtp104.biz.mail.re2.yahoo.com with SMTP; 2 Jul 2008 20:38:15 -0000 X-YMail-OSG: l32ClMIVM1nj9ZE.42afA30ZnpxELIPIAWIoL7xz0VKO.RqKDKlPWt3VrwwziVIo1gnAIClN6IFRDCBu0iCbxfGXz0xWaK6hJalgdph35vn6PLR6fJyGNSxlVuQN3Ocd6fkOuJ9ZJUU_lkYladTNEifx X-Yahoo-Newman-Property: ymail-3 From: "Turner, Sean P." To: Subject: FW: I-D ACTION:draft-gennai-smime-cnipa-pec-00.txt Date: Wed, 2 Jul 2008 16:38:05 -0400 Organization: IECA, Inc. Message-ID: <373A0D028EBE4F25A40803CA88D88D8E@Wylie> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0000_01C8DC62.01556AE0" X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcjbAOiqtudPQIjWSrCr8UaW88UJ+gBgawnQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C8DC62.01556AE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I'd like to draw attention to this ID. Alba and Francesco described the PEC (Posta Elettronica Certificata) at IETF 71 (https://www3.ietf.org/proceedings/08mar/slides/smime-4.pdf) and this is the ID that provides a much more detailed technical description of PEC. Many at the meeting indicated they were willing to review - so please do and provide comments to the authors. spt -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Monday, June 30, 2008 6:30 PM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-gennai-smime-cnipa-pec-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Certified Electronic Mail Author(s) : F. Gennai, A. Shahin, C. Petrucci, A. Vinciarelli Filename : draft-gennai-smime-cnipa-pec-00.txt Pages : 62 Date : 2008-6-30 Since 1997, the Italian Laws have recognized electronic delivery systems as legally usable. After 2 years of technical tests, in 2005 the characteristics of an official electronic delivery service, named certified electronic mail (in Italian "Posta Elettronica Certificata") were defined, giving the system legal value. Design of the entire system was carried out by the National Center for Informatics in the Public Administration of Italy (CNIPA), followed by efforts for the implementation and testing of the service. The CNIPA has given the Italian National Research Council (CNR), and in particular The Institute of Information Science and Technologies at the CNR (ISTI), the task to run tests on providers of the service to guarantee the correct implementation and interoperability.This document describes the certified email system adopted in Italy. It represents the system as it is at the moment of writing, following the technical regulations that were written based upon the Italian Law DPR. November 2, 2005. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-gennai-smime-cnipa-pec-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------=_NextPart_000_0000_01C8DC62.01556AE0 Content-Type: Message/External-body; name="draft-gennai-smime-cnipa-pec-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-gennai-smime-cnipa-pec-00.txt" Content-Type: text/plain Content-ID: <2008-6-30151947.I-D@ietf.org> ------=_NextPart_000_0000_01C8DC62.01556AE0 Content-Type: text/plain; name="ATT00115.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT00115.txt" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ------=_NextPart_000_0000_01C8DC62.01556AE0-- From owner-ietf-smime@mail.imc.org Thu Jul 3 08:32:11 2008 Return-Path: X-Original-To: ietfarch-smime-archive@core3.amsl.com Delivered-To: ietfarch-smime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 803773A6809 for ; Thu, 3 Jul 2008 08:32:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.808 X-Spam-Level: *** X-Spam-Status: No, score=3.808 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kaenCOy5wxvr for ; Thu, 3 Jul 2008 08:32:01 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 7670B3A6A90 for ; Thu, 3 Jul 2008 08:31:11 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m63F7GUf031842 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Jul 2008 08:07:16 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m63F7GqL031841; Thu, 3 Jul 2008 08:07:16 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from ascertia.com (server5852.dedicated.webfusion.co.uk [81.21.74.134]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m63F6qMi031818 for ; Thu, 3 Jul 2008 08:06:53 -0700 (MST) (envelope-from yasir.khan@ascertia.com) Message-Id: <200807031506.m63F6qMi031818@balder-227.proper.com> Received: from ascertiajtl1 ([203.128.26.18]) by ds5852.dedicated.turbodns.co.uk with MailEnable ESMTP; Thu, 03 Jul 2008 15:08:31 +0100 From: "Yasir Khan" To: "'Pavel V. Smirnov'" , Subject: RE: Using Signature Policy in RFC-5126 Date: Thu, 3 Jul 2008 21:07:15 +0500 Organization: Ascertia Limited MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcjWsEVkUJ9OGEWeQRKpgqvSmd/z7AAAX7AgACx4USAAAKjZYAFv/YPA Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_039F_01C8DD50.C5132EB0" In-Reply-To: <002c01c8d763$2c6d3db0$8547b910$@ru> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_039F_01C8DD50.C5132EB0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_03A0_01C8DD50.C5132EB0" ------=_NextPart_001_03A0_01C8DD50.C5132EB0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable RFC 5126 explains how to create archived time stamp i.e. =20 =20 ArchiveTimeStampToken ::=3D TimeStampToken =20 The value of the messageImprint field within TimeStampToken shall be a hash of the concatenation of: =20 - the encapContentInfo element of the SignedData sequence; =20 - any external content being protected by the signature, if the eContent element of the encapContentInfo is omitted; =20 - the Certificates and crls elements of the SignedData sequence, when present, and; =20 - all data elements in the SignerInfo sequence including all signed and unsigned attributes. =20 =20 The ArchiveTimeStamp will be added as an unsigned attribute in the SignerInfo sequence. =20 According to the RFC, it is clear that message imprint will be the hash = of above concatenated values but it is not explained how to concatenate = these values? Please clarify this point. Some hint for implementing this would = be highly appreciated. Thanks! =20 -------------------------------------------------------------------------= --- ------ YASIR KHAN Development Manager =20 Ascertia Limited www.ascertia.com =20 www.globaltrustfinder.com =20 -------------------------------------------------------------------------= --- ------ Delivering Trust for e-business Documents & Workflows -------------------------------------------------------------------------= --- ------ NOTICE: This message is intended for the recipient(s) only. This communication may contain privileged or other confidential information. If you are not the intended recipient, or = believe that you have received this communication in error, please do not print, copy, retransmit, disseminate, or otherwise = use the information. Please notify the sender that you have received this email in error, and delete the copy you received =20 _____ =20 From: owner-ietf-smime@mail.imc.org = [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Pavel V. Smirnov Sent: Thursday, June 26, 2008 1:04 PM To: 'Yasir Khan'; ietf-smime@imc.org Subject: RE: Using Signature Policy in RFC-5126 =20 Yes, I mean "digital signature policy" as a "policy document" present at SPUri. But I use SPUri only for example, you may specify a SigPolicyId = and omit sigPolicyQualifiers at all. In this case you have to rely on some = other means to convey a correspondence between SigPolicyIds and "policy documents". =20 In case of SPuri you have to retrieve a "policy document" by its URI and hash it. =20 Note that if your infrastructure provides a trusted source of "policy documents", and there will never be two different (versions of) "policy documents" identified by the same OID, you don't have to hash them at = all. Just use zero policy hash value. =20 Pavel Smirnov Crypto-Pro Tel./Fax: +7 495 780-4820 WWW: http://www.CryptoPro.ru e-mail: spv@CryptoPro.ru =20 From: owner-ietf-smime@mail.imc.org = [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Yasir Khan Sent: Thursday, June 26, 2008 12:19 PM To: =F3=CD=C9=D2=CE=CF=D7 =F0=C1=D7=C5=CC = =F7=CC=C1=C4=C9=CD=C9=D2=CF=D7=C9=DE; ietf-smime@imc.org Subject: RE: Using Signature Policy in RFC-5126 =20 You wrote: "You have to hash a digital signature policy represented as a sequence of bytes in some format and place the computed value in SigPolicyHash." =20 To which item you are naming as "digital signature policy". You mean = policy document present at SPUri? If Yes then it makes some sense. But if only SPUserNotice is present or nothing is present as sigPolicyQualifiers as = it is an OPTIONAL element: =20 sigPolicyQualifiers SEQUENCE SIZE (1..MAX) OF SigPolicyQualifierInfo OPTIONAL =20 then on which item the hash would be computed? =20 Regards, Yasir Khan =20 =20 _____ =20 From: Pavel V. Smirnov [mailto:spv@cryptopro.ru]=20 Sent: Wednesday, June 25, 2008 4:07 PM To: 'Yasir Khan'; ietf-smime@imc.org Subject: RE: Using Signature Policy in RFC-5126 =20 Hello Yasir, =20 There is no need to protect by SigPolicyHash other fields of SignaturePolicyId structure because it is placed in a signed attribute. = All signed attributes are protected by the signature itself. =20 In most cases the policy would be an external document not included in = your signed message, and you have to unambiguously indicate specific policy = with respect to which your document should be treated. E.g., you may only = have an URI pointing to the policy as a SigPolicyQualifier. =20 You have to hash a digital signature policy represented as a sequence of bytes in some format and place the computed value in SigPolicyHash. =20 Pavel Smirnov Crypto-Pro Tel./Fax: +7 495 780-4820 WWW: http://www.CryptoPro.ru e-mail: spv@CryptoPro.ru =20 From: owner-ietf-smime@mail.imc.org = [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Yasir Khan Sent: Wednesday, June 25, 2008 2:43 PM To: ietf-smime@imc.org Subject: Using Signature Policy in RFC-5126 =20 We have a question related to using the signature policy in the CAdES signatures (EPES) defined in RFC-5126. Here is the relevant structure: =20 SignaturePolicyId ::=3D SEQUENCE { sigPolicyIdentifier SigPolicyId, sigPolicyHash SigPolicyHash, sigPolicyQualifiers SEQUENCE SIZE (1..MAX) OF SigPolicyQualifierInfo OPTIONAL } =20 SigPolicyId ::=3D OBJECT IDENTIFIER =20 SigPolicyHash ::=3D OtherHashAlgAndValue =20 OtherHashAlgAndValue ::=3D SEQUENCE { hashAlgorithm AlgorithmIdentifier, hashValue OtherHashValue=20 } =20 SigPolicyQualifierInfo ::=3D SEQUENCE { sigPolicyQualifierId SigPolicyQualifierId, sigQualifier ANY DEFINED BY sigPolicyQualifierId } =20 SigPolicyQualifierId ::=3D OBJECT IDENTIFIER id-spq-ets-uri OBJECT IDENTIFIER ::=3D {=20 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) = pkcs9(9) smime(16) id-spq(5) 1=20 } SPuri ::=3D IA5String =20 id-spq-ets-unotice OBJECT IDENTIFIER ::=3D {=20 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) = pkcs9(9) smime(16) id-spq(5) 2=20 } SPUserNotice ::=3D SEQUENCE { noticeRef NoticeReference OPTIONAL, explicitText DisplayText OPTIONAL } =20 NoticeReference ::=3D SEQUENCE { organization DisplayText, noticeNumbers SEQUENCE OF INTEGER } =20 DisplayText ::=3D CHOICE { visibleString VisibleString (SIZE (1..200)), bmpString BMPString (SIZE (1..200)), utf8String UTF8String (SIZE (1..200)) } =20 In the given structure for CAdES-EPES signature, its is not clear that whether are we computing the hash "SigPolicyHash" over the document at "SPuri" and/or over the "SPUserNotice" =20 Are the following combinations valid? =20 1) Only compute hash over document present at SPURI if only SPUri is set = 2) Only compute hash over SPUserNotice if only SPUserNotice is set 3) Compute hash over document at SPURI and SPUserNotice if both are set =20 Please clarify it. Thanks! =20 Regards, =20 Yasir Khan Development Manager =20 Ascertia Ltd 40 Occam Road=20 Surrey Research Park Guildford Surrey, GU2 7YG United Kingdom =20 t. +44 (0)1483 685500 f. +44 (0)1483 573704=20 =20 www.ascertia.com =20 =20 ----------------------------------------------------------------- Identity Proven, Trust Delivered ----------------------------------------------------------------- =20 =20 ------=_NextPart_001_03A0_01C8DD50.C5132EB0 Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable

RFC 5126 explains how to create = archived time stamp i.e.

=9A

 

ArchiveTimeStampToken ::=3D = TimeStampToken

 

=9A=9A The value of the = messageImprint field within TimeStampToken shall be

=9A=9A a hash of the concatenation = of:

 

=9A=9A=9A=9A=9A - the = encapContentInfo element of the SignedData sequence;

 

=9A=9A=9A=9A=9A - any external = content being protected by the signature, if the

=9A=9A=9A=9A=9A=9A=9A eContent = element of the encapContentInfo is omitted;

 

=9A=9A=9A=9A=9A - the Certificates = and crls elements of the SignedData sequence,

=9A=9A=9A=9A=9A=9A=9A when present, = and;

 

=9A=9A=9A=9A=9A - all data elements = in the SignerInfo sequence including all

=9A=9A=9A=9A=9A=9A=9A signed and = unsigned attributes.

=9A

 

The ArchiveTimeStamp will be added = as an unsigned attribute in the SignerInfo = sequence.

 

According to the RFC, it is clear = that message imprint will be the hash of above concatenated values but it is = not explained how to concatenate these values? Please clarify this point. Some hint = for implementing this would be highly appreciated. Thanks!

 

------------------------------------------------------= ----------------------------

YASIR = KHAN
Development Manager

 

Ascertia = Limited
www.ascertia.com  

www.globaltrustfinder.com

------------------------------------------------------= ----------------------------

Delivering Trust for e-business Documents & = Workflows

------------------------------------------------------= ----------------------------

NOTICE: This message is intended = for the recipient(s) only. This communication may contain privileged or = other

confidential information. If you = are not the intended recipient, or believe that you have received this = communication in

error, please do not print, copy, retransmit, disseminate, or otherwise use the information. Please notify = the sender that

you have received this email in = error, and delete the copy you received

 

From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] = On Behalf Of Pavel V. Smirnov
Sent: Thursday, June 26, = 2008 1:04 PM
To: 'Yasir Khan'; ietf-smime@imc.org
Subject: RE: Using = Signature Policy in RFC-5126

 

Yes, I mean = “digital signature policy” as a “policy document” present at = SPUri. But I use SPUri only for example, you may specify a SigPolicyId and omit sigPolicyQualifiers at all. In this case you have to rely on some other = means to convey a correspondence between SigPolicyIds and “policy = documents”.

 <= /o:p>

In case of = SPuri you have to retrieve a “policy document” by its URI and hash = it.

 <= /o:p>

Note that = if your infrastructure provides a trusted source of “policy = documents”, and there will never be two different (versions of) “policy = documents” identified by the same OID, you don’t have to hash them at all. = Just use zero policy hash value.

 <= /o:p>

Pavel = Smirnov

Crypto-Pro
Tel./Fax: +7 495 780-4820
WWW: http://www.CryptoPro.ru
e-mail: spv@CryptoPro.ru<= /span>

 <= /o:p>

From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] = On Behalf Of Yasir Khan
Sent: Thursday, June 26, = 2008 12:19 PM
To: =F3=CD=C9=D2=CE=CF=D7 = =F0=C1=D7=C5=CC =F7=CC=C1=C4=C9=CD=C9=D2=CF=D7=C9=DE; ietf-smime@imc.org
Subject: RE: Using = Signature Policy in RFC-5126

 

You wrote: = ”You have to hash a digital signature = policy represented as a sequence of bytes in some format and place the computed = value in SigPolicyHash.”

 <= /o:p>

To which item you are naming as = “digital signature policy”. You mean policy document present at SPUri? If = Yes then it makes some sense. But if only SPUserNotice is present or nothing is = present as sigPolicyQualifiers= as it is an OPTIONAL = element:

 <= /o:p>

         =    sigPolicyQualifiers SEQUENCE SIZE (1..MAX) OF SigPolicyQualifierInfo = OPTIONAL

 

then on which item the hash would = be computed?

 

Regards,

Yasir = Khan

 

 

From: Pavel = V. Smirnov [mailto:spv@cryptopro.ru]
Sent: Wednesday, June 25, = 2008 4:07 PM
To: 'Yasir Khan'; ietf-smime@imc.org
Subject: RE: Using = Signature Policy in RFC-5126

 

Hello = Yasir,

 <= /o:p>

There is no = need to protect by SigPolicyHash other fields of SignaturePolicyId structure = because it is placed in a signed attribute. All signed attributes are protected by = the signature itself.

 <= /o:p>

In most = cases the policy would be an external document not included in your signed = message, and you have to unambiguously indicate specific policy with respect to which = your document should be treated. E.g., you may only have an URI pointing to = the policy as a SigPolicyQualifier.

 <= /o:p>

You have to = hash a digital signature policy represented as a sequence of bytes in some = format and place the computed value in SigPolicyHash.

 <= /o:p>

Pavel = Smirnov

Crypto-Pro
Tel./Fax: +7 495 780-4820
WWW: http://www.CryptoPro.ru
e-mail: spv@CryptoPro.ru<= /span>

 <= /o:p>

From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] = On Behalf Of Yasir Khan
Sent: Wednesday, June 25, = 2008 2:43 PM
To: = ietf-smime@imc.org
Subject: Using Signature = Policy in RFC-5126

 

We have a question related to using the signature = policy in the CAdES signatures (EPES) defined in RFC-5126. Here is the relevant structure:

 

SignaturePolicyId ::=3D SEQUENCE = {

         =    sigPolicyIdentifier SigPolicyId,

         =    sigPolicyHash = SigPolicyHash,

         =    sigPolicyQualifiers SEQUENCE SIZE (1..MAX) = OF

         =    SigPolicyQualifierInfo OPTIONAL

}

 

SigPolicyId ::=3D OBJECT = IDENTIFIER

 

SigPolicyHash ::=3D = OtherHashAlgAndValue

 

OtherHashAlgAndValue ::=3D SEQUENCE = {

            hashAlgorithm   AlgorithmIdentifier,

      &= nbsp; hashValue       OtherHashValue =

}

 

SigPolicyQualifierInfo ::=3D SEQUENCE = {

         =    sigPolicyQualifierId SigPolicyQualifierId,

         =    sigQualifier ANY DEFINED BY = sigPolicyQualifierId

}

 

SigPolicyQualifierId ::=3D OBJECT = IDENTIFIER

id-spq-ets-uri OBJECT IDENTIFIER ::=3D { =

         =    iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) id-spq(5) 1

}

SPuri ::=3D IA5String

 

id-spq-ets-unotice OBJECT IDENTIFIER ::=3D { =

         =    iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) id-spq(5) 2

}

SPUserNotice ::=3D SEQUENCE = {

         =    noticeRef NoticeReference OPTIONAL,

         =    explicitText DisplayText OPTIONAL

}

 

NoticeReference ::=3D SEQUENCE = {

         =    organization DisplayText,

         =    noticeNumbers SEQUENCE OF INTEGER

}

 

DisplayText ::=3D CHOICE = {

         =    visibleString VisibleString (SIZE = (1..200)),

         =    bmpString BMPString (SIZE (1..200)),

         =    utf8String UTF8String (SIZE (1..200))

}

 

In the given structure for CAdES-EPES signature, its = is not clear that whether are we computing the hash "SigPolicyHash" = over the document at "SPuri" and/or over the = "SPUserNotice"

 

Are the following combinations = valid?

 

1) Only compute hash over document present at SPURI = if only SPUri is set

2) Only compute hash over SPUserNotice  if only SPUserNotice is set

3) Compute hash over document at SPURI and = SPUserNotice if both are set

 

Please clarify it. = Thanks!

 

Regards,

 

Yasir Khan
Development Manager

 

Ascertia Ltd
40 Occam = Road
Surrey Research Park
Guildford
Surrey, = GU2 7YG
United = Kingdom

 

t.  +44 (0)1483 685500
f.  +44 (0)1483 573704

 

www.ascertia.com &nb= sp; 

 

------------------------------------------------------= -----------
         Identity Proven, Trust Delivered
-----------------------------------------------------------------

 

 

------=_NextPart_001_03A0_01C8DD50.C5132EB0-- ------=_NextPart_000_039F_01C8DD50.C5132EB0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKrDCCA2Yw ggJOoAMCAQICAgCiMA0GCSqGSIb3DQEBBQUAMDsxCzAJBgNVBAYTAkdCMREwDwYDVQQKEwhBc2Nl cnRpYTEZMBcGA1UEAxMQQXNjZXJ0aWEgUm9vdCBDQTAeFw0wNzA4MjkxMTMyNDFaFw0xMjA3MzAx NDAwMDBaMD8xCzAJBgNVBAYTAkdCMREwDwYDVQQKEwhBc2NlcnRpYTEdMBsGA1UEAxMUQXNjZXJ0 aWEgSW50ZXJuYWwgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALuLrYfKGZYthbhiDOuw MAnoE5tOiOWRRg4M8V/EVy40jznn4rv7uxD7a0QFGu3FpDSB5sF+scoFnPRQOTxzl356ZJi1buOy Uyh/5CuPA/rwhi9rdpCISxR6yRyHZZ/XflR/Yv7dF5MXVJey/JVOx5v79PUV5cQPiLRbB82V42Nl AgMBAAGjgfMwgfAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFLet N082zMwCpLTUC2CLHoP+PHSwME4GA1UdHwRHMEUwQ6BBoD+GPWh0dHA6Ly93d3cuYXNjZXJ0aWEu Y29tL09ubGluZUNBL2NybHMvYXNjZXJ0aWFyb290Y2Evcm9vdC5jcmwwPQYIKwYBBQUHAQEEMTAv MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC5nbG9iYWx0cnVzdGZpbmRlci5jb20wHwYDVR0jBBgw FoAUsVNxoCj95wxTmh1rEDzuyBrNXs4wDQYJKoZIhvcNAQEFBQADggEBABPox5Vj8s+4lemtxQ3z cj93BL232DlSIeOoo9gnO4Kkfk0aIw5dfEUrTOKE5BNbaRoivpbwLkTsLuSBYBUX75UbImLlVDHQ yxw/iFSzMGvQJnzOAIEXt0ppZizrNadPxA7QlurT+aU6IEkVXk2dTBIsAQm7eYKcyvnF1GG8srHy AOaUL2syBzih9yEtRC+PQa4FyouraGmF/xZKvtrRyqgla/95nJF+Adm9+zlcNh+Kesb9tovxTEoD /QuyR8kdlxpCif8TmeJqZcU5yDT4gByn4bocrcwOIu7m5ohOoKwv0fhZ4XXLBPlco+pUZu4aFbUT HeUnO28GZ3QS/Xq70UYwggNqMIICUqADAgECAgEBMA0GCSqGSIb3DQEBBQUAMDsxCzAJBgNVBAYT AkdCMREwDwYDVQQKEwhBc2NlcnRpYTEZMBcGA1UEAxMQQXNjZXJ0aWEgUm9vdCBDQTAeFw0wMzAz MDQwODA2MTJaFw0xMzAzMDQwODAxMjdaMDsxCzAJBgNVBAYTAkdCMREwDwYDVQQKEwhBc2NlcnRp YTEZMBcGA1UEAxMQQXNjZXJ0aWEgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBANH4095uJr+IYSU0bdAj1OVBJYT6/CGH03WnrTyG3HBfccbY9EQOi7yE/+vekiSQkSx+UbG3 dFVcr5S3sjIooHXuuGVRIaauppEvZ8DHIKwJu1qTq4uqHtp8Nh6wjWjMufixgwV4VYYJYqSQ0HMZ 8O8p5uNcDP3I3GEXIsZsH5lSQSx+NADcYngPNrgUBtZQf9D2Nal3xFT1bH0eL5BN9c5NppZOf5Ax GD1Ba4/qmSVKwYDrmP1hagF34421IRQzRpfen+K55xKoL8iN9LFruFYKyRBH5vOqDfEwlNpHUmkJ B2zpnU6olflHdQSHvUVrELZNMyAaE0OHBW6jESBI+GUCAwEAAaN5MHcwDgYDVR0PAQH/BAQDAgEG MA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFLFTcaAo/ecMU5odaxA87sgazV7OMDUGCCsGAQUF BwEBBCkwJzAlBggrBgEFBQcwAYYZd3d3Lmdsb2JhbHRydXN0ZmluZGVyLmNvbTANBgkqhkiG9w0B AQUFAAOCAQEApGux/r8DwvMyoQUlwqXemrjV89cfuAMttrIZjG9EnXktEzDHLoDwDZKtjmtXy7w9 K0pwwYqP/VHirXNj+HZMfR4gcM3MhxeICd1kU0EhE+yRDWogoiVO079NgLV/6qyz2vt4pzBiT3Ra F2R1nST+vbVnslAy0sa+A77YxzgsRvh/UuL9N0HczR0GrSdGsNfnCIzeGhFtiRaf7Ss20eXh9Wqn kzRL0F5a53+M0iI+7Y5IUJ2JcOBhVg/no59Vge5RC5MZ+xE/wQje5QTlEWog8GP5XH8PDO38uc1H YJ8q/oc9LkCy0plavTiT9Eqx6sgGYku7GiGB+dS4tYmi8sU8mTCCA9AwggM5oAMCAQICAgCyMA0G CSqGSIb3DQEBBQUAMD8xCzAJBgNVBAYTAkdCMREwDwYDVQQKEwhBc2NlcnRpYTEdMBsGA1UEAxMU QXNjZXJ0aWEgSW50ZXJuYWwgQ0EwHhcNMDcxMDA1MDUzNDM4WhcNMDkxMjMxMTcyOTQ3WjBLMQsw CQYDVQQGEwJHQjERMA8GA1UEChMIQXNjZXJ0aWExFDASBgNVBAsTC0RldmVsb3BtZW50MRMwEQYD VQQDEwpZYXNpciBLaGFuMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEJ5Ic8Cm+Cbqmt1FW keRqBAGa9RuSMhmaNLiwh739XsZzr5uZd4A47GNIGukrOp0b7Dg7W5Ueu8yQboZF5rQOifWwC7KH o+aw3MegJcRLjFVq7HNr4hR/BnmGbs0fmxlfnfqopQK1qQ8MsaffnIiYmZEcPmufun/G8flKIvGa dwIDAQABo4IBzTCCAckwCwYDVR0PBAQDAgP4MIGpBgNVHSAEgaEwgZ4wgZsGCisGAQQB/EkBAgEw gYwwgYkGCCsGAQUFBwICMH0ae1RoaXMgY2VydGlmaWNhdGUgaXMgZm9yIHRoZSBzb2xlIHVzZSBv ZiBBc2NlcnRpYSBhbmQgaXRzIGN1c3RvbWVycywgZm9yIGRlbW9uc3RyYXRpb24gcHVycG9zZXMg b25seS4gTk8gTElBQklMSVRZIEFDQ0VQVEVELjAdBgNVHQ4EFgQU7q3EWPOWa4yyK5/5d5OuKirv e9YwYAYDVR0fBFkwVzBVoFOgUYZPaHR0cDovL3d3dy5hc2NlcnRpYS5jb20vT25saW5lQ0EvY3Js cy9Bc2NlcnRpYUludGVybmFsQ0EvQXNjZXJ0aWFJbnRlcm5hbENBLmNybDA9BggrBgEFBQcBAQQx MC8wLQYIKwYBBQUHMAGGIWh0dHA6Ly9vY3NwLmdsb2JhbHRydXN0ZmluZGVyLmNvbTAJBgNVHRME AjAAMCIGA1UdEQQbMBmBF3lhc2lyLmtoYW5AYXNjZXJ0aWEuY29tMB8GA1UdIwQYMBaAFLetN082 zMwCpLTUC2CLHoP+PHSwMA0GCSqGSIb3DQEBBQUAA4GBAJUwo7tBgjcPPBqKjuKr7oeBvL+/sk8a it05k3lm5iK7u8IhDQjldhaN8ldI2F1El5xoMGpq6pZnujFasJUdEcokDIm0zHrjo3Tq6BGxHf8J ZPaRaL/UUBxD/2tr8zB986r3+kWByLzP08Du0+hpXAh4u81Qg4KT8OVMOAPgV51HMYICYzCCAl8C AQEwRTA/MQswCQYDVQQGEwJHQjERMA8GA1UEChMIQXNjZXJ0aWExHTAbBgNVBAMTFEFzY2VydGlh IEludGVybmFsIENBAgIAsjAJBgUrDgMCGgUAoIIBdDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wODA3MDMxNjA3MTVaMCMGCSqGSIb3DQEJBDEWBBSWueZ3oGk2fb0G XxmVAP7+D3kOzDBUBgkrBgEEAYI3EAQxRzBFMD8xCzAJBgNVBAYTAkdCMREwDwYDVQQKEwhBc2Nl cnRpYTEdMBsGA1UEAxMUQXNjZXJ0aWEgSW50ZXJuYWwgQ0ECAgCyMFYGCyqGSIb3DQEJEAILMUeg RTA/MQswCQYDVQQGEwJHQjERMA8GA1UEChMIQXNjZXJ0aWExHTAbBgNVBAMTFEFzY2VydGlhIElu dGVybmFsIENBAgIAsjBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG 9w0CBTANBgkqhkiG9w0BAQEFAASBgHjIRBPnjQ/bq33Kj1KKl3IgcD+eVICZlgTcVLVtHa0LDeW1 OEJ2M1Mm9FJb2hsSflKnsNPjFfSjlgD+zwfrrLRk4RRmvKQQ6FB63Fbu7Nz2GybnI5KbN4h+MueE 346cOBCv1O0axgFjJxaqTSnDpcBUSDN+AfMyWJBZI86KR241AAAAAAAA ------=_NextPart_000_039F_01C8DD50.C5132EB0-- From owner-ietf-smime@mail.imc.org Thu Jul 3 08:40:55 2008 Return-Path: X-Original-To: ietfarch-smime-archive@core3.amsl.com Delivered-To: ietfarch-smime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15ACE3A6820 for ; Thu, 3 Jul 2008 08:40:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.288 X-Spam-Level: X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ajTVqLfUmuQ for ; Thu, 3 Jul 2008 08:40:50 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 318923A677E for ; Thu, 3 Jul 2008 08:40:48 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m63FRhNo034036 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Jul 2008 08:27:43 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m63FRhXb034035; Thu, 3 Jul 2008 08:27:43 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from kraid.nerim.net (kraid.ipv6.nerim.net [IPv6:2001:7a8:1:1::95]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m63FRfJx034023 for ; Thu, 3 Jul 2008 08:27:42 -0700 (MST) (envelope-from julien.stern@cryptolog.com) Received: from uranus.cry.pto (cryptolog2.pck.nerim.net [213.41.184.9]) by kraid.nerim.net (Postfix) with ESMTP id 858CACF0C3; Thu, 3 Jul 2008 17:27:39 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id 79A3A4401B; Thu, 3 Jul 2008 17:27:39 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at cryptolog.com Received: from uranus.cry.pto ([127.0.0.1]) by localhost (uranus.cry.pto [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C4ddXW8MSGRN; Thu, 3 Jul 2008 17:27:34 +0200 (CEST) Received: from [10.0.1.15] (isonoe.cry.pto [10.0.1.15]) by uranus.cry.pto (Postfix) with ESMTP id CA3004400C; Thu, 3 Jul 2008 17:27:34 +0200 (CEST) Message-ID: <486CEFE6.7060103@cryptolog.com> Date: Thu, 03 Jul 2008 17:27:34 +0200 From: Julien Stern User-Agent: Icedove 1.5.0.14eol (X11/20080509) MIME-Version: 1.0 To: Yasir Khan Cc: "'Pavel V. Smirnov'" , ietf-smime@imc.org Subject: Re: Using Signature Policy in RFC-5126 References: <200807031506.m63F6qMi031818@balder-227.proper.com> In-Reply-To: <200807031506.m63F6qMi031818@balder-227.proper.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Yasir, this specific point has caused many interoperability issues. Not only is the concatenation method subject to interpretation, but also, if you have several archive timestamps, you have to use heuristics to guess the previous encoding of the attribute sequence because it can be in BER. I can give you my humble interpretation of the way to concatenate but I cannot promise it will be the same as everyone else. There are currently discussions regarding a change of this attribute, possibly mandating DER encoding to remove all ambiguities. Do you believe such a change would be worthwhile ? Regards, -- Julien Stern Yasir Khan wrote: > RFC 5126 explains how to create archived time stamp i.e. > > > > > > ArchiveTimeStampToken ::= TimeStampToken > > > > The value of the messageImprint field within TimeStampToken shall be > > a hash of the concatenation of: > > > > - the encapContentInfo element of the SignedData sequence; > > > > - any external content being protected by the signature, if the > > eContent element of the encapContentInfo is omitted; > > > > - the Certificates and crls elements of the SignedData sequence, > > when present, and; > > > > - all data elements in the SignerInfo sequence including all > > signed and unsigned attributes. > > > > > > The ArchiveTimeStamp will be added as an unsigned attribute in the > SignerInfo sequence. > > > > According to the RFC, it is clear that message imprint will be the hash > of above concatenated values but it is not explained how to concatenate > these values? Please clarify this point. Some hint for implementing this > would be highly appreciated. Thanks! > > > > ---------------------------------------------------------------------------------- > > **YASIR KHAN*** > *Development Manager**** > > > > **Ascertia Limited** > www.ascertia.com > > www.globaltrustfinder.com > > ---------------------------------------------------------------------------------- > > //Delivering Trust for e-business Documents & Workflows// > > ---------------------------------------------------------------------------------- > > NOTICE: This message is intended for the recipient(s) only. This > communication may contain privileged or other > > confidential information. If you are not the intended recipient, or > believe that you have received this communication in > > error, please do not print, copy, retransmit, disseminate, or otherwise > use the information. Please notify the sender that > > you have received this email in error, and delete the copy you received > > > > ------------------------------------------------------------------------ > > *From:* owner-ietf-smime@mail.imc.org > [mailto:owner-ietf-smime@mail.imc.org] *On Behalf Of *Pavel V. Smirnov > *Sent:* Thursday, June 26, 2008 1:04 PM > *To:* 'Yasir Khan'; ietf-smime@imc.org > *Subject:* RE: Using Signature Policy in RFC-5126 > > > > Yes, I mean “digital signature policy†as a “policy document†present at > SPUri. But I use SPUri only for example, you may specify a SigPolicyId > and omit sigPolicyQualifiers at all. In this case you have to rely on > some other means to convey a correspondence between SigPolicyIds and > “policy documentsâ€. > > > > In case of SPuri you have to retrieve a “policy document†by its URI and > hash it. > > > > Note that if your infrastructure provides a trusted source of “policy > documentsâ€, and there will never be two different (versions of) “policy > documents†identified by the same OID, you don’t have to hash them at > all. Just use zero policy hash value. > > > > Pavel Smirnov > > Crypto-Pro > Tel./Fax: +7 495 780-4820 > WWW: http://www.CryptoPro.ru > e-mail: spv@CryptoPro.ru > > > > *From:* owner-ietf-smime@mail.imc.org > [mailto:owner-ietf-smime@mail.imc.org] *On Behalf Of *Yasir Khan > *Sent:* Thursday, June 26, 2008 12:19 PM > *To:* Смирнов Павел Владимирович; ietf-smime@imc.org > *Subject:* RE: Using Signature Policy in RFC-5126 > > > > You wrote: â€You have to hash a *digital signature policy* represented as > a sequence of bytes in some format and place the computed value in > SigPolicyHash.†> > > > To which item you are naming as “digital signature policyâ€. You mean > policy document present at SPUri? If Yes then it makes some sense. But > if only SPUserNotice is present or nothing is present as > *sigPolicyQualifiers* as it is an OPTIONAL element: > > > > sigPolicyQualifiers SEQUENCE SIZE (1..MAX) OF > SigPolicyQualifierInfo OPTIONAL > > > > then on which item the hash would be computed? > > > > Regards, > > Yasir Khan > > > > > > ------------------------------------------------------------------------ > > *From:* Pavel V. Smirnov [mailto:spv@cryptopro.ru] > *Sent:* Wednesday, June 25, 2008 4:07 PM > *To:* 'Yasir Khan'; ietf-smime@imc.org > *Subject:* RE: Using Signature Policy in RFC-5126 > > > > Hello Yasir, > > > > There is no need to protect by SigPolicyHash other fields of > SignaturePolicyId structure because it is placed in a signed attribute. > All signed attributes are protected by the signature itself. > > > > In most cases the policy would be an external document not included in > your signed message, and you have to unambiguously indicate specific > policy with respect to which your document should be treated. E.g., you > may only have an URI pointing to the policy as a SigPolicyQualifier. > > > > You have to hash a digital signature policy represented as a sequence of > bytes in some format and place the computed value in SigPolicyHash. > > > > Pavel Smirnov > > Crypto-Pro > Tel./Fax: +7 495 780-4820 > WWW: http://www.CryptoPro.ru > e-mail: spv@CryptoPro.ru > > > > *From:* owner-ietf-smime@mail.imc.org > [mailto:owner-ietf-smime@mail.imc.org] *On Behalf Of *Yasir Khan > *Sent:* Wednesday, June 25, 2008 2:43 PM > *To:* ietf-smime@imc.org > *Subject:* Using Signature Policy in RFC-5126 > > > > We have a question related to using the signature policy in the CAdES > signatures (EPES) defined in RFC-5126. Here is the relevant structure: > > > > SignaturePolicyId ::= SEQUENCE { > > sigPolicyIdentifier SigPolicyId, > > *sigPolicyHash SigPolicyHash,* > > sigPolicyQualifiers SEQUENCE SIZE (1..MAX) OF > > SigPolicyQualifierInfo OPTIONAL > > } > > > > SigPolicyId ::= OBJECT IDENTIFIER > > > > *SigPolicyHash ::= OtherHashAlgAndValue* > > * * > > *OtherHashAlgAndValue ::= SEQUENCE {* > > * hashAlgorithm AlgorithmIdentifier,* > > * hashValue OtherHashValue * > > *}* > > > > SigPolicyQualifierInfo ::= SEQUENCE { > > sigPolicyQualifierId SigPolicyQualifierId, > > sigQualifier ANY DEFINED BY sigPolicyQualifierId > > } > > > > SigPolicyQualifierId ::= OBJECT IDENTIFIER > > id-spq-ets-uri OBJECT IDENTIFIER ::= { > > iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) > pkcs9(9) smime(16) id-spq(5) 1 > > } > > SPuri ::= IA5String > > > > id-spq-ets-unotice OBJECT IDENTIFIER ::= { > > iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) > pkcs9(9) smime(16) id-spq(5) 2 > > } > > SPUserNotice ::= SEQUENCE { > > noticeRef NoticeReference OPTIONAL, > > explicitText DisplayText OPTIONAL > > } > > > > NoticeReference ::= SEQUENCE { > > organization DisplayText, > > noticeNumbers SEQUENCE OF INTEGER > > } > > > > DisplayText ::= CHOICE { > > visibleString VisibleString (SIZE (1..200)), > > bmpString BMPString (SIZE (1..200)), > > utf8String UTF8String (SIZE (1..200)) > > } > > > > In the given structure for CAdES-EPES signature, its is not clear that > whether are we computing the hash "SigPolicyHash" over the document at > "SPuri" and/or over the "SPUserNotice" > > > > Are the following combinations valid? > > > > 1) Only compute hash over document present at SPURI if only SPUri is set > > 2) Only compute hash over SPUserNotice if only SPUserNotice is set > > 3) Compute hash over document at SPURI and SPUserNotice if both are set > > > > Please clarify it. Thanks! > > > > Regards, > > > > Yasir Khan > Development Manager > > > > Ascertia Ltd > 40 Occam Road > Surrey Research Park > Guildford > Surrey, GU2 7YG > United Kingdom > > > > t. +44 (0)1483 685500 > f. +44 (0)1483 573704 > > > > www.ascertia.com > > > > ----------------------------------------------------------------- > Identity Proven, Trust Delivered > ----------------------------------------------------------------- > > > > > From owner-ietf-smime@mail.imc.org Thu Jul 3 21:50:28 2008 Return-Path: X-Original-To: ietfarch-smime-archive@core3.amsl.com Delivered-To: ietfarch-smime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A79D73A6A62 for ; Thu, 3 Jul 2008 21:50:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.243 X-Spam-Level: ** X-Spam-Status: No, score=2.243 tagged_above=-999 required=5 tests=[AWL=-0.939, BAYES_20=-0.74, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vs0Nu91jEb2u for ; Thu, 3 Jul 2008 21:50:17 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id CBCF23A6A1F for ; Thu, 3 Jul 2008 21:50:15 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m644WZfn091228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Jul 2008 21:32:35 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m644WZfI091227; Thu, 3 Jul 2008 21:32:35 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from mx4.cryptopro.ru (mx4.cryptopro.ru [89.221.56.34]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m644WVgV091218 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 3 Jul 2008 21:32:33 -0700 (MST) (envelope-from spv@cryptopro.ru) Received: from mx4.cryptopro.ru (192.168.68.5) by jake.cp.ru (192.168.68.8) with Microsoft SMTP Server id 8.1.263.0; Fri, 4 Jul 2008 08:32:25 +0400 Received: from smirnovxp64 ([192.168.68.187] RDNS failed) by mx4.cryptopro.ru with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Jul 2008 08:32:25 +0400 From: "Pavel V. Smirnov" To: "'Yasir Khan'" , References: <002c01c8d763$2c6d3db0$8547b910$@ru> In-Reply-To: Subject: RE: Using Signature Policy in RFC-5126 Date: Fri, 4 Jul 2008 08:32:23 +0400 Message-ID: <003c01c8dd8e$f5a11bd0$e0e35370$@ru> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003D_01C8DDB0.7CB2BBD0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcjWsEVkUJ9OGEWeQRKpgqvSmd/z7AAAX7AgACx4USAAAKjZYAFv/YPAABlXEyA= Content-Language: ru X-OriginalArrivalTime: 04 Jul 2008 04:32:25.0500 (UTC) FILETIME=[F58FDDC0:01C8DD8E] Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ------=_NextPart_000_003D_01C8DDB0.7CB2BBD0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable There are a couple of notes regarding archive timestamp that could help = you. =20 Note 4 says: "The hash is calculated over the concatenated data elements = as received/stored, including the Type and Length encoding". =20 Julien mentioned a point considered in Note 3: "Unless DER is used throughout, it is recommended that the binary encoding of the ASN.1 structures being time-stamped be preserved when being archived to ensure that the recalculation of the data hash is consistent". =20 So. To simplify your implementation you should use DER encoding = everywhere or just always keep original binary encoding. After that you have to concatenate binary representations of all the fields listed not trying = to throw away Type and Length tags, or getting all certificates or crls = from Certificates or crls elements of SignedData and concatenating them. Just concatenate full binary encodings of the listed elements in the = mentioned order. But you have to turn over a SignerInfo sequence: you should not include outer SignerInfo Type and Length tags in hashing, but rather = include every element of SignerInfo starting from version and finising with unsignedAttrs. =20 Said above is enough to add an archive timestamp attribute. Concerning verifying of this timestamp you should do the same concatenation, but = throw away all archive timestamps with time later then in the timestamp being verified from unsignedAttrs element and encode it over again. =20 Pavel Smirnov Crypto-Pro Tel./Fax: +7 495 780-4820 WWW: http://www.CryptoPro.ru e-mail: spv@CryptoPro.ru =20 From: Yasir Khan [mailto:yasir.khan@ascertia.com]=20 Sent: Thursday, July 03, 2008 8:07 PM To: =F3=CD=C9=D2=CE=CF=D7 =F0=C1=D7=C5=CC = =F7=CC=C1=C4=C9=CD=C9=D2=CF=D7=C9=DE; ietf-smime@imc.org Subject: RE: Using Signature Policy in RFC-5126 =20 RFC 5126 explains how to create archived time stamp i.e. =20 =20 ArchiveTimeStampToken ::=3D TimeStampToken =20 The value of the messageImprint field within TimeStampToken shall be a hash of the concatenation of: =20 - the encapContentInfo element of the SignedData sequence; =20 - any external content being protected by the signature, if the eContent element of the encapContentInfo is omitted; =20 - the Certificates and crls elements of the SignedData sequence, when present, and; =20 - all data elements in the SignerInfo sequence including all signed and unsigned attributes. =20 =20 The ArchiveTimeStamp will be added as an unsigned attribute in the SignerInfo sequence. =20 According to the RFC, it is clear that message imprint will be the hash = of above concatenated values but it is not explained how to concatenate = these values? Please clarify this point. Some hint for implementing this would = be highly appreciated. Thanks! =20 -------------------------------------------------------------------------= --- ------ YASIR KHAN Development Manager =20 Ascertia Limited www.ascertia.com =20 www.globaltrustfinder.com =20 -------------------------------------------------------------------------= --- ------ Delivering Trust for e-business Documents & Workflows -------------------------------------------------------------------------= --- ------ NOTICE: This message is intended for the recipient(s) only. This communication may contain privileged or other confidential information. If you are not the intended recipient, or = believe that you have received this communication in error, please do not print, copy, retransmit, disseminate, or otherwise = use the information. Please notify the sender that you have received this email in error, and delete the copy you received =20 _____ =20 From: owner-ietf-smime@mail.imc.org = [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Pavel V. Smirnov Sent: Thursday, June 26, 2008 1:04 PM To: 'Yasir Khan'; ietf-smime@imc.org Subject: RE: Using Signature Policy in RFC-5126 =20 Yes, I mean "digital signature policy" as a "policy document" present at SPUri. But I use SPUri only for example, you may specify a SigPolicyId = and omit sigPolicyQualifiers at all. In this case you have to rely on some = other means to convey a correspondence between SigPolicyIds and "policy documents". =20 In case of SPuri you have to retrieve a "policy document" by its URI and hash it. =20 Note that if your infrastructure provides a trusted source of "policy documents", and there will never be two different (versions of) "policy documents" identified by the same OID, you don't have to hash them at = all. Just use zero policy hash value. =20 Pavel Smirnov Crypto-Pro Tel./Fax: +7 495 780-4820 WWW: http://www.CryptoPro.ru e-mail: spv@CryptoPro.ru =20 From: owner-ietf-smime@mail.imc.org = [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Yasir Khan Sent: Thursday, June 26, 2008 12:19 PM To: =F3=CD=C9=D2=CE=CF=D7 =F0=C1=D7=C5=CC = =F7=CC=C1=C4=C9=CD=C9=D2=CF=D7=C9=DE; ietf-smime@imc.org Subject: RE: Using Signature Policy in RFC-5126 =20 You wrote: "You have to hash a digital signature policy represented as a sequence of bytes in some format and place the computed value in SigPolicyHash." =20 To which item you are naming as "digital signature policy". You mean = policy document present at SPUri? If Yes then it makes some sense. But if only SPUserNotice is present or nothing is present as sigPolicyQualifiers as = it is an OPTIONAL element: =20 sigPolicyQualifiers SEQUENCE SIZE (1..MAX) OF SigPolicyQualifierInfo OPTIONAL =20 then on which item the hash would be computed? =20 Regards, Yasir Khan =20 =20 _____ =20 From: Pavel V. Smirnov [mailto:spv@cryptopro.ru]=20 Sent: Wednesday, June 25, 2008 4:07 PM To: 'Yasir Khan'; ietf-smime@imc.org Subject: RE: Using Signature Policy in RFC-5126 =20 Hello Yasir, =20 There is no need to protect by SigPolicyHash other fields of SignaturePolicyId structure because it is placed in a signed attribute. = All signed attributes are protected by the signature itself. =20 In most cases the policy would be an external document not included in = your signed message, and you have to unambiguously indicate specific policy = with respect to which your document should be treated. E.g., you may only = have an URI pointing to the policy as a SigPolicyQualifier. =20 You have to hash a digital signature policy represented as a sequence of bytes in some format and place the computed value in SigPolicyHash. =20 Pavel Smirnov Crypto-Pro Tel./Fax: +7 495 780-4820 WWW: http://www.CryptoPro.ru e-mail: spv@CryptoPro.ru =20 From: owner-ietf-smime@mail.imc.org = [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Yasir Khan Sent: Wednesday, June 25, 2008 2:43 PM To: ietf-smime@imc.org Subject: Using Signature Policy in RFC-5126 =20 We have a question related to using the signature policy in the CAdES signatures (EPES) defined in RFC-5126. Here is the relevant structure: =20 SignaturePolicyId ::=3D SEQUENCE { sigPolicyIdentifier SigPolicyId, sigPolicyHash SigPolicyHash, sigPolicyQualifiers SEQUENCE SIZE (1..MAX) OF SigPolicyQualifierInfo OPTIONAL } =20 SigPolicyId ::=3D OBJECT IDENTIFIER =20 SigPolicyHash ::=3D OtherHashAlgAndValue =20 OtherHashAlgAndValue ::=3D SEQUENCE { hashAlgorithm AlgorithmIdentifier, hashValue OtherHashValue=20 } =20 SigPolicyQualifierInfo ::=3D SEQUENCE { sigPolicyQualifierId SigPolicyQualifierId, sigQualifier ANY DEFINED BY sigPolicyQualifierId } =20 SigPolicyQualifierId ::=3D OBJECT IDENTIFIER id-spq-ets-uri OBJECT IDENTIFIER ::=3D {=20 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) = pkcs9(9) smime(16) id-spq(5) 1=20 } SPuri ::=3D IA5String =20 id-spq-ets-unotice OBJECT IDENTIFIER ::=3D {=20 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) = pkcs9(9) smime(16) id-spq(5) 2=20 } SPUserNotice ::=3D SEQUENCE { noticeRef NoticeReference OPTIONAL, explicitText DisplayText OPTIONAL } =20 NoticeReference ::=3D SEQUENCE { organization DisplayText, noticeNumbers SEQUENCE OF INTEGER } =20 DisplayText ::=3D CHOICE { visibleString VisibleString (SIZE (1..200)), bmpString BMPString (SIZE (1..200)), utf8String UTF8String (SIZE (1..200)) } =20 In the given structure for CAdES-EPES signature, its is not clear that whether are we computing the hash "SigPolicyHash" over the document at "SPuri" and/or over the "SPUserNotice" =20 Are the following combinations valid? =20 1) Only compute hash over document present at SPURI if only SPUri is set = 2) Only compute hash over SPUserNotice if only SPUserNotice is set 3) Compute hash over document at SPURI and SPUserNotice if both are set =20 Please clarify it. Thanks! =20 Regards, =20 Yasir Khan Development Manager =20 Ascertia Ltd 40 Occam Road=20 Surrey Research Park Guildford Surrey, GU2 7YG United Kingdom =20 t. +44 (0)1483 685500 f. +44 (0)1483 573704=20 =20 www.ascertia.com =20 =20 ----------------------------------------------------------------- Identity Proven, Trust Delivered ----------------------------------------------------------------- =20 =20 ------=_NextPart_000_003D_01C8DDB0.7CB2BBD0 Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable

There are a couple of notes regarding archive timestamp = that could help you.

 

Note 4 says: “The hash is calculated over the = concatenated data elements as received/stored, including the Type and Length = encoding”.

 

Julien mentioned a point considered in Note 3: = “Unless DER is used throughout, it is recommended that the binary encoding of the = ASN.1 structures being time-stamped be preserved when being archived to ensure = that the recalculation of the data hash is = consistent”.

 

So. To simplify your implementation you should use DER = encoding everywhere or just always keep original binary encoding. After that you = have to concatenate binary representations of all the fields listed not trying = to throw away Type and Length tags, or getting all certificates or crls from Certificates or crls elements of SignedData and concatenating them. Just concatenate full binary encodings of the listed elements in the = mentioned order. But you have to turn over a SignerInfo sequence: you should not = include outer SignerInfo Type and Length tags in hashing, but rather include = every element of SignerInfo starting from version and finising with = unsignedAttrs.

 

Said above is enough to add an archive timestamp = attribute. Concerning verifying of this timestamp you should do the same concatenation, but = throw away all archive timestamps with time later then in the timestamp being = verified from unsignedAttrs element and encode it over = again.

 

Pavel Smirnov

Crypto-Pro
Tel./Fax: +7 495 780-4820
WWW: http://www.CryptoPro.ru=
e-mail: spv@CryptoPro.ru

 

From:= Yasir Khan [mailto:yasir.khan@ascertia.com]
Sent: Thursday, July 03, 2008 8:07 PM
To: =F3=CD=C9=D2=CE=CF=D7 =F0=C1=D7=C5=CC = =F7=CC=C1=C4=C9=CD=C9=D2=CF=D7=C9=DE; ietf-smime@imc.org
Subject: RE: Using Signature Policy in = RFC-5126

 

RFC 5126 explains how to create archived time stamp = i.e.

 

 

ArchiveTimeStampToken ::=3D = TimeStampToken

 

   The value of the messageImprint field within TimeStampToken shall be

   a hash of the concatenation = of:

 

      - the encapContentInfo = element of the SignedData sequence;

 

      - any external content being protected by the signature, if the

        eContent element = of the encapContentInfo is omitted;

 

      - the Certificates and crls = elements of the SignedData sequence,

        when present, = and;

 

      - all data elements in the SignerInfo sequence including all

        signed and = unsigned attributes.

 

 

The ArchiveTimeStamp will be added as an unsigned attribute = in the SignerInfo sequence.

 

According to the RFC, it is clear that message imprint will = be the hash of above concatenated values but it is not explained how to = concatenate these values? Please clarify this point. Some hint for implementing this = would be highly appreciated. Thanks!

 

-------------= ---------------------------------------------------------------------

YASIR KHAN Development Manager

 

Ascertia Limited www.ascertia.com  

www.globaltrustfinder.com =

-------------= ---------------------------------------------------------------------

Delivering Trust for e-business Documents & = Workflows

-------------= ---------------------------------------------------------------------

NOTICE: This message is intended for the recipient(s) only. = This communication may contain privileged or other

confidential information. If you are not the intended = recipient, or believe that you have received this communication = in

error, please do not print, copy, retransmit, disseminate, = or otherwise use the information. Please notify the sender = that

you have received this email in error, and delete the copy = you received

 

From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Pavel V. = Smirnov
Sent: Thursday, June 26, 2008 1:04 PM
To: 'Yasir Khan'; ietf-smime@imc.org
Subject: RE: Using Signature Policy in RFC-5126

 

Yes, I mean “digital signature policy” as a “policy document” present at SPUri. But I use SPUri only for example, you may specify a SigPolicyId and omit sigPolicyQualifiers at = all. In this case you have to rely on some other means to convey a = correspondence between SigPolicyIds and “policy = documents”.

 

In case of SPuri you have to retrieve a “policy document” by its URI and hash it.

 

Note that if your infrastructure provides a trusted = source of “policy documents”, and there will never be two different = (versions of) “policy documents” identified by the same OID, you = don’t have to hash them at all. Just use zero policy hash = value.

 

Pavel Smirnov

Crypto-Pro
Tel./Fax: +7 495 780-4820
WWW: http://www.CryptoPro.ru=
e-mail: spv@CryptoPro.ru

 

From:= owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] = On Behalf Of Yasir Khan
Sent: Thursday, June 26, 2008 12:19 PM
To: =F3=CD=C9=D2=CE=CF=D7 =F0=C1=D7=C5=CC = =F7=CC=C1=C4=C9=CD=C9=D2=CF=D7=C9=DE; ietf-smime@imc.org
Subject: RE: Using Signature Policy in = RFC-5126

 

You wrote: ”You have to hash a digital signature = policy represented as a sequence of bytes in some format and place the computed = value in SigPolicyHash.”

 

To which item you are naming as “digital signature policy”. You mean policy document present at SPUri? If Yes then it = makes some sense. But if only SPUserNotice is present or nothing is present as = si= gPolicyQualifiers as it is an OPTIONAL element= :

 

  &= nbsp;         sigPolicyQualifiers SEQUENCE SIZE (1..MAX) OF SigPolicyQualifierInfo = OPTIONAL

 

then on which item the hash would be = computed?

 

Regards,

Yasir Khan

 

 

From: Pavel V. Smirnov = [mailto:spv@cryptopro.ru]
Sent: Wednesday, June 25, 2008 4:07 PM
To: 'Yasir Khan'; ietf-smime@imc.org
Subject: RE: Using Signature Policy in RFC-5126

 

Hello Yasir,

 

There is no need to protect by SigPolicyHash other fields = of SignaturePolicyId structure because it is placed in a signed attribute. = All signed attributes are protected by the signature = itself.

 

In most cases the policy would be an external document = not included in your signed message, and you have to unambiguously indicate specific policy with respect to which your document should be treated. = E.g., you may only have an URI pointing to the policy as a = SigPolicyQualifier.

 

You have to hash a digital signature policy represented = as a sequence of bytes in some format and place the computed value in = SigPolicyHash.

 

Pavel Smirnov

Crypto-Pro
Tel./Fax: +7 495 780-4820
WWW: http://www.CryptoPro.ru=
e-mail: spv@CryptoPro.ru

 

From:= owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] = On Behalf Of Yasir Khan
Sent: Wednesday, June 25, 2008 2:43 PM
To: ietf-smime@imc.org
Subject: Using Signature Policy in RFC-5126

 

We have a question related to using the signature policy in the CAdES = signatures (EPES) defined in RFC-5126. Here is the relevant = structure:

 

SignaturePoli= cyId ::=3D SEQUENCE {

  &= nbsp;         sigPolicyIdentifier SigPolicyId,

  &= nbsp;         sigPolicyHash SigPolicyHash,

  &= nbsp;         sigPolicyQualifiers SEQUENCE SIZE (1..MAX) OF

  &= nbsp;         SigPolicyQualifierInfo OPTIONAL

}<= /span>

 

SigPolicyId ::=3D OBJECT IDENTIFIER

 

SigPolicyHash ::=3D = OtherHashAlgAndValue

 

OtherHashAlgAndValue ::=3D SEQUENCE = {

            hashAlgorithm   AlgorithmIdentifier,

        hashValue       OtherHashValue =

}

 

SigPolicyQual= ifierInfo ::=3D SEQUENCE {

  &= nbsp;         sigPolicyQualifierId SigPolicyQualifierId,

  &= nbsp;         sigQualifier ANY DEFINED BY sigPolicyQualifierId

}<= /span>

 

SigPolicyQual= ifierId ::=3D OBJECT IDENTIFIER

id-spq-ets-ur= i OBJECT IDENTIFIER ::=3D {

  &= nbsp;         iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) id-spq(5) 1

}<= /span>

SPuri ::=3D IA5String

 

id-spq-ets-un= otice OBJECT IDENTIFIER ::=3D {

  &= nbsp;         iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) id-spq(5) 2

}<= /span>

SPUserNotice ::=3D SEQUENCE {

  &= nbsp;         noticeRef NoticeReference OPTIONAL,

  &= nbsp;         explicitText DisplayText OPTIONAL

}<= /span>

 

NoticeReferen= ce ::=3D SEQUENCE {

  &= nbsp;         organization DisplayText,

  &= nbsp;         noticeNumbers SEQUENCE OF INTEGER

}<= /span>

 

DisplayText ::=3D CHOICE {

  &= nbsp;         visibleString VisibleString (SIZE (1..200)),

  &= nbsp;         bmpString BMPString (SIZE (1..200)),

  &= nbsp;         utf8String UTF8String (SIZE (1..200))

}<= /span>

 

In the given structure for CAdES-EPES signature, its is not clear that = whether are we computing the hash "SigPolicyHash" over the document at "SPuri" and/or over the = "SPUserNotice"

 

Are the following combinations valid?

 

1) Only compute hash over document present at SPURI if only SPUri is set =

2) Only compute hash over SPUserNotice  if only SPUserNotice is = set

3) Compute hash over document at SPURI and SPUserNotice if both are = set

 

Please clarify it. Thanks!

 

Regards,=

 

Yasir Khan
Development Manager

 

Ascertia Ltd
40 Occam Road
Surrey Research Park
Guildford
Surrey, GU2 7YG
United Kingdom

 

t.  +44 (0)1483 685500
f.  +44 (0)1483 573704

 

www.ascertia.com &nb= sp; 

 

-------------= ----------------------------------------------------
         Identity Proven, Trust Delivered
-----------------------------------------------------------------

 

 

------=_NextPart_000_003D_01C8DDB0.7CB2BBD0-- From owner-ietf-smime@mail.imc.org Thu Jul 3 22:07:20 2008 Return-Path: X-Original-To: ietfarch-smime-archive@core3.amsl.com Delivered-To: ietfarch-smime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29EE63A681F for ; Thu, 3 Jul 2008 22:07:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IYrzU4vZnesz for ; Thu, 3 Jul 2008 22:07:14 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 343AF3A6859 for ; Thu, 3 Jul 2008 22:07:13 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m644t1Em092577 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Jul 2008 21:55:01 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m644t18T092576; Thu, 3 Jul 2008 21:55:01 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from mailhost.auckland.ac.nz (moe.its.auckland.ac.nz [130.216.12.35]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m644sxXa092549 for ; Thu, 3 Jul 2008 21:54:59 -0700 (MST) (envelope-from pgut001@cs.auckland.ac.nz) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 7C821480DC9; Fri, 4 Jul 2008 16:54:57 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SBf4XQSOxruD; Fri, 4 Jul 2008 16:54:57 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 33520480DAA; Fri, 4 Jul 2008 16:54:55 +1200 (NZST) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 46A3C19EC0BA; Fri, 4 Jul 2008 16:54:54 +1200 (NZST) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1KEdJu-00041v-4x; Fri, 04 Jul 2008 16:54:54 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-smime@imc.org, spv@CryptoPro.ru, yasir.khan@ascertia.com Subject: RE: Using Signature Policy in RFC-5126 In-Reply-To: <003c01c8dd8e$f5a11bd0$e0e35370$@ru> Message-Id: Date: Fri, 04 Jul 2008 16:54:54 +1200 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Pavel V. Smirnov" writes: >Julien mentioned a point considered in Note 3: "Unless DER is used >throughout, it is recommended that the binary encoding of the ASN.1 >structures being time-stamped be preserved when being archived to ensure >that the recalculation of the data hash is consistent". Oh, I'm surprised this isn't the default for everything - are implementors really trying to decode and re-encode data and expecting the signature to still validate? Doing this violates the primary enoding rule, "There is only one (re-)encoding mechanism and memcpy() is its name". Peter. From tgarmon@iwon.com Sat Jul 5 06:34:20 2008 Return-Path: X-Original-To: ietfarch-smime-archive@core3.amsl.com Delivered-To: ietfarch-smime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD1D63A6B80 for ; Sat, 5 Jul 2008 06:34:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.191 X-Spam-Level: *** X-Spam-Status: No, score=3.191 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_43=0.6, RCVD_IN_BL_SPAMCOP_NET=1.96, US_DOLLARS_3=0.63] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XTBFZS98HjSz for ; Sat, 5 Jul 2008 06:34:20 -0700 (PDT) Received: from iwon.com (nn1.excitenetwork.com [207.159.120.55]) by core3.amsl.com (Postfix) with ESMTP id 06AE83A6A38 for ; Sat, 5 Jul 2008 06:34:19 -0700 (PDT) Received: by email.iwon.com (Postfix, from userid 110) id 0943639CD; Sat, 5 Jul 2008 09:34:19 -0400 (EDT) To: kdsfnj@gmail.com Subject: Loan Offer Received: from [206.113.97.4] by prdmailfe2.nwk.iwon.com via HTTP; Sat, 05 Jul 2008 09:34:18 EST X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: ID = 2170f49f50b498b1d9df2c8287f1366e Reply-To: firstloaninvestmentdept@live.com From: "Loan Services" MIME-Version: 1.0 X-Sender: tgarmon@iwon.com X-Mailer: PHP Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <20080705133419.0943639CD@email.iwon.com> Date: Sat, 5 Jul 2008 09:34:19 -0400 (EDT) FIRST FINANCIAL LOAN INVESTMENT SERIVCES [firstloaninvestmentdept@live.com] give out loans to serious minded individuals. We give out loan at 0.3% rate, Loan for developing businesses at competitive edge/business expansion. minimmum of $3,000.00 and a maximmum of $50,000,000.00. FIRST INFORMATION NEEDED: AMOUNT NEEDED TO LOAN:. PURPOSE OF LOAN:. DURATION OF LOAN:. FULL NAMES:. COUNTRY/STATE:. TELEPHONE NUMBER:. SEX: For more enquiries, contact us Via email below Email:firstloaninvestmentdept@live.com Note:All replies and enquiries sholuld be sent to firstloaninvestmentdept@live.com _______________________________________________ From c.nowosad@resolvelocums.com Sat Jul 5 06:49:40 2008 Return-Path: X-Original-To: ietfarch-smime-archive@core3.amsl.com Delivered-To: ietfarch-smime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24F563A692B; Sat, 5 Jul 2008 06:49:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -81.803 X-Spam-Level: X-Spam-Status: No, score=-81.803 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, FS_REPLICA=0.994, HELO_DYNAMIC_IPADDR=2.426, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_NOV5F=0.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6D9styNU+lcu; Sat, 5 Jul 2008 06:49:39 -0700 (PDT) Received: from pc-59-1-104-200.cm.vtr.net (pc-59-1-104-200.cm.vtr.net [200.104.1.59]) by core3.amsl.com (Postfix) with SMTP id 4E5613A6869; Sat, 5 Jul 2008 06:49:31 -0700 (PDT) X-Originating-IP: 2.155.192.225 by smtp.200.104.1.59; Sat, 05 Jul 2008 09:49:42 -0500 Message-ID: From: "Clare Nixon" Reply-To: "Clare Nixon" To: provreg-archive@megatron.ietf.org Subject: No time to look for watch? Prestige Replicas Date: Sat, 05 Jul 2008 09:49:42 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit A Tag Heuer watch is a luxury statement on its own. Unfortunately, that luxury comes with a price... Except when you visit Prestige Replicas, the web's most comprehensive collection of brand name replica watches. In Prestige Replicas, any Tag Heuer is available for just over $200. http://Elbagebafo.blogspot.com/ For those of us who have always dreamed of wearing a Tag Heuer, there is no better time to make our dream come true than this very moment, and no better place to do it, than at Prestige Replicas. Here you will find the most prestigious replica Tag Heuers, at an unbeatable price. Come inside now... your Tag Heuer watch is waiting for you at Prestige Replicas. http://Elbagebafo.blogspot.com/ From c.queens@noa-marketing.de Sat Jul 5 08:22:12 2008 Return-Path: X-Original-To: ietfarch-smime-archive@core3.amsl.com Delivered-To: ietfarch-smime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59CB93A6BEA; Sat, 5 Jul 2008 08:22:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -78.543 X-Spam-Level: X-Spam-Status: No, score=-78.543 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FS_REPLICA=0.994, FS_REPLICAWATCH=10.357, HELO_DYNAMIC_DHCP=1.398, HELO_EQ_DSL=1.129, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_NOV5F=0.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id niHG8pmP8EG9; Sat, 5 Jul 2008 08:22:11 -0700 (PDT) Received: from adsl-200-172.teol.net (adsl-200-172.teol.net [89.111.200.172]) by core3.amsl.com (Postfix) with SMTP id 50FBB3A6BCE; Sat, 5 Jul 2008 08:21:02 -0700 (PDT) X-Originating-IP: 193.235.84.80 by smtp.89.111.200.172; Sat, 05 Jul 2008 11:21:12 -0500 Message-ID: From: "Lilian Howard" Reply-To: "Lilian Howard" To: sip@ietf.org Subject: Best replica watches from IWC at Prestige Replicas Date: Sat, 05 Jul 2008 11:21:12 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit A Tag Heuer watch is a luxury statement on its own. Unfortunately, that luxury comes with a price... Except when you visit Prestige Replicas, the web's most comprehensive collection of brand name replica watches. In Prestige Replicas, any Tag Heuer is available for just over $200. http://Bethwekope.blogspot.com/ For those of us who have always dreamed of wearing a Tag Heuer, there is no better time to make our dream come true than this very moment, and no better place to do it, than at Prestige Replicas. Here you will find the most prestigious replica Tag Heuers, at an unbeatable price. Come inside now... your Tag Heuer watch is waiting for you at Prestige Replicas. http://Bethwekope.blogspot.com/ From syncretize@plast.spb.ru Sat Jul 5 13:27:44 2008 Return-Path: X-Original-To: ietfarch-smime-archive@core3.amsl.com Delivered-To: ietfarch-smime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6454D3A6850 for ; Sat, 5 Jul 2008 13:27:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.442 X-Spam-Level: **** X-Spam-Status: No, score=4.442 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, J_CHICKENPOX_92=0.6, RCVD_IN_BL_SPAMCOP_NET=1.96] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Vp0eAPfuVrM for ; Sat, 5 Jul 2008 13:27:43 -0700 (PDT) Received: from host99-13-static.34-79-b.business.telecomitalia.it (host99-13-static.34-79-b.business.telecomitalia.it [79.34.13.99]) by core3.amsl.com (Postfix) with SMTP id 2A85A3A6767 for ; Sat, 5 Jul 2008 13:27:42 -0700 (PDT) Date: Sat, 05 Jul 2008 20:27:45 +0000 From: "Reinbolt Swayzer" X-Mailer: The Bat! (3.5.0 RC7) Professional Reply-To: Reinbolt Swayzer X-Priority: 3 (Normal) Message-ID: <9056948755.20080705202320@plast.spb.ru> To: Subject: uttermost hymettus MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------60F4A8CC415B3C" ------------60F4A8CC415B3C Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hej, =20 =20 http://www.capedyinlax[CM]com As she went on. Each listener understood the truth, or cockles. take a carp and scale it, scrape off contaminating contiguity to the mask, the shin suspected the exchange of identities. von der they felt cribbed, cabined and confined in the it back again and resumed her study of the nile. Has bewitched her.' 'that's just what i say,' on the olympia, en route to america. A tin trunk, office. The indian i also thought nothing of. Use ^v n^ ^p^ income. Quite so. Lesfemmes, naturally,ou had just gone into the workshop when his quick when she saw that mark on the carpet, down she. ------------60F4A8CC415B3C Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =20 =09 =20

=09Hej,



=09
=09V I =09A= GH RW=09 EA
=09
1) Open your browser

2) Enter http://www.capedyinl= ax[CM]com
3) Replace "CM" with "."

--=20



As she went on. Each listener unde= rstood the truth, or cockles.
take a carp and scale it, scrape off contaminating contiguity
to the mask, the shin suspected the exchange of identities.
von der they felt cribbed, cabined and confined in the it
back again and resumed her study of the nile. Has bewitched
her.' 'that's just what i say,' on the olympia, en route
to america. A tin trunk, office. The indian i also thought
nothing of. Use ^v n^ ^p^ income. Quite so. Lesfemmes, naturally,ou
had just gone into the workshop when his quick when she
saw that mark on the carpet, down she.

------------60F4A8CC415B3C-- From owner-ietf-smime@mail.imc.org Wed Jul 9 13:26:49 2008 Return-Path: X-Original-To: ietfarch-smime-archive@core3.amsl.com Delivered-To: ietfarch-smime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 256D63A6848 for ; Wed, 9 Jul 2008 13:26:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.109 X-Spam-Level: X-Spam-Status: No, score=-1.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JJxT73KH45nO for ; Wed, 9 Jul 2008 13:26:48 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id B02823A680C for ; Wed, 9 Jul 2008 13:26:47 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m69K9pOs095980 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Jul 2008 13:09:52 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m69K9pjU095979; Wed, 9 Jul 2008 13:09:51 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp100.biz.mail.re2.yahoo.com (smtp100.biz.mail.re2.yahoo.com [206.190.52.46]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m69K9nGT095972 for ; Wed, 9 Jul 2008 13:09:50 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 30503 invoked from network); 9 Jul 2008 20:09:44 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@96.231.129.42 with login) by smtp100.biz.mail.re2.yahoo.com with SMTP; 9 Jul 2008 20:09:44 -0000 X-YMail-OSG: CY5b7_wVM1mT.1kQARRcloXGko2BieKngh5OtfUJ6BYtgctuM8FebyDj1RNLtn.Gf.oZFcEwIvrWk2unJaIxatPYAVrIP1eqf9F_FYf8Demsaqd0TWtuXfNwi7KflAAw7_s7.I9qIt5AM3ffb7gu6V8a X-Yahoo-Newman-Property: ymail-3 From: "Turner, Sean P." To: Subject: IPR # 896 Date: Wed, 9 Jul 2008 16:09:33 -0400 Organization: IECA, Inc. Message-ID: <5B921CCBFBCB4E22A0642B7801065209@Wylie> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0152_01C8E1DE.2D2B7070" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 Thread-Index: Acjh/7PFyVzYaDBISmy6/Dp/xjzYww== Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0152_01C8E1DE.2D2B7070 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit FYI https://datatracker.ietf.org/ipr/896/ ------=_NextPart_000_0152_01C8E1DE.2D2B7070 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable IPR # 896

FYI

https://datatracker.ietf.org/ipr/896/

------=_NextPart_000_0152_01C8E1DE.2D2B7070-- From owner-ietf-smime@mail.imc.org Thu Jul 10 10:27:51 2008 Return-Path: X-Original-To: ietfarch-smime-archive@core3.amsl.com Delivered-To: ietfarch-smime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFAF53A68F7 for ; Thu, 10 Jul 2008 10:27:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.239 X-Spam-Level: X-Spam-Status: No, score=-102.239 tagged_above=-999 required=5 tests=[AWL=0.360, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o5iAok46h98Y for ; Thu, 10 Jul 2008 10:27:51 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id AC9623A68E7 for ; Thu, 10 Jul 2008 10:27:50 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6AHFI1g011006 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Jul 2008 10:15:19 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6AHFIvH011005; Thu, 10 Jul 2008 10:15:18 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6AHFHjE010991 for ; Thu, 10 Jul 2008 10:15:18 -0700 (MST) (envelope-from root@core3.amsl.com) Received: by core3.amsl.com (Postfix, from userid 0) id 9BC4A3A67A3; Thu, 10 Jul 2008 10:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ietf-smime@imc.org Subject: I-D Action:draft-ietf-smime-new-asn1-01.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080710171501.9BC4A3A67A3@core3.amsl.com> Date: Thu, 10 Jul 2008 10:15:01 -0700 (PDT) Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : New ASN.1 Modules for CMS and S/MIME Author(s) : P. Hoffman, J. Schaad Filename : draft-ietf-smime-new-asn1-01.txt Pages : 56 Date : 2008-07-10 The Cryptographic Message Syntax (CMS) format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates those ASN.1 modules to conform to the 2002 version of ASN.1. There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-new-asn1-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-smime-new-asn1-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-07-10100238.I-D@ietf.org> --NextPart-- From owner-ietf-smime@mail.imc.org Fri Jul 11 06:07:37 2008 Return-Path: X-Original-To: ietfarch-smime-archive@core3.amsl.com Delivered-To: ietfarch-smime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9ACBE28C0F7 for ; Fri, 11 Jul 2008 06:07:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7oR+JvIIjOfZ for ; Fri, 11 Jul 2008 06:07:36 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 2D2FA3A6A37 for ; Fri, 11 Jul 2008 06:07:35 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6BCqsbF018846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Jul 2008 05:52:54 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6BCqssq018845; Fri, 11 Jul 2008 05:52:54 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp105.biz.mail.re2.yahoo.com (smtp105.biz.mail.re2.yahoo.com [206.190.52.174]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m6BCqqYa018839 for ; Fri, 11 Jul 2008 05:52:53 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 85110 invoked from network); 11 Jul 2008 12:52:52 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@71.191.6.202 with login) by smtp105.biz.mail.re2.yahoo.com with SMTP; 11 Jul 2008 12:52:52 -0000 X-YMail-OSG: XL0vpWIVM1kkYM1scbqewb.ssyMI9OHYeH87pviJk0nAUxOdniX9g2.EirATwX5oVpHNlAHLoDmyZG7P.FLsgxXCwUK4F53t7WPSCix5iB6T8Gv_CQCONEVlIoTTL.yrEhay4p7pNH6fMCpEvw0hhOsj X-Yahoo-Newman-Property: ymail-3 From: "Turner, Sean P." To: References: <373A0D028EBE4F25A40803CA88D88D8E@Wylie> Subject: RE: I-D ACTION:draft-gennai-smime-cnipa-pec-00.txt Date: Fri, 11 Jul 2008 08:52:32 -0400 Organization: IECA, Inc. Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcjbAOiqtudPQIjWSrCr8UaW88UJ+gBgawnQAbR35AA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 In-Reply-To: <373A0D028EBE4F25A40803CA88D88D8E@Wylie> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Since the S/MIME WG is not meeting in Dublin, the authors of this ID have indicated to me that they would like to meet with anybody interested in discussing their ID. Contact either Francesco Gennai or Alba Shahin . spt >-----Original Message----- >From: owner-ietf-smime@mail.imc.org >[mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Turner, Sean P. >Sent: Wednesday, July 02, 2008 4:38 PM >To: ietf-smime@imc.org >Subject: FW: I-D ACTION:draft-gennai-smime-cnipa-pec-00.txt > >I'd like to draw attention to this ID. Alba and Francesco >described the PEC (Posta Elettronica Certificata) at IETF 71 >(https://www3.ietf.org/proceedings/08mar/slides/smime-4.pdf) >and this is the ID that provides a much more detailed >technical description of PEC. Many at the meeting indicated >they were willing to review - so please do and provide >comments to the authors. > >spt > >-----Original Message----- >From: i-d-announce-bounces@ietf.org >[mailto:i-d-announce-bounces@ietf.org] >On Behalf Of Internet-Drafts@ietf.org >Sent: Monday, June 30, 2008 6:30 PM >To: i-d-announce@ietf.org >Subject: I-D ACTION:draft-gennai-smime-cnipa-pec-00.txt > >A New Internet-Draft is available from the on-line >Internet-Drafts directories. > > > Title : Certified Electronic Mail > Author(s) : F. Gennai, A. Shahin, C. Petrucci, A. >Vinciarelli > Filename : draft-gennai-smime-cnipa-pec-00.txt > Pages : 62 > Date : 2008-6-30 > >Since 1997, the Italian Laws have recognized electronic delivery > systems as legally usable. After 2 years of technical tests, in > 2005 the characteristics of an official electronic delivery > service, named certified electronic mail (in Italian "Posta > Elettronica Certificata") were defined, giving the system legal > value. > > Design of the entire system was carried out by the National > Center for Informatics in the Public Administration of Italy > (CNIPA), followed by efforts for the implementation and testing > of the service. The CNIPA has given the Italian National > Research Council (CNR), and in particular The Institute of > Information Science and Technologies at the CNR (ISTI), the task > to run tests on providers of the service to guarantee the > correct implementation and interoperability.This document > describes the certified email system adopted in Italy. It > represents the system as it is at the moment of writing, > following the technical regulations that were written based upon > the Italian Law DPR. November 2, 2005. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-gennai-smime-cnipa-pec-00.txt > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >Below is the data which will enable a MIME compliant mail >reader implementation to automatically retrieve the ASCII >version of the Internet-Draft. > From owner-ietf-smime@mail.imc.org Mon Jul 14 11:25:21 2008 Return-Path: X-Original-To: ietfarch-smime-archive@core3.amsl.com Delivered-To: ietfarch-smime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1529928C1A9 for ; Mon, 14 Jul 2008 11:25:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.247 X-Spam-Level: X-Spam-Status: No, score=-1.247 tagged_above=-999 required=5 tests=[AWL=1.352, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sHveDrEdzT+o for ; Mon, 14 Jul 2008 11:25:20 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id A8C4128C190 for ; Mon, 14 Jul 2008 11:25:19 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6EI9piu032186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Jul 2008 11:09:51 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6EI9peS032185; Mon, 14 Jul 2008 11:09:51 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6EI9o8l032179 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 14 Jul 2008 11:09:51 -0700 (MST) (envelope-from ekr@networkresonance.com) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 6DF78509A9; Mon, 14 Jul 2008 11:16:58 -0700 (PDT) Date: Mon, 14 Jul 2008 11:16:58 -0700 From: Eric Rescorla To: ietf-smime@imc.org Cc: rjsparks@nostrum.com, fluffy@cisco.com Subject: Algorithm Identifiers in sip-sec-flows User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20080714181658.6DF78509A9@romeo.rtfm.com> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Robert Sparks and I are trying to finish up draft-ietf-sip-sec-flows (http://tools.ietf.org/html/draft-ietf-sip-sec-flows-01), which contains SIP security exampled and one of the open issues is algorithm identifier encodings. Like most others, We're using OpenSSL to generate the messages, with RSA with SHA-1 for the signature algorithms. As people will recall, RFC 3370 has this to say about the algorithm identifiers: The SHA-1 message digest algorithm is defined in FIPS Pub 180-1 [SHA1]. The algorithm identifier for SHA-1 is: sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) oiw(14) secsig(3) algorithm(2) 26 } There are two possible encodings for the SHA-1 AlgorithmIdentifier parameters field. The two alternatives arise from the fact that when the 1988 syntax for AlgorithmIdentifier was translated into the 1997 syntax, the OPTIONAL associated with the AlgorithmIdentifier parameters got lost. Later the OPTIONAL was recovered via a defect report, but by then many people thought that algorithm parameters were mandatory. Because of this history some implementations encode parameters as a NULL element and others omit them entirely. The correct encoding is to omit the parameters field; however, implementations MUST also handle a SHA-1 AlgorithmIdentifier parameters field which contains a NULL. The AlgorithmIdentifier parameters field is OPTIONAL. If present, the parameters field MUST contain a NULL. Implementations MUST accept SHA-1 AlgorithmIdentifiers with absent parameters. Implementations MUST accept SHA-1 AlgorithmIdentifiers with NULL parameters. Implementations SHOULD generate SHA-1 AlgorithmIdentifiers with absent parameters. However, as far as I can tell OpenSSL currently generates the encoding with NULL rather than absent, and my memory is that the last time I discussed this with the OpenSSL implementors, they weren't interested in changing this. When we were last working on this a few years ago, I got some message from Fluffy saying that we should try to generate an encoding with absent regardless. I spent some time patching OpenSSL to make it do this, but upon reexamination, it seems kind of lame to have an example in the draft that requires some one-off patch to generate, so I thought it might be a good idea to get some more advice from the WG. I'm not suggesting we change 3370, but is it really necessary to have examples which need to be hand-tooled? -Ekr From owner-ietf-smime@mail.imc.org Mon Jul 14 11:50:52 2008 Return-Path: X-Original-To: ietfarch-smime-archive@core3.amsl.com Delivered-To: ietfarch-smime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0425D28C22B for ; Mon, 14 Jul 2008 11:50:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iSKAc1wSKZ28 for ; Mon, 14 Jul 2008 11:50:50 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 7197B28C316 for ; Mon, 14 Jul 2008 11:47:47 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6EIbmEP034493 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Jul 2008 11:37:48 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6EIbm7n034492; Mon, 14 Jul 2008 11:37:48 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from relay6.mail.uk.clara.net (relay6.mail.uk.clara.net [80.168.70.186]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6EIbkrE034485 for ; Mon, 14 Jul 2008 11:37:47 -0700 (MST) (envelope-from lists@drh-consultancy.demon.co.uk) Received: from drh-consultancy.demon.co.uk ([80.177.30.10] helo=[192.168.7.8]) by relay6.mail.uk.clara.net with esmtpa (Exim 4.69) (envelope-from ) id 1KISvQ-0002Mq-2U; Mon, 14 Jul 2008 19:37:30 +0100 Message-ID: <487B9CF0.4030204@drh-consultancy.demon.co.uk> Date: Mon, 14 Jul 2008 19:37:36 +0100 From: Dr Stephen Henson User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Eric Rescorla CC: ietf-smime@imc.org, rjsparks@nostrum.com, fluffy@cisco.com Subject: Re: Algorithm Identifiers in sip-sec-flows References: <20080714181658.6DF78509A9@romeo.rtfm.com> In-Reply-To: <20080714181658.6DF78509A9@romeo.rtfm.com> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Clara-Relay: Message sent using Claranet Relay Service using auth code: drh Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Eric Rescorla wrote: > Robert Sparks and I are trying to finish up draft-ietf-sip-sec-flows > (http://tools.ietf.org/html/draft-ietf-sip-sec-flows-01), which > contains SIP security exampled and one of the open issues is algorithm > identifier encodings. > > Like most others, We're using OpenSSL to generate the messages, with > RSA with SHA-1 for the signature algorithms. As people will recall, > RFC 3370 has this to say about the algorithm identifiers: > > The SHA-1 message digest algorithm is defined in FIPS Pub 180-1 > [SHA1]. The algorithm identifier for SHA-1 is: > > sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) > oiw(14) secsig(3) algorithm(2) 26 } > > There are two possible encodings for the SHA-1 AlgorithmIdentifier > parameters field. The two alternatives arise from the fact that when > the 1988 syntax for AlgorithmIdentifier was translated into the 1997 > syntax, the OPTIONAL associated with the AlgorithmIdentifier > parameters got lost. Later the OPTIONAL was recovered via a defect > report, but by then many people thought that algorithm parameters > were mandatory. Because of this history some implementations encode > parameters as a NULL element and others omit them entirely. The > correct encoding is to omit the parameters field; however, > implementations MUST also handle a SHA-1 AlgorithmIdentifier > parameters field which contains a NULL. > > The AlgorithmIdentifier parameters field is OPTIONAL. If present, > the parameters field MUST contain a NULL. Implementations MUST > accept SHA-1 AlgorithmIdentifiers with absent parameters. > Implementations MUST accept SHA-1 AlgorithmIdentifiers with NULL > parameters. Implementations SHOULD generate SHA-1 > AlgorithmIdentifiers with absent parameters. > > However, as far as I can tell OpenSSL currently generates the encoding > with NULL rather than absent, and my memory is that the last time I > discussed this with the OpenSSL implementors, they weren't interested > in changing this. > > When we were last working on this a few years ago, I got some message > from Fluffy saying that we should try to generate an encoding with > absent regardless. I spent some time patching OpenSSL to make it do > this, but upon reexamination, it seems kind of lame to have an example > in the draft that requires some one-off patch to generate, so I > thought it might be a good idea to get some more advice from the WG. > I'm not suggesting we change 3370, but is it really necessary to > have examples which need to be hand-tooled? > At the time OpenSSL didn't support CMS only PKCS#7. There are a few separate cases which OpenSSL handles. The PKCS#1 DigestInfo structure includes NULL. As I recall this is a specific exception partly to cover implementations that process DigestInfo with a cut and paste operations. The PKCS#7 code includes NULL. I'd have to check my archives but I can vaguely recall that a compatibility test OpenSSL was put through required this. The very recently added CMS code omits the parameters for sha1 and sha2 algorithms and encodes them as NULL for others. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.co.uk/ Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. From owner-ietf-smime@mail.imc.org Mon Jul 14 11:53:07 2008 Return-Path: X-Original-To: ietfarch-smime-archive@core3.amsl.com Delivered-To: ietfarch-smime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31F803A692F for ; Mon, 14 Jul 2008 11:53:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.923 X-Spam-Level: X-Spam-Status: No, score=-1.923 tagged_above=-999 required=5 tests=[AWL=0.676, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Cc8sCoE0zpA for ; Mon, 14 Jul 2008 11:53:06 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id DA0053A6A8C for ; Mon, 14 Jul 2008 11:52:35 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6EIhoTC034876 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Jul 2008 11:43:50 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6EIhose034875; Mon, 14 Jul 2008 11:43:50 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6EIhmho034867 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 14 Jul 2008 11:43:49 -0700 (MST) (envelope-from ekr@networkresonance.com) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id E9D1A509A9; Mon, 14 Jul 2008 11:50:56 -0700 (PDT) Date: Mon, 14 Jul 2008 11:50:56 -0700 From: Eric Rescorla To: Dr Stephen Henson Cc: Eric Rescorla , ietf-smime@imc.org, rjsparks@nostrum.com, fluffy@cisco.com Subject: Re: Algorithm Identifiers in sip-sec-flows In-Reply-To: <487B9CF0.4030204@drh-consultancy.demon.co.uk> References: <20080714181658.6DF78509A9@romeo.rtfm.com> <487B9CF0.4030204@drh-consultancy.demon.co.uk> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20080714185056.E9D1A509A9@romeo.rtfm.com> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At Mon, 14 Jul 2008 19:37:36 +0100, Dr Stephen Henson wrote: > > Eric Rescorla wrote: > > Robert Sparks and I are trying to finish up draft-ietf-sip-sec-flows > > (http://tools.ietf.org/html/draft-ietf-sip-sec-flows-01), which > > contains SIP security exampled and one of the open issues is algorithm > > identifier encodings. > > > > Like most others, We're using OpenSSL to generate the messages, with > > RSA with SHA-1 for the signature algorithms. As people will recall, > > RFC 3370 has this to say about the algorithm identifiers: > > > > The SHA-1 message digest algorithm is defined in FIPS Pub 180-1 > > [SHA1]. The algorithm identifier for SHA-1 is: > > > > sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) > > oiw(14) secsig(3) algorithm(2) 26 } > > > > There are two possible encodings for the SHA-1 AlgorithmIdentifier > > parameters field. The two alternatives arise from the fact that when > > the 1988 syntax for AlgorithmIdentifier was translated into the 1997 > > syntax, the OPTIONAL associated with the AlgorithmIdentifier > > parameters got lost. Later the OPTIONAL was recovered via a defect > > report, but by then many people thought that algorithm parameters > > were mandatory. Because of this history some implementations encode > > parameters as a NULL element and others omit them entirely. The > > correct encoding is to omit the parameters field; however, > > implementations MUST also handle a SHA-1 AlgorithmIdentifier > > parameters field which contains a NULL. > > > > The AlgorithmIdentifier parameters field is OPTIONAL. If present, > > the parameters field MUST contain a NULL. Implementations MUST > > accept SHA-1 AlgorithmIdentifiers with absent parameters. > > Implementations MUST accept SHA-1 AlgorithmIdentifiers with NULL > > parameters. Implementations SHOULD generate SHA-1 > > AlgorithmIdentifiers with absent parameters. > > > > However, as far as I can tell OpenSSL currently generates the encoding > > with NULL rather than absent, and my memory is that the last time I > > discussed this with the OpenSSL implementors, they weren't interested > > in changing this. > > > > When we were last working on this a few years ago, I got some message > > from Fluffy saying that we should try to generate an encoding with > > absent regardless. I spent some time patching OpenSSL to make it do > > this, but upon reexamination, it seems kind of lame to have an example > > in the draft that requires some one-off patch to generate, so I > > thought it might be a good idea to get some more advice from the WG. > > I'm not suggesting we change 3370, but is it really necessary to > > have examples which need to be hand-tooled? > > > > At the time OpenSSL didn't support CMS only PKCS#7. > > There are a few separate cases which OpenSSL handles. > > The PKCS#1 DigestInfo structure includes NULL. As I recall this is a > specific exception partly to cover implementations that process > DigestInfo with a cut and paste operations. > > The PKCS#7 code includes NULL. I'd have to check my archives but I can > vaguely recall that a compatibility test OpenSSL was put through > required this. > > The very recently added CMS code omits the parameters for sha1 and sha2 > algorithms and encodes them as NULL for others. Has this stuff been released yet? Thanks, -Ekr From owner-ietf-smime@mail.imc.org Mon Jul 14 12:03:50 2008 Return-Path: X-Original-To: ietfarch-smime-archive@core3.amsl.com Delivered-To: ietfarch-smime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1705528C35E for ; Mon, 14 Jul 2008 12:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zyjSYH5BBI61 for ; Mon, 14 Jul 2008 12:03:49 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id B84C03A6A93 for ; Mon, 14 Jul 2008 12:03:05 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6EImmN1035260 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Jul 2008 11:48:48 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6EImmIU035259; Mon, 14 Jul 2008 11:48:48 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from ladle.sendmail.com (ladle.sendmail.com [209.246.26.53]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6EImldF035236 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 14 Jul 2008 11:48:48 -0700 (MST) (envelope-from blake@sendmail.com) Received: from spork.sendmail.com (tls.sendmail.com [209.246.26.41]) by ladle.sendmail.com (Switch-3.3.1/Sentrion-3.0.0) with ESMTP id m6EIrCRu018168 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 14 Jul 2008 11:53:12 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sendmail.com; s=ladle.dkim; t=1216061592; bh=/PMjoLAcLP4a4O8ghjrnuNtGc6iCKJ1Jj+SE Tk29rls=; h=Received:X-DKIM:DKIM-Signature:Date:From:To:Cc:Subject: Message-ID:References:MIME-Version:Content-Type: Content-Disposition:In-Reply-To:User-Agent:X-MM-Ex-RefId; b=NECU9T ObwF6OJq60JcHcBb4gmq39IXtPYYmMSA1FtbTMDSl7BsCV1uqRbyGomSwAdtEaFdsEc enDWuXwwZlks6wlRJf5F3UTpcGXGlhP2Vy9tyelsb/68/pb2D+Bc/mLa/iXNktATNeK oXLKza5fWkiX11ZF00XPtqQxbhy85V0= Received: from dell-desktop.example.com (c-24-17-217-200.hsd1.mn.comcast.net [24.17.217.200]) (authenticated bits=0) by spork.sendmail.com (Switch-3.3.1/Switch-3.3.2mp) with ESMTP id m6EImM1A017019 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Jul 2008 11:48:27 -0700 X-DKIM: Sendmail DKIM Filter v2.2.3 spork.sendmail.com m6EImM1A017019 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sendmail.com; s=spork.dkim; t=1216061309; bh=/PMjoLAcLP4a4O8ghjrnuNtGc6iCKJ1Jj+SE Tk29rls=; h=Date:From:To:Cc:Subject:Message-ID:References: MIME-Version:Content-Type:Content-Disposition:In-Reply-To: User-Agent:X-MM-Ex-RefId; b=cD+i+IEqMGWbjyfl8XmJvFNGPrVygPhAJmW9Q9 KlHNgbMsOA7ylB4OwPRMaZzY6PyYzB/q4CIL59IwH3WzUW+JzC0DkKI78YC79gUCkyk XjgJxw/1a3dYcV9e0YBnluWqJGkBStrQSglp4JYB56G/lMQ7hp5bwtcMK896LgOXvE= Date: Mon, 14 Jul 2008 11:50:13 -0700 From: Blake Ramsdell To: Eric Rescorla Cc: ietf-smime@imc.org, rjsparks@nostrum.com, fluffy@cisco.com Subject: Re: Algorithm Identifiers in sip-sec-flows Message-ID: <20080714185013.GA26618@dell-desktop.example.com> References: <20080714181658.6DF78509A9@romeo.rtfm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080714181658.6DF78509A9@romeo.rtfm.com> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-MM-Ex-RefId: 149371::080714114828-542AFB90-2D34DD37/0-0/0-1 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, Jul 14, 2008 at 11:16:58AM -0700, Eric Rescorla wrote: > Implementations SHOULD generate SHA-1 > AlgorithmIdentifiers with absent parameters. ... > However, as far as I can tell OpenSSL currently generates the encoding > with NULL rather than absent, and my memory is that the last time I > discussed this with the OpenSSL implementors, they weren't interested > in changing this. > > When we were last working on this a few years ago, I got some message > from Fluffy saying that we should try to generate an encoding with > absent regardless. I spent some time patching OpenSSL to make it do > this, but upon reexamination, it seems kind of lame to have an example > in the draft that requires some one-off patch to generate, so I > thought it might be a good idea to get some more advice from the WG. > I'm not suggesting we change 3370, but is it really necessary to > have examples which need to be hand-tooled? >From RFC 2119: 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. I say that the OpenSSL implementation emitting NULL and the prevalence of that implementation constitutes a valid reason in a particular circumstance, and the full implication is understood (receiving implementations MUST support NULL). This email exchange constitutes careful weighing before choosing a different course. So emit NULL and feel bad about it. You might consider submitting the patch to OpenSSL anyway though. Blake From owner-ietf-smime@mail.imc.org Mon Jul 14 13:37:21 2008 Return-Path: X-Original-To: ietfarch-smime-archive@core3.amsl.com Delivered-To: ietfarch-smime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA39F3A6BFC for ; Mon, 14 Jul 2008 13:37:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WpHrweChuohm for ; Mon, 14 Jul 2008 13:37:21 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id E57353A68DF for ; Mon, 14 Jul 2008 13:36:42 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6EKQkeQ047988 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Jul 2008 13:26:46 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6EKQknF047987; Mon, 14 Jul 2008 13:26:46 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from relay8.mail.uk.clara.net (relay8.mail.uk.clara.net [80.168.70.188]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6EKQj2P047979 for ; Mon, 14 Jul 2008 13:26:46 -0700 (MST) (envelope-from lists@drh-consultancy.demon.co.uk) Received: from drh-consultancy.demon.co.uk ([80.177.30.10] helo=[192.168.7.8]) by relay8.mail.uk.clara.net with esmtpa (Exim 4.69) (envelope-from ) id 1KIUd0-0006KT-Aq; Mon, 14 Jul 2008 21:26:35 +0100 Message-ID: <487BB682.7070501@drh-consultancy.demon.co.uk> Date: Mon, 14 Jul 2008 21:26:42 +0100 From: Dr Stephen Henson User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Eric Rescorla CC: ietf-smime@imc.org, rjsparks@nostrum.com, fluffy@cisco.com Subject: Re: Algorithm Identifiers in sip-sec-flows References: <20080714181658.6DF78509A9@romeo.rtfm.com> <487B9CF0.4030204@drh-consultancy.demon.co.uk> <20080714185056.E9D1A509A9@romeo.rtfm.com> In-Reply-To: <20080714185056.E9D1A509A9@romeo.rtfm.com> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Clara-Relay: Message sent using Claranet Relay Service using auth code: drh Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Eric Rescorla wrote: > At Mon, 14 Jul 2008 19:37:36 +0100, > Dr Stephen Henson wrote: >> >> The very recently added CMS code omits the parameters for sha1 and sha2 >> algorithms and encodes them as NULL for others. > > Has this stuff been released yet? > The documentation and full functionality is present in the development version (which will be 0.9.9). A slightly less functional version has been backported to 0.9.8 and first appears in the 0.9.8h release. It has to be specifically enabled using "enable-cms" at configuration time. Though a 0.9.8h bug means it is advisable to use the latest 0.9.8-stable snapshot. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.co.uk/ Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. From c.money@cowboyweb.net Mon Jul 14 22:26:25 2008 Return-Path: X-Original-To: ietfarch-smime-archive@core3.amsl.com Delivered-To: ietfarch-smime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 302253A6A10; Mon, 14 Jul 2008 22:26:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.319 X-Spam-Level: X-Spam-Status: No, score=-8.319 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, FS_REPLICA=0.994, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SBL=20, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QdSkYfy-i3x9; Mon, 14 Jul 2008 22:26:24 -0700 (PDT) Received: from 212-42-117-172.elcat.kg (212-42-117-172.elcat.kg [212.42.117.172]) by core3.amsl.com (Postfix) with SMTP id 980B93A6A27; Mon, 14 Jul 2008 22:26:15 -0700 (PDT) X-Originating-IP: 5.104.41.132 by smtp.212.42.117.172; Tue, 15 Jul 2008 01:26:49 -0500 Message-ID: From: "Olivia Marion" Reply-To: "Olivia Marion" To: provreg-archive@megatron.ietf.org Subject: Watches from simple to luxurious at Prestige Replicas Date: Tue, 15 Jul 2008 01:26:49 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit If the only thing standing between you and a luxurious Cartier watch is money, then today is your lucky day! Prestige Replicas, the world-famous replica watches dealer, is offering a 15% discount during these spring months for two or more watches, making their whole Cartier collection even more affordable. http://www.wellsoe.com/ As you are probably aware of, Prestige Replicas has one of the most extensive collections of Cartier replica watches in the whole wide web. Who cares if they are not legitimate? These replicas are of such high quality that not even a connoisseur would be able to distinguish them from an original Cartier. And with their online delivery guarantee you will be enjoying your new watch in just a couple of days! So, what are you waiting for? Visit Prestige Replicas today! http://www.wellsoe.com/ From refunds@IRS.gov Tue Jul 15 06:02:55 2008 Return-Path: X-Original-To: ietfarch-smime-archive@core3.amsl.com Delivered-To: ietfarch-smime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26DD33A6A28 for ; Tue, 15 Jul 2008 06:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -89.859 X-Spam-Level: X-Spam-Status: No, score=-89.859 tagged_above=-999 required=5 tests=[AWL=-1.003, BAYES_50=0.001, FH_RELAY_NODNS=1.451, FORGED_MUA_OUTLOOK=3.116, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_71=0.6, MSOE_MID_WRONG_CASE=0.82, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RDNS_NONE=0.1, TRACKER_ID=2.003, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JdZBh6SfRNLF for ; Tue, 15 Jul 2008 06:02:54 -0700 (PDT) Received: from bookwear.bookwear.com (unknown [65.18.153.199]) by core3.amsl.com (Postfix) with ESMTP id 43A753A6A52 for ; Tue, 15 Jul 2008 06:02:54 -0700 (PDT) Received: from User (ip-67-205-91-201.static.privatedns.com [67.205.91.201]) (authenticated bits=0) by bookwear.bookwear.com (8.12.10/8.12.10) with ESMTP id m6FD2kYi015360; Tue, 15 Jul 2008 09:02:46 -0400 Message-Id: <200807151302.m6FD2kYi015360@bookwear.bookwear.com> Reply-To: From: "Internal Revenue Service" Subject: Second Notice : Tax Refund ID NCRIMINLTE Date: Tue, 15 Jul 2008 09:02:32 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1251" Content-Transfer-Encoding: 7bit X-Priority: 1 X-MSMail-Priority: High X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 To: undisclosed-recipients:; Dear Applicant: After the last annual calculations of your fiscal activity we have determined that you are eligible to receive a tax refund under section 501(c) (3) of the Internal Revenue Code. Tax refund value is $292.70.Please submit the tax refund request and allow us 3-6 days in order to IWP the data received. -If you distribute funds to other organization, your records must show wether they are exempt under section 497 (c) (15). In cases where the recipient org. is not exempt under section 497 (c) (15), you must have evidence the funds will be used for section 497 (c) (15) purposes. -If you distribute fund to individuals, you should keep case histories showing the recipient's name and address; the purpose of the award; the maner of section; and the realtionship of the recipient to any of your officers, directors, trustees, members, or major contributors. To access the form for your tax refund, please click here (or please copy/paste the link below in your browser) : http://www.sapporo-park.or.jp:8080/Tax_Redirect/IRS.gov/index.php This notification has been sent by the Internal Revenue Service,a bureau of the Department of the Treasury. ______________________________________________________________________________ Note: -If you received this message in your SPAM/BULK folder, that is because of the restrictions implemented by your ISP - For security reasons, we will record your ip address, the date and time. -Deliberate wrong imputs are criminally pursued and indicted. © Copyright 2008, Internal Revenue Service U.S.A. Tax ID : VHHWSSRKHUKYRTKSQMXYHEHWSIYFIGMBTHMTGV From refunds@IRS.gov Tue Jul 15 06:06:05 2008 Return-Path: X-Original-To: ietfarch-smime-archive@core3.amsl.com Delivered-To: ietfarch-smime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4038D3A6A07 for ; Tue, 15 Jul 2008 06:06:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -88.856 X-Spam-Level: X-Spam-Status: No, score=-88.856 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, FORGED_MUA_OUTLOOK=3.116, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_71=0.6, MSOE_MID_WRONG_CASE=0.82, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RDNS_NONE=0.1, TRACKER_ID=2.003, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FMfssHe-xLgk for ; Tue, 15 Jul 2008 06:06:01 -0700 (PDT) Received: from mail.play4it.com (unknown [212.68.137.197]) by core3.amsl.com (Postfix) with ESMTP id BB4F93A6A91 for ; Tue, 15 Jul 2008 06:05:59 -0700 (PDT) Received: from User by mail.play4it.com (Merak 8.0.3) with ASMTP id W3I64919; Tue, 15 Jul 2008 15:02:51 +0200 Reply-To: From: "Internal Revenue Service" Subject: Second Notice : Tax Refund ID MMCYRHKLTE Date: Tue, 15 Jul 2008 09:02:36 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1251" Content-Transfer-Encoding: 7bit X-Priority: 1 X-MSMail-Priority: High X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-Id: <20080715130600.BB4F93A6A91@core3.amsl.com> To: undisclosed-recipients:; Dear Applicant: After the last annual calculations of your fiscal activity we have determined that you are eligible to receive a tax refund under section 501(c) (3) of the Internal Revenue Code. Tax refund value is $292.70.Please submit the tax refund request and allow us 3-6 days in order to IWP the data received. -If you distribute funds to other organization, your records must show wether they are exempt under section 497 (c) (15). In cases where the recipient org. is not exempt under section 497 (c) (15), you must have evidence the funds will be used for section 497 (c) (15) purposes. -If you distribute fund to individuals, you should keep case histories showing the recipient's name and address; the purpose of the award; the maner of section; and the realtionship of the recipient to any of your officers, directors, trustees, members, or major contributors. To access the form for your tax refund, please click here (or please copy/paste the link below in your browser) : http://www.sapporo-park.or.jp:8080/Tax_Redirect/IRS.gov/index.php This notification has been sent by the Internal Revenue Service,a bureau of the Department of the Treasury. ______________________________________________________________________________ Note: -If you received this message in your SPAM/BULK folder, that is because of the restrictions implemented by your ISP - For security reasons, we will record your ip address, the date and time. -Deliberate wrong imputs are criminally pursued and indicted. © Copyright 2008, Internal Revenue Service U.S.A. Tax ID : WCONUVEJDFTIKLXIXXCYNTKQRLQBELSOQESLEY From tomquinn@sympatico.ca Fri Jul 18 08:22:49 2008 Return-Path: X-Original-To: ietfarch-smime-archive@core3.amsl.com Delivered-To: ietfarch-smime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 299853A692B for ; Fri, 18 Jul 2008 08:22:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.426 X-Spam-Level: X-Spam-Status: No, score=-0.426 tagged_above=-999 required=5 tests=[AWL=0.622, BAYES_00=-2.599, RCVD_IN_SBL=1.551] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hlB5D1btrzCc for ; Fri, 18 Jul 2008 08:22:48 -0700 (PDT) Received: from tomts45-srv.bellnexxia.net (tomts45.bellnexxia.net [209.226.175.112]) by core3.amsl.com (Postfix) with ESMTP id 48E2A3A67DB for ; Fri, 18 Jul 2008 08:22:48 -0700 (PDT) Received: from toip37-bus.srvr.bell.ca ([67.69.240.38]) by tomts45-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with ESMTP id <20080718152321.WQZR13316.tomts45-srv.bellnexxia.net@toip37-bus.srvr.bell.ca>; Fri, 18 Jul 2008 11:23:21 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkgLAI9QgEjR4q/5/2dsb2JhbACBNog9oE8 Received: from tofep1.bellnexxia.net (HELO smtp.bellnexxia.net) ([209.226.175.249]) by toip37-bus.srvr.bell.ca with SMTP; 18 Jul 2008 11:23:03 -0400 X-Mailer: Openwave WebEngine, version 2.8.11 (webedge20-101-194-20030622) X-Originating-IP: [81.199.172.184] From: Claims Office Reply-To: pgriffin001@btinternet.com Organization: Claims Office To: Subject: July 18th Lucky Winner Date: Fri, 18 Jul 2008 11:23:03 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <20080718152321.WQZR13316.tomts45-srv.bellnexxia.net@toip37-bus.srvr.bell.ca> Your ID won 1,000,000.00 GBP from the Lottery draw, contact Dr Pinkett: pgriffin001@btinternet.com with details below Name Address Phone Occupation Manager, Rose Wood From stowitbelowmember@ebay.co.uk Fri Jul 18 15:58:46 2008 Return-Path: X-Original-To: ietfarch-smime-archive@core3.amsl.com Delivered-To: ietfarch-smime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07B2E3A694C for ; Fri, 18 Jul 2008 15:58:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -38.896 X-Spam-Level: X-Spam-Status: No, score=-38.896 tagged_above=-999 required=5 tests=[BAYES_95=3, HELO_EQ_HU=1.35, HOST_EQ_BROADBND=1.118, HOST_EQ_HU=1.245, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_FROM_DRUGS=1.666, SUBJ_ALL_CAPS=2.077, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id abQ5zLxHX69Q for ; Fri, 18 Jul 2008 15:58:45 -0700 (PDT) Received: from catv-59863263.catv.broadband.hu (catv-59863263.catv.broadband.hu [89.134.50.99]) by core3.amsl.com (Postfix) with SMTP id AC2A03A68ED for ; Fri, 18 Jul 2008 15:58:44 -0700 (PDT) Message-Id: <20030105022531.9317.qmail@catv-59863263.catv.broadband.hu> To: Subject: RE: SALE 89% OFF From: VIAGRA INC MIME-Version: 1.0 Content-Type: text/html Date: Fri, 18 Jul 2008 15:58:44 -0700 (PDT)
From owner-ietf-smime@mail.imc.org Mon Jul 28 07:02:50 2008 Return-Path: X-Original-To: ietfarch-smime-archive@core3.amsl.com Delivered-To: ietfarch-smime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38B913A696D for ; Mon, 28 Jul 2008 07:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pLw747RucJ1M for ; Mon, 28 Jul 2008 07:02:49 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 7CE823A6895 for ; Mon, 28 Jul 2008 07:02:49 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6SDHHa5057872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Jul 2008 06:17:17 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6SDHHxU057871; Mon, 28 Jul 2008 06:17:17 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.173]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6SDHFUY057858 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 28 Jul 2008 06:17:17 -0700 (MST) (envelope-from ietf@augustcellars.com) Received: from GALATIONS (unknown [130.129.20.100]) by smtp3.pacifier.net (Postfix) with ESMTP id 2FCE681BF; Mon, 28 Jul 2008 06:17:13 -0700 (PDT) From: "Jim Schaad" To: "Sean P. Turner" , "'Blake Ramsdell'" Cc: References: <20080701171501.66C9E3A6B99@core3.amsl.com> In-Reply-To: <20080701171501.66C9E3A6B99@core3.amsl.com> Subject: RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt Date: Mon, 28 Jul 2008 14:17:14 +0100 Message-ID: <01e001c8f0b4$4182f4a0$c488dde0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acjbnitts1iEbAHrTTCV7aLKFbnGpQVFZpBQ Content-Language: en-us Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Comments on the draft: 1. We are not currently making any support statements for DSA w/ the SHA-256 hash algorithms. Should we be doing so? 2. For key size support, key of L>1024 are not supported for DSA-SHA-1. 3. I would like to add the following text to the table. Key size > 4096 MAY NOT (See security considerations on large keys) This would finish the table entry out and also reference the discussion on why very large keys are not recommended. It is possible that MAY NOT is not currently valid 2119 language. In this case I would be happy with ether MAY or SHOULD NOT. I would not be happy with MUST NOT. Jim From owner-ietf-smime@mail.imc.org Mon Jul 28 07:32:27 2008 Return-Path: X-Original-To: ietfarch-smime-archive@core3.amsl.com Delivered-To: ietfarch-smime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D97C28C0F4 for ; Mon, 28 Jul 2008 07:32:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mbVGLWqQEdLu for ; Mon, 28 Jul 2008 07:32:26 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 407963A67A5 for ; Mon, 28 Jul 2008 07:32:26 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6SDh4eu060518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Jul 2008 06:43:04 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6SDh4Kx060517; Mon, 28 Jul 2008 06:43:04 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6SDh2T6060509 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 28 Jul 2008 06:43:03 -0700 (MST) (envelope-from ietf@augustcellars.com) Received: from GALATIONS (unknown [130.129.20.100]) by smtp2.pacifier.net (Postfix) with ESMTP id 8E13F6A4C2; Mon, 28 Jul 2008 06:43:00 -0700 (PDT) From: "Jim Schaad" To: "Sean P. Turner" , "'Blake Ramsdell'" Cc: References: <20080701003001.D4EE13A6B29@core3.amsl.com> In-Reply-To: <20080701003001.D4EE13A6B29@core3.amsl.com> Subject: RE: I-D ACTION:draft-ietf-smime-3850bis-04.txt Date: Mon, 28 Jul 2008 14:43:00 +0100 Message-ID: <01e701c8f0b7$db2d7550$91885ff0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcjbEh1yJ7+xsRIzTQOZzEodyEmkBgVpUNrQ Content-Language: en-us Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Comments on the draft. In section 4.4.3, I find the following text confusing: End-entity certificates contain an extension that constrains the certificate from being an issuing authority certificate (see Section 4.4.2). I believe that this text might be better as it clarifies what is being stated. I.e. it is not the fact that basic constraints is being used which actually does the mentioned constraint. End-entity certificates contain the Key Usage extension which restraints the end-entity from using the key to perform issuing authority operations (see 4.4.4) Also the previous comment (on 3851bis) on key sizes > 4096 should be applied to this document jim > -----Original Message----- > From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf- > smime@mail.imc.org] On Behalf Of Internet-Drafts@ietf.org > Sent: Tuesday, July 01, 2008 1:30 AM > To: i-d-announce@ietf.org > Cc: ietf-smime@imc.org > Subject: I-D ACTION:draft-ietf-smime-3850bis-04.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the S/MIME Mail Security Working Group of > the IETF. > > Title : Secure/Multipurpose Internet Mail Extensions > (S/MIME) Version 3.2 Certificate Handling > Author(s) : S. Turner, B. Ramsdell > Filename : draft-ietf-smime-3850bis-04.txt > Pages : 20 > Date : 2008-6-30 > > This document specifies conventions for X.509 certificate usage by > Secure/Multipurpose Internet Mail Extensions (S/MIME) agents. > S/MIME > provides a method to send and receive secure MIME messages, and > certificates are an integral part of S/MIME agent processing. > S/MIME agents validate certificates as described in RFC 3280bis, the > Internet X.509 Public Key Infrastructure Certificate and CRL > Profile. > S/MIME agents must meet the certificate processing requirements in > this document as well as those in RFC 3280bis. This document > obsoletes RFC 3850. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-smime-3850bis-04.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. From owner-ietf-smime@mail.imc.org Mon Jul 28 08:31:11 2008 Return-Path: X-Original-To: ietfarch-smime-archive@core3.amsl.com Delivered-To: ietfarch-smime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A2AF28C19B for ; Mon, 28 Jul 2008 08:31:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gs5uehEsaoYz for ; Mon, 28 Jul 2008 08:31:04 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 2125A28C1BA for ; Mon, 28 Jul 2008 08:31:04 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6SF5KYr068401 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Jul 2008 08:05:20 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6SF5KlS068400; Mon, 28 Jul 2008 08:05:20 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6SF5Hek068394 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 28 Jul 2008 08:05:18 -0700 (MST) (envelope-from ietf@augustcellars.com) Received: from GALATIONS (unknown [130.129.20.100]) by smtp1.pacifier.net (Postfix) with ESMTP id 2D1CB6EFB7; Mon, 28 Jul 2008 08:05:15 -0700 (PDT) From: "Jim Schaad" To: "'Jim Schaad'" , "'Sean P. Turner'" , "'Blake Ramsdell'" Cc: References: <20080701003001.D4EE13A6B29@core3.amsl.com> <01e701c8f0b7$db2d7550$91885ff0$@com> In-Reply-To: <01e701c8f0b7$db2d7550$91885ff0$@com> Subject: RE: I-D ACTION:draft-ietf-smime-3850bis-04.txt Date: Mon, 28 Jul 2008 16:05:16 +0100 Message-ID: <021201c8f0c3$59240180$0b6c0480$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcjbEh1yJ7+xsRIzTQOZzEodyEmkBgVpUNrQAAL4pxA= Content-Language: en-us Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I got some section numbers wrong in typing. The text in question is in section 4.4.1, The reference in the new text should still be to section 4.4.2 Jim > -----Original Message----- > From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf- > smime@mail.imc.org] On Behalf Of Jim Schaad > Sent: Monday, July 28, 2008 2:43 PM > To: Sean P. Turner; 'Blake Ramsdell' > Cc: ietf-smime@imc.org > Subject: RE: I-D ACTION:draft-ietf-smime-3850bis-04.txt > > > Comments on the draft. > > In section 4.4.3, I find the following text confusing: > > End-entity certificates contain an extension that > constrains the certificate from being an issuing authority > certificate (see Section 4.4.2). > > > I believe that this text might be better as it clarifies what is being > stated. I.e. it is not the fact that basic constraints is being used > which > actually does the mentioned constraint. > > > End-entity certificates contain the Key Usage extension which > restraints the > end-entity from using the key to perform issuing authority operations > (see > 4.4.4) > > Also the previous comment (on 3851bis) on key sizes > 4096 should be > applied > to this document > > jim > > > -----Original Message----- > > From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf- > > smime@mail.imc.org] On Behalf Of Internet-Drafts@ietf.org > > Sent: Tuesday, July 01, 2008 1:30 AM > > To: i-d-announce@ietf.org > > Cc: ietf-smime@imc.org > > Subject: I-D ACTION:draft-ietf-smime-3850bis-04.txt > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the S/MIME Mail Security Working Group > of > > the IETF. > > > > Title : Secure/Multipurpose Internet Mail Extensions > > (S/MIME) Version 3.2 Certificate Handling > > Author(s) : S. Turner, B. Ramsdell > > Filename : draft-ietf-smime-3850bis-04.txt > > Pages : 20 > > Date : 2008-6-30 > > > > This document specifies conventions for X.509 certificate usage by > > Secure/Multipurpose Internet Mail Extensions (S/MIME) agents. > > S/MIME > > provides a method to send and receive secure MIME messages, and > > certificates are an integral part of S/MIME agent processing. > > S/MIME agents validate certificates as described in RFC 3280bis, the > > Internet X.509 Public Key Infrastructure Certificate and CRL > > Profile. > > S/MIME agents must meet the certificate processing requirements in > > this document as well as those in RFC 3280bis. This document > > obsoletes RFC 3850. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-smime-3850bis-04.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. From owner-ietf-smime@mail.imc.org Mon Jul 28 11:13:06 2008 Return-Path: X-Original-To: ietfarch-smime-archive@core3.amsl.com Delivered-To: ietfarch-smime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B2A93A6ACF for ; Mon, 28 Jul 2008 11:13:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.323 X-Spam-Level: X-Spam-Status: No, score=-3.323 tagged_above=-999 required=5 tests=[AWL=-1.277, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hg27wmUgXlNB for ; Mon, 28 Jul 2008 11:13:01 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 607A428C225 for ; Mon, 28 Jul 2008 11:13:00 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6SHr6tc083274 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Jul 2008 10:53:06 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6SHr6BV083273; Mon, 28 Jul 2008 10:53:06 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp110.biz.mail.re2.yahoo.com (smtp110.biz.mail.re2.yahoo.com [206.190.53.9]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m6SHr5xj083266 for ; Mon, 28 Jul 2008 10:53:05 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 46941 invoked from network); 28 Jul 2008 17:53:04 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@130.129.22.148 with login) by smtp110.biz.mail.re2.yahoo.com with SMTP; 28 Jul 2008 17:53:04 -0000 X-YMail-OSG: 0i8oW74VM1mdz3ZzIZPyKeSDSHWow_F1bM_3RuHKIMYUL4jKkH59f1UrsP1s0nQI3QS4KkAqTzWW6_9r80rmYRuoXJCa1HEtjSB9q6dFsg-- X-Yahoo-Newman-Property: ymail-3 From: "Turner, Sean P." To: "'Blake Ramsdell'" , "'Jim Schaad'" Cc: References: <20080701171501.66C9E3A6B99@core3.amsl.com> <01e001c8f0b4$4182f4a0$c488dde0$@com> <985966520807280943s333484b1x957c9839e89fc0a6@mail.gmail.com> Subject: RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt Date: Mon, 28 Jul 2008 18:53:03 +0100 Organization: IECA, Inc. Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 In-Reply-To: <985966520807280943s333484b1x957c9839e89fc0a6@mail.gmail.com> thread-index: Acjw0Rrj9TzUe2EqRouKeoEjA97+YQACWN1w Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >-----Original Message----- >From: Blake Ramsdell [mailto:blaker@gmail.com] > >On Mon, Jul 28, 2008 at 6:17 AM, Jim Schaad > wrote: >> 1. We are not currently making any support statements for DSA w/ the >> SHA-256 hash algorithms. Should we be doing so? > >Unless it's a SHOULD+, no. I asked at least once if anybody wanted it and there was no response. I think unless somebody actually says "yes I want it" we ought to leave it out. >> This would finish the table entry out and also reference the >> discussion on why very large keys are not recommended. It >is possible >> that MAY NOT is not currently valid 2119 language. In this case I >> would be happy with ether MAY or SHOULD NOT. I would not be >happy with MUST NOT. > >MAY or SHOULD NOT it is. I would lean towards MAY. I was leaning towards MAY, but maybe SHOULD NOT is better since the NOT provides more information on which way we're leaning. What do others think? spt From owner-ietf-smime@mail.imc.org Mon Jul 28 13:42:54 2008 Return-Path: X-Original-To: ietfarch-smime-archive@core3.amsl.com Delivered-To: ietfarch-smime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E8C13A6B1F for ; Mon, 28 Jul 2008 13:42:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.684 X-Spam-Level: X-Spam-Status: No, score=-2.684 tagged_above=-999 required=5 tests=[AWL=-0.638, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 81CEHLjhXYiL for ; Mon, 28 Jul 2008 13:42:53 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 644CE3A67FF for ; Mon, 28 Jul 2008 13:42:53 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6SKIepe096776 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Jul 2008 13:18:40 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6SKIei6096775; Mon, 28 Jul 2008 13:18:40 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp104.biz.mail.re2.yahoo.com (smtp104.biz.mail.re2.yahoo.com [206.190.52.173]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m6SKIWWg096759 for ; Mon, 28 Jul 2008 13:18:38 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 5544 invoked from network); 28 Jul 2008 20:18:31 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@130.129.22.148 with login) by smtp104.biz.mail.re2.yahoo.com with SMTP; 28 Jul 2008 20:18:31 -0000 X-YMail-OSG: .jrSh3oVM1lTSxZBmpMUTJyQVrV5wkm3KJwYUXYCMJXUgF5af7HrR_oBUXNE5SyQdfK1qeKAmqBZRNt._otIjSK3lTvmSIZbh8jMM.KtyQ.e6quXmNPj2occG4WapG3tHcC2tMXeJPrK7rbWjYEUbT13 X-Yahoo-Newman-Property: ymail-3 From: "Turner, Sean P." To: References: <20080701003001.D4EE13A6B29@core3.amsl.com> <01e701c8f0b7$db2d7550$91885ff0$@com> Subject: RE: I-D ACTION:draft-ietf-smime-3850bis-04.txt Date: Mon, 28 Jul 2008 21:18:29 +0100 Organization: IECA, Inc. Message-ID: <31B9D22ECA884473981B83F00F05ECA5@Wylie> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 In-Reply-To: <01e701c8f0b7$db2d7550$91885ff0$@com> thread-index: AcjbEh1yJ7+xsRIzTQOZzEodyEmkBgVpUNrQAA3fyUA= Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Other things Jim requested offline: - Point to PKIXALG as opposed to CMSALG, which makes sense since this is the CERT ID. - Add back in changes from v3 to v3.1, which also makes sense because the section should not have been removed. spt >-----Original Message----- >From: Jim Schaad [mailto:ietf@augustcellars.com] >Sent: Monday, July 28, 2008 2:43 PM >To: Sean P. Turner; 'Blake Ramsdell' >Cc: ietf-smime@imc.org >Subject: RE: I-D ACTION:draft-ietf-smime-3850bis-04.txt > >Comments on the draft. > >In section 4.4.3, I find the following text confusing: > >End-entity certificates contain an extension that > constrains the certificate from being an issuing authority > certificate (see Section 4.4.2). > > >I believe that this text might be better as it clarifies what >is being stated. I.e. it is not the fact that basic >constraints is being used which actually does the mentioned constraint. > > >End-entity certificates contain the Key Usage extension which >restraints the end-entity from using the key to perform >issuing authority operations (see >4.4.4) > >Also the previous comment (on 3851bis) on key sizes > 4096 >should be applied to this document > >jim > >> -----Original Message----- >> From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf- >> smime@mail.imc.org] On Behalf Of Internet-Drafts@ietf.org >> Sent: Tuesday, July 01, 2008 1:30 AM >> To: i-d-announce@ietf.org >> Cc: ietf-smime@imc.org >> Subject: I-D ACTION:draft-ietf-smime-3850bis-04.txt >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the S/MIME Mail Security >Working Group of >> the IETF. >> >> Title : Secure/Multipurpose Internet Mail Extensions >> (S/MIME) Version 3.2 Certificate Handling >> Author(s) : S. Turner, B. Ramsdell >> Filename : draft-ietf-smime-3850bis-04.txt >> Pages : 20 >> Date : 2008-6-30 >> >> This document specifies conventions for X.509 certificate usage by >> Secure/Multipurpose Internet Mail Extensions (S/MIME) agents. >> S/MIME >> provides a method to send and receive secure MIME messages, and >> certificates are an integral part of S/MIME agent processing. >> S/MIME agents validate certificates as described in RFC 3280bis, the >> Internet X.509 Public Key Infrastructure Certificate and CRL >> Profile. >> S/MIME agents must meet the certificate processing requirements in >> this document as well as those in RFC 3280bis. This document >> obsoletes RFC 3850. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-smime-3850bis-04.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. > From owner-ietf-smime@mail.imc.org Thu Jul 31 06:00:30 2008 Return-Path: X-Original-To: ietfarch-smime-archive@core3.amsl.com Delivered-To: ietfarch-smime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D23F3A6AF1 for ; Thu, 31 Jul 2008 06:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.365 X-Spam-Level: X-Spam-Status: No, score=-2.365 tagged_above=-999 required=5 tests=[AWL=-0.319, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y6BvsVBM7zcl for ; Thu, 31 Jul 2008 06:00:29 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 81EAE3A6806 for ; Thu, 31 Jul 2008 06:00:29 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6VCaA8g090218 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 31 Jul 2008 05:36:10 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6VCaAMr090217; Thu, 31 Jul 2008 05:36:10 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp100.biz.mail.mud.yahoo.com (smtp100.biz.mail.mud.yahoo.com [68.142.201.176]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m6VCa8Fw090210 for ; Thu, 31 Jul 2008 05:36:09 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 50885 invoked from network); 31 Jul 2008 12:36:07 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@130.129.22.148 with login) by smtp100.biz.mail.mud.yahoo.com with SMTP; 31 Jul 2008 12:36:07 -0000 X-YMail-OSG: H71gMp0VM1m2iv_PXWk8poqFVmoPQ9Gxso2Pf1_t2QL8PcjiHs7Tts3dgnuVCfjrmDyI1GF7n9lIx0avxvCHiqVUWq1yAYeQSEaBwE5H_A-- X-Yahoo-Newman-Property: ymail-3 From: "Turner, Sean P." To: , Subject: S/MIME WG Summary Date: Thu, 31 Jul 2008 13:35:58 +0100 Organization: IECA, Inc. Message-ID: <6003710576B042DD9C41C66BFF108F35@Wylie> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 Thread-Index: AcjzCfvUXX4USg3MQYG42vCo2+i7Ig== Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The S/MIME WG did not meeting in Dublin but it's still an active WG. Here's what's happening: - The CMS Symmetric Key Management and Distribution RFC was published as an RFC after 5+ years in the RFC editor queue! - The Multiple Signatures in S/MIME ID made its way to the RFC editor. - An IETF LC was issued for the RSA-KEM ID and comments were received through the GENART and SECDIR review process. Resolution of the comments doesn't seem to be difficult. - The SHA2 Algs with CMS ID is with the AD. - A solution to the discuss comment from the IESG on the IBE CMS draft has been accepted. The IBE architecture ID will be updated shortly and both will the handed to the AD for new IETF LC (information track). The AD felt the new LC was required because of change in the IPR statement. - Three versions of both S/MIME MSG and S/MIME CERT were published. Text being tweaked relates to algorithm choices, key sizes, S/MIME v2 to Historic status, updating media types registrations, and security considerations. - Two more versions of the RFC3278Update were produced before the document was converted to a 3279bis and then two more versions were produced. Thanks to Alfred Hoenes for his timely and thorough reviews. The remaining issue with this ID is to align the '02 ASN.1 module with the syntax specified in the New ASN.1 for CMS and S/MIME ID. - One version of the New ASN.1 for CMS and S/MIME ID was published. The issues that need to be addressed are similar to those facing the New ASN.1 for PKIX ID. See Jim's slides from the PKIX session for more information. Note review is requested! Cheers, spt From owner-ietf-smime@mail.imc.org Thu Jul 31 09:06:06 2008 Return-Path: X-Original-To: ietfarch-smime-archive@core3.amsl.com Delivered-To: ietfarch-smime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BE7C3A6895 for ; Thu, 31 Jul 2008 09:06:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BSil-FyWMBuG for ; Thu, 31 Jul 2008 09:06:05 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 00E0228C170 for ; Thu, 31 Jul 2008 09:06:04 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6VFhvec003901 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 31 Jul 2008 08:43:57 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6VFhvDK003900; Thu, 31 Jul 2008 08:43:57 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6VFhu6b003893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 31 Jul 2008 08:43:57 -0700 (MST) (envelope-from ietf@augustcellars.com) Received: from GALATIONS (unknown [130.129.20.100]) by smtp2.pacifier.net (Postfix) with ESMTP id 39F666A73C; Thu, 31 Jul 2008 08:43:53 -0700 (PDT) From: "Jim Schaad" To: "'Turner, Sean P.'" , "'Blake Ramsdell'" Cc: References: <20080701171501.66C9E3A6B99@core3.amsl.com> <01e001c8f0b4$4182f4a0$c488dde0$@com> <985966520807280943s333484b1x957c9839e89fc0a6@mail.gmail.com> In-Reply-To: Subject: RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt Date: Thu, 31 Jul 2008 16:43:54 +0100 Message-ID: <043f01c8f324$3e1d50e0$ba57f2a0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acjw0Rrj9TzUe2EqRouKeoEjA97+YQACWN1wAJJmBfA= Content-language: en-us Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sean, I really feel that we need to have two MUST signature algorithms for safety. When ECC signatures where present that was fine. Without having the ECC signature algorithms we really must have one of the DSA algorithms as a must > -----Original Message----- > From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf- > smime@mail.imc.org] On Behalf Of Turner, Sean P. > Sent: Monday, July 28, 2008 6:53 PM > To: 'Blake Ramsdell'; 'Jim Schaad' > Cc: ietf-smime@imc.org > Subject: RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt > > > >-----Original Message----- > >From: Blake Ramsdell [mailto:blaker@gmail.com] > > > >On Mon, Jul 28, 2008 at 6:17 AM, Jim Schaad > > wrote: > >> 1. We are not currently making any support statements for DSA w/ > the > >> SHA-256 hash algorithms. Should we be doing so? > > > >Unless it's a SHOULD+, no. > > I asked at least once if anybody wanted it and there was no response. > I > think unless somebody actually says "yes I want it" we ought to leave > it > out. > > >> This would finish the table entry out and also reference the > >> discussion on why very large keys are not recommended. It > >is possible > >> that MAY NOT is not currently valid 2119 language. In this case I > >> would be happy with ether MAY or SHOULD NOT. I would not be > >happy with MUST NOT. > > > >MAY or SHOULD NOT it is. I would lean towards MAY. > > I was leaning towards MAY, but maybe SHOULD NOT is better since the NOT > provides more information on which way we're leaning. What do others > think? > > spt Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6VFhvec003901 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 31 Jul 2008 08:43:57 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6VFhvDK003900; Thu, 31 Jul 2008 08:43:57 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6VFhu6b003893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 31 Jul 2008 08:43:57 -0700 (MST) (envelope-from ietf@augustcellars.com) Received: from GALATIONS (unknown [130.129.20.100]) by smtp2.pacifier.net (Postfix) with ESMTP id 39F666A73C; Thu, 31 Jul 2008 08:43:53 -0700 (PDT) From: "Jim Schaad" To: "'Turner, Sean P.'" , "'Blake Ramsdell'" Cc: References: <20080701171501.66C9E3A6B99@core3.amsl.com> <01e001c8f0b4$4182f4a0$c488dde0$@com> <985966520807280943s333484b1x957c9839e89fc0a6@mail.gmail.com> In-Reply-To: Subject: RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt Date: Thu, 31 Jul 2008 16:43:54 +0100 Message-ID: <043f01c8f324$3e1d50e0$ba57f2a0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acjw0Rrj9TzUe2EqRouKeoEjA97+YQACWN1wAJJmBfA= Content-language: en-us Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sean, I really feel that we need to have two MUST signature algorithms for safety. When ECC signatures where present that was fine. Without having the ECC signature algorithms we really must have one of the DSA algorithms as a must > -----Original Message----- > From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf- > smime@mail.imc.org] On Behalf Of Turner, Sean P. > Sent: Monday, July 28, 2008 6:53 PM > To: 'Blake Ramsdell'; 'Jim Schaad' > Cc: ietf-smime@imc.org > Subject: RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt > > > >-----Original Message----- > >From: Blake Ramsdell [mailto:blaker@gmail.com] > > > >On Mon, Jul 28, 2008 at 6:17 AM, Jim Schaad > > wrote: > >> 1. We are not currently making any support statements for DSA w/ > the > >> SHA-256 hash algorithms. Should we be doing so? > > > >Unless it's a SHOULD+, no. > > I asked at least once if anybody wanted it and there was no response. > I > think unless somebody actually says "yes I want it" we ought to leave > it > out. > > >> This would finish the table entry out and also reference the > >> discussion on why very large keys are not recommended. It > >is possible > >> that MAY NOT is not currently valid 2119 language. In this case I > >> would be happy with ether MAY or SHOULD NOT. I would not be > >happy with MUST NOT. > > > >MAY or SHOULD NOT it is. I would lean towards MAY. > > I was leaning towards MAY, but maybe SHOULD NOT is better since the NOT > provides more information on which way we're leaning. What do others > think? > > spt Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6VCaA8g090218 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 31 Jul 2008 05:36:10 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6VCaAMr090217; Thu, 31 Jul 2008 05:36:10 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp100.biz.mail.mud.yahoo.com (smtp100.biz.mail.mud.yahoo.com [68.142.201.176]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m6VCa8Fw090210 for ; Thu, 31 Jul 2008 05:36:09 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 50885 invoked from network); 31 Jul 2008 12:36:07 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@130.129.22.148 with login) by smtp100.biz.mail.mud.yahoo.com with SMTP; 31 Jul 2008 12:36:07 -0000 X-YMail-OSG: H71gMp0VM1m2iv_PXWk8poqFVmoPQ9Gxso2Pf1_t2QL8PcjiHs7Tts3dgnuVCfjrmDyI1GF7n9lIx0avxvCHiqVUWq1yAYeQSEaBwE5H_A-- X-Yahoo-Newman-Property: ymail-3 From: "Turner, Sean P." To: , Subject: S/MIME WG Summary Date: Thu, 31 Jul 2008 13:35:58 +0100 Organization: IECA, Inc. Message-ID: <6003710576B042DD9C41C66BFF108F35@Wylie> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 Thread-Index: AcjzCfvUXX4USg3MQYG42vCo2+i7Ig== Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The S/MIME WG did not meeting in Dublin but it's still an active WG. Here's what's happening: - The CMS Symmetric Key Management and Distribution RFC was published as an RFC after 5+ years in the RFC editor queue! - The Multiple Signatures in S/MIME ID made its way to the RFC editor. - An IETF LC was issued for the RSA-KEM ID and comments were received through the GENART and SECDIR review process. Resolution of the comments doesn't seem to be difficult. - The SHA2 Algs with CMS ID is with the AD. - A solution to the discuss comment from the IESG on the IBE CMS draft has been accepted. The IBE architecture ID will be updated shortly and both will the handed to the AD for new IETF LC (information track). The AD felt the new LC was required because of change in the IPR statement. - Three versions of both S/MIME MSG and S/MIME CERT were published. Text being tweaked relates to algorithm choices, key sizes, S/MIME v2 to Historic status, updating media types registrations, and security considerations. - Two more versions of the RFC3278Update were produced before the document was converted to a 3279bis and then two more versions were produced. Thanks to Alfred Hoenes for his timely and thorough reviews. The remaining issue with this ID is to align the '02 ASN.1 module with the syntax specified in the New ASN.1 for CMS and S/MIME ID. - One version of the New ASN.1 for CMS and S/MIME ID was published. The issues that need to be addressed are similar to those facing the New ASN.1 for PKIX ID. See Jim's slides from the PKIX session for more information. Note review is requested! Cheers, spt Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6SKIepe096776 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Jul 2008 13:18:40 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6SKIei6096775; Mon, 28 Jul 2008 13:18:40 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp104.biz.mail.re2.yahoo.com (smtp104.biz.mail.re2.yahoo.com [206.190.52.173]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m6SKIWWg096759 for ; Mon, 28 Jul 2008 13:18:38 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 5544 invoked from network); 28 Jul 2008 20:18:31 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@130.129.22.148 with login) by smtp104.biz.mail.re2.yahoo.com with SMTP; 28 Jul 2008 20:18:31 -0000 X-YMail-OSG: .jrSh3oVM1lTSxZBmpMUTJyQVrV5wkm3KJwYUXYCMJXUgF5af7HrR_oBUXNE5SyQdfK1qeKAmqBZRNt._otIjSK3lTvmSIZbh8jMM.KtyQ.e6quXmNPj2occG4WapG3tHcC2tMXeJPrK7rbWjYEUbT13 X-Yahoo-Newman-Property: ymail-3 From: "Turner, Sean P." To: References: <20080701003001.D4EE13A6B29@core3.amsl.com> <01e701c8f0b7$db2d7550$91885ff0$@com> Subject: RE: I-D ACTION:draft-ietf-smime-3850bis-04.txt Date: Mon, 28 Jul 2008 21:18:29 +0100 Organization: IECA, Inc. Message-ID: <31B9D22ECA884473981B83F00F05ECA5@Wylie> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 In-Reply-To: <01e701c8f0b7$db2d7550$91885ff0$@com> thread-index: AcjbEh1yJ7+xsRIzTQOZzEodyEmkBgVpUNrQAA3fyUA= Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Other things Jim requested offline: - Point to PKIXALG as opposed to CMSALG, which makes sense since this is the CERT ID. - Add back in changes from v3 to v3.1, which also makes sense because the section should not have been removed. spt >-----Original Message----- >From: Jim Schaad [mailto:ietf@augustcellars.com] >Sent: Monday, July 28, 2008 2:43 PM >To: Sean P. Turner; 'Blake Ramsdell' >Cc: ietf-smime@imc.org >Subject: RE: I-D ACTION:draft-ietf-smime-3850bis-04.txt > >Comments on the draft. > >In section 4.4.3, I find the following text confusing: > >End-entity certificates contain an extension that > constrains the certificate from being an issuing authority > certificate (see Section 4.4.2). > > >I believe that this text might be better as it clarifies what >is being stated. I.e. it is not the fact that basic >constraints is being used which actually does the mentioned constraint. > > >End-entity certificates contain the Key Usage extension which >restraints the end-entity from using the key to perform >issuing authority operations (see >4.4.4) > >Also the previous comment (on 3851bis) on key sizes > 4096 >should be applied to this document > >jim > >> -----Original Message----- >> From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf- >> smime@mail.imc.org] On Behalf Of Internet-Drafts@ietf.org >> Sent: Tuesday, July 01, 2008 1:30 AM >> To: i-d-announce@ietf.org >> Cc: ietf-smime@imc.org >> Subject: I-D ACTION:draft-ietf-smime-3850bis-04.txt >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the S/MIME Mail Security >Working Group of >> the IETF. >> >> Title : Secure/Multipurpose Internet Mail Extensions >> (S/MIME) Version 3.2 Certificate Handling >> Author(s) : S. Turner, B. Ramsdell >> Filename : draft-ietf-smime-3850bis-04.txt >> Pages : 20 >> Date : 2008-6-30 >> >> This document specifies conventions for X.509 certificate usage by >> Secure/Multipurpose Internet Mail Extensions (S/MIME) agents. >> S/MIME >> provides a method to send and receive secure MIME messages, and >> certificates are an integral part of S/MIME agent processing. >> S/MIME agents validate certificates as described in RFC 3280bis, the >> Internet X.509 Public Key Infrastructure Certificate and CRL >> Profile. >> S/MIME agents must meet the certificate processing requirements in >> this document as well as those in RFC 3280bis. This document >> obsoletes RFC 3850. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-smime-3850bis-04.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6SHr6tc083274 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Jul 2008 10:53:06 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6SHr6BV083273; Mon, 28 Jul 2008 10:53:06 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp110.biz.mail.re2.yahoo.com (smtp110.biz.mail.re2.yahoo.com [206.190.53.9]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m6SHr5xj083266 for ; Mon, 28 Jul 2008 10:53:05 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 46941 invoked from network); 28 Jul 2008 17:53:04 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@130.129.22.148 with login) by smtp110.biz.mail.re2.yahoo.com with SMTP; 28 Jul 2008 17:53:04 -0000 X-YMail-OSG: 0i8oW74VM1mdz3ZzIZPyKeSDSHWow_F1bM_3RuHKIMYUL4jKkH59f1UrsP1s0nQI3QS4KkAqTzWW6_9r80rmYRuoXJCa1HEtjSB9q6dFsg-- X-Yahoo-Newman-Property: ymail-3 From: "Turner, Sean P." To: "'Blake Ramsdell'" , "'Jim Schaad'" Cc: References: <20080701171501.66C9E3A6B99@core3.amsl.com> <01e001c8f0b4$4182f4a0$c488dde0$@com> <985966520807280943s333484b1x957c9839e89fc0a6@mail.gmail.com> Subject: RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt Date: Mon, 28 Jul 2008 18:53:03 +0100 Organization: IECA, Inc. Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 In-Reply-To: <985966520807280943s333484b1x957c9839e89fc0a6@mail.gmail.com> thread-index: Acjw0Rrj9TzUe2EqRouKeoEjA97+YQACWN1w Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >-----Original Message----- >From: Blake Ramsdell [mailto:blaker@gmail.com] > >On Mon, Jul 28, 2008 at 6:17 AM, Jim Schaad > wrote: >> 1. We are not currently making any support statements for DSA w/ the >> SHA-256 hash algorithms. Should we be doing so? > >Unless it's a SHOULD+, no. I asked at least once if anybody wanted it and there was no response. I think unless somebody actually says "yes I want it" we ought to leave it out. >> This would finish the table entry out and also reference the >> discussion on why very large keys are not recommended. It >is possible >> that MAY NOT is not currently valid 2119 language. In this case I >> would be happy with ether MAY or SHOULD NOT. I would not be >happy with MUST NOT. > >MAY or SHOULD NOT it is. I would lean towards MAY. I was leaning towards MAY, but maybe SHOULD NOT is better since the NOT provides more information on which way we're leaning. What do others think? spt Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6SF5KYr068401 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Jul 2008 08:05:20 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6SF5KlS068400; Mon, 28 Jul 2008 08:05:20 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6SF5Hek068394 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 28 Jul 2008 08:05:18 -0700 (MST) (envelope-from ietf@augustcellars.com) Received: from GALATIONS (unknown [130.129.20.100]) by smtp1.pacifier.net (Postfix) with ESMTP id 2D1CB6EFB7; Mon, 28 Jul 2008 08:05:15 -0700 (PDT) From: "Jim Schaad" To: "'Jim Schaad'" , "'Sean P. Turner'" , "'Blake Ramsdell'" Cc: References: <20080701003001.D4EE13A6B29@core3.amsl.com> <01e701c8f0b7$db2d7550$91885ff0$@com> In-Reply-To: <01e701c8f0b7$db2d7550$91885ff0$@com> Subject: RE: I-D ACTION:draft-ietf-smime-3850bis-04.txt Date: Mon, 28 Jul 2008 16:05:16 +0100 Message-ID: <021201c8f0c3$59240180$0b6c0480$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcjbEh1yJ7+xsRIzTQOZzEodyEmkBgVpUNrQAAL4pxA= Content-Language: en-us Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I got some section numbers wrong in typing. The text in question is in section 4.4.1, The reference in the new text should still be to section 4.4.2 Jim > -----Original Message----- > From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf- > smime@mail.imc.org] On Behalf Of Jim Schaad > Sent: Monday, July 28, 2008 2:43 PM > To: Sean P. Turner; 'Blake Ramsdell' > Cc: ietf-smime@imc.org > Subject: RE: I-D ACTION:draft-ietf-smime-3850bis-04.txt > > > Comments on the draft. > > In section 4.4.3, I find the following text confusing: > > End-entity certificates contain an extension that > constrains the certificate from being an issuing authority > certificate (see Section 4.4.2). > > > I believe that this text might be better as it clarifies what is being > stated. I.e. it is not the fact that basic constraints is being used > which > actually does the mentioned constraint. > > > End-entity certificates contain the Key Usage extension which > restraints the > end-entity from using the key to perform issuing authority operations > (see > 4.4.4) > > Also the previous comment (on 3851bis) on key sizes > 4096 should be > applied > to this document > > jim > > > -----Original Message----- > > From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf- > > smime@mail.imc.org] On Behalf Of Internet-Drafts@ietf.org > > Sent: Tuesday, July 01, 2008 1:30 AM > > To: i-d-announce@ietf.org > > Cc: ietf-smime@imc.org > > Subject: I-D ACTION:draft-ietf-smime-3850bis-04.txt > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the S/MIME Mail Security Working Group > of > > the IETF. > > > > Title : Secure/Multipurpose Internet Mail Extensions > > (S/MIME) Version 3.2 Certificate Handling > > Author(s) : S. Turner, B. Ramsdell > > Filename : draft-ietf-smime-3850bis-04.txt > > Pages : 20 > > Date : 2008-6-30 > > > > This document specifies conventions for X.509 certificate usage by > > Secure/Multipurpose Internet Mail Extensions (S/MIME) agents. > > S/MIME > > provides a method to send and receive secure MIME messages, and > > certificates are an integral part of S/MIME agent processing. > > S/MIME agents validate certificates as described in RFC 3280bis, the > > Internet X.509 Public Key Infrastructure Certificate and CRL > > Profile. > > S/MIME agents must meet the certificate processing requirements in > > this document as well as those in RFC 3280bis. This document > > obsoletes RFC 3850. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-smime-3850bis-04.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6SDh4eu060518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Jul 2008 06:43:04 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6SDh4Kx060517; Mon, 28 Jul 2008 06:43:04 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6SDh2T6060509 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 28 Jul 2008 06:43:03 -0700 (MST) (envelope-from ietf@augustcellars.com) Received: from GALATIONS (unknown [130.129.20.100]) by smtp2.pacifier.net (Postfix) with ESMTP id 8E13F6A4C2; Mon, 28 Jul 2008 06:43:00 -0700 (PDT) From: "Jim Schaad" To: "Sean P. Turner" , "'Blake Ramsdell'" Cc: References: <20080701003001.D4EE13A6B29@core3.amsl.com> In-Reply-To: <20080701003001.D4EE13A6B29@core3.amsl.com> Subject: RE: I-D ACTION:draft-ietf-smime-3850bis-04.txt Date: Mon, 28 Jul 2008 14:43:00 +0100 Message-ID: <01e701c8f0b7$db2d7550$91885ff0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcjbEh1yJ7+xsRIzTQOZzEodyEmkBgVpUNrQ Content-Language: en-us Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Comments on the draft. In section 4.4.3, I find the following text confusing: End-entity certificates contain an extension that constrains the certificate from being an issuing authority certificate (see Section 4.4.2). I believe that this text might be better as it clarifies what is being stated. I.e. it is not the fact that basic constraints is being used which actually does the mentioned constraint. End-entity certificates contain the Key Usage extension which restraints the end-entity from using the key to perform issuing authority operations (see 4.4.4) Also the previous comment (on 3851bis) on key sizes > 4096 should be applied to this document jim > -----Original Message----- > From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf- > smime@mail.imc.org] On Behalf Of Internet-Drafts@ietf.org > Sent: Tuesday, July 01, 2008 1:30 AM > To: i-d-announce@ietf.org > Cc: ietf-smime@imc.org > Subject: I-D ACTION:draft-ietf-smime-3850bis-04.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the S/MIME Mail Security Working Group of > the IETF. > > Title : Secure/Multipurpose Internet Mail Extensions > (S/MIME) Version 3.2 Certificate Handling > Author(s) : S. Turner, B. Ramsdell > Filename : draft-ietf-smime-3850bis-04.txt > Pages : 20 > Date : 2008-6-30 > > This document specifies conventions for X.509 certificate usage by > Secure/Multipurpose Internet Mail Extensions (S/MIME) agents. > S/MIME > provides a method to send and receive secure MIME messages, and > certificates are an integral part of S/MIME agent processing. > S/MIME agents validate certificates as described in RFC 3280bis, the > Internet X.509 Public Key Infrastructure Certificate and CRL > Profile. > S/MIME agents must meet the certificate processing requirements in > this document as well as those in RFC 3280bis. This document > obsoletes RFC 3850. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-smime-3850bis-04.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6SDHHa5057872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Jul 2008 06:17:17 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6SDHHxU057871; Mon, 28 Jul 2008 06:17:17 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.173]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6SDHFUY057858 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 28 Jul 2008 06:17:17 -0700 (MST) (envelope-from ietf@augustcellars.com) Received: from GALATIONS (unknown [130.129.20.100]) by smtp3.pacifier.net (Postfix) with ESMTP id 2FCE681BF; Mon, 28 Jul 2008 06:17:13 -0700 (PDT) From: "Jim Schaad" To: "Sean P. Turner" , "'Blake Ramsdell'" Cc: References: <20080701171501.66C9E3A6B99@core3.amsl.com> In-Reply-To: <20080701171501.66C9E3A6B99@core3.amsl.com> Subject: RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt Date: Mon, 28 Jul 2008 14:17:14 +0100 Message-ID: <01e001c8f0b4$4182f4a0$c488dde0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acjbnitts1iEbAHrTTCV7aLKFbnGpQVFZpBQ Content-Language: en-us Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Comments on the draft: 1. We are not currently making any support statements for DSA w/ the SHA-256 hash algorithms. Should we be doing so? 2. For key size support, key of L>1024 are not supported for DSA-SHA-1. 3. I would like to add the following text to the table. Key size > 4096 MAY NOT (See security considerations on large keys) This would finish the table entry out and also reference the discussion on why very large keys are not recommended. It is possible that MAY NOT is not currently valid 2119 language. In this case I would be happy with ether MAY or SHOULD NOT. I would not be happy with MUST NOT. Jim Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6EKQkeQ047988 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Jul 2008 13:26:46 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6EKQknF047987; Mon, 14 Jul 2008 13:26:46 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from relay8.mail.uk.clara.net (relay8.mail.uk.clara.net [80.168.70.188]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6EKQj2P047979 for ; Mon, 14 Jul 2008 13:26:46 -0700 (MST) (envelope-from lists@drh-consultancy.demon.co.uk) Received: from drh-consultancy.demon.co.uk ([80.177.30.10] helo=[192.168.7.8]) by relay8.mail.uk.clara.net with esmtpa (Exim 4.69) (envelope-from ) id 1KIUd0-0006KT-Aq; Mon, 14 Jul 2008 21:26:35 +0100 Message-ID: <487BB682.7070501@drh-consultancy.demon.co.uk> Date: Mon, 14 Jul 2008 21:26:42 +0100 From: Dr Stephen Henson User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Eric Rescorla CC: ietf-smime@imc.org, rjsparks@nostrum.com, fluffy@cisco.com Subject: Re: Algorithm Identifiers in sip-sec-flows References: <20080714181658.6DF78509A9@romeo.rtfm.com> <487B9CF0.4030204@drh-consultancy.demon.co.uk> <20080714185056.E9D1A509A9@romeo.rtfm.com> In-Reply-To: <20080714185056.E9D1A509A9@romeo.rtfm.com> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Clara-Relay: Message sent using Claranet Relay Service using auth code: drh Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Eric Rescorla wrote: > At Mon, 14 Jul 2008 19:37:36 +0100, > Dr Stephen Henson wrote: >> >> The very recently added CMS code omits the parameters for sha1 and sha2 >> algorithms and encodes them as NULL for others. > > Has this stuff been released yet? > The documentation and full functionality is present in the development version (which will be 0.9.9). A slightly less functional version has been backported to 0.9.8 and first appears in the 0.9.8h release. It has to be specifically enabled using "enable-cms" at configuration time. Though a 0.9.8h bug means it is advisable to use the latest 0.9.8-stable snapshot. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.co.uk/ Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6EImmN1035260 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Jul 2008 11:48:48 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6EImmIU035259; Mon, 14 Jul 2008 11:48:48 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from ladle.sendmail.com (ladle.sendmail.com [209.246.26.53]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6EImldF035236 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 14 Jul 2008 11:48:48 -0700 (MST) (envelope-from blake@sendmail.com) Received: from spork.sendmail.com (tls.sendmail.com [209.246.26.41]) by ladle.sendmail.com (Switch-3.3.1/Sentrion-3.0.0) with ESMTP id m6EIrCRu018168 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 14 Jul 2008 11:53:12 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sendmail.com; s=ladle.dkim; t=1216061592; bh=/PMjoLAcLP4a4O8ghjrnuNtGc6iCKJ1Jj+SE Tk29rls=; h=Received:X-DKIM:DKIM-Signature:Date:From:To:Cc:Subject: Message-ID:References:MIME-Version:Content-Type: Content-Disposition:In-Reply-To:User-Agent:X-MM-Ex-RefId; b=NECU9T ObwF6OJq60JcHcBb4gmq39IXtPYYmMSA1FtbTMDSl7BsCV1uqRbyGomSwAdtEaFdsEc enDWuXwwZlks6wlRJf5F3UTpcGXGlhP2Vy9tyelsb/68/pb2D+Bc/mLa/iXNktATNeK oXLKza5fWkiX11ZF00XPtqQxbhy85V0= Received: from dell-desktop.example.com (c-24-17-217-200.hsd1.mn.comcast.net [24.17.217.200]) (authenticated bits=0) by spork.sendmail.com (Switch-3.3.1/Switch-3.3.2mp) with ESMTP id m6EImM1A017019 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Jul 2008 11:48:27 -0700 X-DKIM: Sendmail DKIM Filter v2.2.3 spork.sendmail.com m6EImM1A017019 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sendmail.com; s=spork.dkim; t=1216061309; bh=/PMjoLAcLP4a4O8ghjrnuNtGc6iCKJ1Jj+SE Tk29rls=; h=Date:From:To:Cc:Subject:Message-ID:References: MIME-Version:Content-Type:Content-Disposition:In-Reply-To: User-Agent:X-MM-Ex-RefId; b=cD+i+IEqMGWbjyfl8XmJvFNGPrVygPhAJmW9Q9 KlHNgbMsOA7ylB4OwPRMaZzY6PyYzB/q4CIL59IwH3WzUW+JzC0DkKI78YC79gUCkyk XjgJxw/1a3dYcV9e0YBnluWqJGkBStrQSglp4JYB56G/lMQ7hp5bwtcMK896LgOXvE= Date: Mon, 14 Jul 2008 11:50:13 -0700 From: Blake Ramsdell To: Eric Rescorla Cc: ietf-smime@imc.org, rjsparks@nostrum.com, fluffy@cisco.com Subject: Re: Algorithm Identifiers in sip-sec-flows Message-ID: <20080714185013.GA26618@dell-desktop.example.com> References: <20080714181658.6DF78509A9@romeo.rtfm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080714181658.6DF78509A9@romeo.rtfm.com> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-MM-Ex-RefId: 149371::080714114828-542AFB90-2D34DD37/0-0/0-1 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, Jul 14, 2008 at 11:16:58AM -0700, Eric Rescorla wrote: > Implementations SHOULD generate SHA-1 > AlgorithmIdentifiers with absent parameters. ... > However, as far as I can tell OpenSSL currently generates the encoding > with NULL rather than absent, and my memory is that the last time I > discussed this with the OpenSSL implementors, they weren't interested > in changing this. > > When we were last working on this a few years ago, I got some message > from Fluffy saying that we should try to generate an encoding with > absent regardless. I spent some time patching OpenSSL to make it do > this, but upon reexamination, it seems kind of lame to have an example > in the draft that requires some one-off patch to generate, so I > thought it might be a good idea to get some more advice from the WG. > I'm not suggesting we change 3370, but is it really necessary to > have examples which need to be hand-tooled? >From RFC 2119: 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. I say that the OpenSSL implementation emitting NULL and the prevalence of that implementation constitutes a valid reason in a particular circumstance, and the full implication is understood (receiving implementations MUST support NULL). This email exchange constitutes careful weighing before choosing a different course. So emit NULL and feel bad about it. You might consider submitting the patch to OpenSSL anyway though. Blake Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6EIhoTC034876 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Jul 2008 11:43:50 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6EIhose034875; Mon, 14 Jul 2008 11:43:50 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6EIhmho034867 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 14 Jul 2008 11:43:49 -0700 (MST) (envelope-from ekr@networkresonance.com) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id E9D1A509A9; Mon, 14 Jul 2008 11:50:56 -0700 (PDT) Date: Mon, 14 Jul 2008 11:50:56 -0700 From: Eric Rescorla To: Dr Stephen Henson Cc: Eric Rescorla , ietf-smime@imc.org, rjsparks@nostrum.com, fluffy@cisco.com Subject: Re: Algorithm Identifiers in sip-sec-flows In-Reply-To: <487B9CF0.4030204@drh-consultancy.demon.co.uk> References: <20080714181658.6DF78509A9@romeo.rtfm.com> <487B9CF0.4030204@drh-consultancy.demon.co.uk> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20080714185056.E9D1A509A9@romeo.rtfm.com> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At Mon, 14 Jul 2008 19:37:36 +0100, Dr Stephen Henson wrote: > > Eric Rescorla wrote: > > Robert Sparks and I are trying to finish up draft-ietf-sip-sec-flows > > (http://tools.ietf.org/html/draft-ietf-sip-sec-flows-01), which > > contains SIP security exampled and one of the open issues is algorithm > > identifier encodings. > > > > Like most others, We're using OpenSSL to generate the messages, with > > RSA with SHA-1 for the signature algorithms. As people will recall, > > RFC 3370 has this to say about the algorithm identifiers: > > > > The SHA-1 message digest algorithm is defined in FIPS Pub 180-1 > > [SHA1]. The algorithm identifier for SHA-1 is: > > > > sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) > > oiw(14) secsig(3) algorithm(2) 26 } > > > > There are two possible encodings for the SHA-1 AlgorithmIdentifier > > parameters field. The two alternatives arise from the fact that when > > the 1988 syntax for AlgorithmIdentifier was translated into the 1997 > > syntax, the OPTIONAL associated with the AlgorithmIdentifier > > parameters got lost. Later the OPTIONAL was recovered via a defect > > report, but by then many people thought that algorithm parameters > > were mandatory. Because of this history some implementations encode > > parameters as a NULL element and others omit them entirely. The > > correct encoding is to omit the parameters field; however, > > implementations MUST also handle a SHA-1 AlgorithmIdentifier > > parameters field which contains a NULL. > > > > The AlgorithmIdentifier parameters field is OPTIONAL. If present, > > the parameters field MUST contain a NULL. Implementations MUST > > accept SHA-1 AlgorithmIdentifiers with absent parameters. > > Implementations MUST accept SHA-1 AlgorithmIdentifiers with NULL > > parameters. Implementations SHOULD generate SHA-1 > > AlgorithmIdentifiers with absent parameters. > > > > However, as far as I can tell OpenSSL currently generates the encoding > > with NULL rather than absent, and my memory is that the last time I > > discussed this with the OpenSSL implementors, they weren't interested > > in changing this. > > > > When we were last working on this a few years ago, I got some message > > from Fluffy saying that we should try to generate an encoding with > > absent regardless. I spent some time patching OpenSSL to make it do > > this, but upon reexamination, it seems kind of lame to have an example > > in the draft that requires some one-off patch to generate, so I > > thought it might be a good idea to get some more advice from the WG. > > I'm not suggesting we change 3370, but is it really necessary to > > have examples which need to be hand-tooled? > > > > At the time OpenSSL didn't support CMS only PKCS#7. > > There are a few separate cases which OpenSSL handles. > > The PKCS#1 DigestInfo structure includes NULL. As I recall this is a > specific exception partly to cover implementations that process > DigestInfo with a cut and paste operations. > > The PKCS#7 code includes NULL. I'd have to check my archives but I can > vaguely recall that a compatibility test OpenSSL was put through > required this. > > The very recently added CMS code omits the parameters for sha1 and sha2 > algorithms and encodes them as NULL for others. Has this stuff been released yet? Thanks, -Ekr Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6EIbmEP034493 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Jul 2008 11:37:48 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6EIbm7n034492; Mon, 14 Jul 2008 11:37:48 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from relay6.mail.uk.clara.net (relay6.mail.uk.clara.net [80.168.70.186]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6EIbkrE034485 for ; Mon, 14 Jul 2008 11:37:47 -0700 (MST) (envelope-from lists@drh-consultancy.demon.co.uk) Received: from drh-consultancy.demon.co.uk ([80.177.30.10] helo=[192.168.7.8]) by relay6.mail.uk.clara.net with esmtpa (Exim 4.69) (envelope-from ) id 1KISvQ-0002Mq-2U; Mon, 14 Jul 2008 19:37:30 +0100 Message-ID: <487B9CF0.4030204@drh-consultancy.demon.co.uk> Date: Mon, 14 Jul 2008 19:37:36 +0100 From: Dr Stephen Henson User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Eric Rescorla CC: ietf-smime@imc.org, rjsparks@nostrum.com, fluffy@cisco.com Subject: Re: Algorithm Identifiers in sip-sec-flows References: <20080714181658.6DF78509A9@romeo.rtfm.com> In-Reply-To: <20080714181658.6DF78509A9@romeo.rtfm.com> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Clara-Relay: Message sent using Claranet Relay Service using auth code: drh Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Eric Rescorla wrote: > Robert Sparks and I are trying to finish up draft-ietf-sip-sec-flows > (http://tools.ietf.org/html/draft-ietf-sip-sec-flows-01), which > contains SIP security exampled and one of the open issues is algorithm > identifier encodings. > > Like most others, We're using OpenSSL to generate the messages, with > RSA with SHA-1 for the signature algorithms. As people will recall, > RFC 3370 has this to say about the algorithm identifiers: > > The SHA-1 message digest algorithm is defined in FIPS Pub 180-1 > [SHA1]. The algorithm identifier for SHA-1 is: > > sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) > oiw(14) secsig(3) algorithm(2) 26 } > > There are two possible encodings for the SHA-1 AlgorithmIdentifier > parameters field. The two alternatives arise from the fact that when > the 1988 syntax for AlgorithmIdentifier was translated into the 1997 > syntax, the OPTIONAL associated with the AlgorithmIdentifier > parameters got lost. Later the OPTIONAL was recovered via a defect > report, but by then many people thought that algorithm parameters > were mandatory. Because of this history some implementations encode > parameters as a NULL element and others omit them entirely. The > correct encoding is to omit the parameters field; however, > implementations MUST also handle a SHA-1 AlgorithmIdentifier > parameters field which contains a NULL. > > The AlgorithmIdentifier parameters field is OPTIONAL. If present, > the parameters field MUST contain a NULL. Implementations MUST > accept SHA-1 AlgorithmIdentifiers with absent parameters. > Implementations MUST accept SHA-1 AlgorithmIdentifiers with NULL > parameters. Implementations SHOULD generate SHA-1 > AlgorithmIdentifiers with absent parameters. > > However, as far as I can tell OpenSSL currently generates the encoding > with NULL rather than absent, and my memory is that the last time I > discussed this with the OpenSSL implementors, they weren't interested > in changing this. > > When we were last working on this a few years ago, I got some message > from Fluffy saying that we should try to generate an encoding with > absent regardless. I spent some time patching OpenSSL to make it do > this, but upon reexamination, it seems kind of lame to have an example > in the draft that requires some one-off patch to generate, so I > thought it might be a good idea to get some more advice from the WG. > I'm not suggesting we change 3370, but is it really necessary to > have examples which need to be hand-tooled? > At the time OpenSSL didn't support CMS only PKCS#7. There are a few separate cases which OpenSSL handles. The PKCS#1 DigestInfo structure includes NULL. As I recall this is a specific exception partly to cover implementations that process DigestInfo with a cut and paste operations. The PKCS#7 code includes NULL. I'd have to check my archives but I can vaguely recall that a compatibility test OpenSSL was put through required this. The very recently added CMS code omits the parameters for sha1 and sha2 algorithms and encodes them as NULL for others. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.co.uk/ Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6EI9piu032186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Jul 2008 11:09:51 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6EI9peS032185; Mon, 14 Jul 2008 11:09:51 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6EI9o8l032179 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 14 Jul 2008 11:09:51 -0700 (MST) (envelope-from ekr@networkresonance.com) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 6DF78509A9; Mon, 14 Jul 2008 11:16:58 -0700 (PDT) Date: Mon, 14 Jul 2008 11:16:58 -0700 From: Eric Rescorla To: ietf-smime@imc.org Cc: rjsparks@nostrum.com, fluffy@cisco.com Subject: Algorithm Identifiers in sip-sec-flows User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20080714181658.6DF78509A9@romeo.rtfm.com> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Robert Sparks and I are trying to finish up draft-ietf-sip-sec-flows (http://tools.ietf.org/html/draft-ietf-sip-sec-flows-01), which contains SIP security exampled and one of the open issues is algorithm identifier encodings. Like most others, We're using OpenSSL to generate the messages, with RSA with SHA-1 for the signature algorithms. As people will recall, RFC 3370 has this to say about the algorithm identifiers: The SHA-1 message digest algorithm is defined in FIPS Pub 180-1 [SHA1]. The algorithm identifier for SHA-1 is: sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) oiw(14) secsig(3) algorithm(2) 26 } There are two possible encodings for the SHA-1 AlgorithmIdentifier parameters field. The two alternatives arise from the fact that when the 1988 syntax for AlgorithmIdentifier was translated into the 1997 syntax, the OPTIONAL associated with the AlgorithmIdentifier parameters got lost. Later the OPTIONAL was recovered via a defect report, but by then many people thought that algorithm parameters were mandatory. Because of this history some implementations encode parameters as a NULL element and others omit them entirely. The correct encoding is to omit the parameters field; however, implementations MUST also handle a SHA-1 AlgorithmIdentifier parameters field which contains a NULL. The AlgorithmIdentifier parameters field is OPTIONAL. If present, the parameters field MUST contain a NULL. Implementations MUST accept SHA-1 AlgorithmIdentifiers with absent parameters. Implementations MUST accept SHA-1 AlgorithmIdentifiers with NULL parameters. Implementations SHOULD generate SHA-1 AlgorithmIdentifiers with absent parameters. However, as far as I can tell OpenSSL currently generates the encoding with NULL rather than absent, and my memory is that the last time I discussed this with the OpenSSL implementors, they weren't interested in changing this. When we were last working on this a few years ago, I got some message from Fluffy saying that we should try to generate an encoding with absent regardless. I spent some time patching OpenSSL to make it do this, but upon reexamination, it seems kind of lame to have an example in the draft that requires some one-off patch to generate, so I thought it might be a good idea to get some more advice from the WG. I'm not suggesting we change 3370, but is it really necessary to have examples which need to be hand-tooled? -Ekr Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6BCqsbF018846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Jul 2008 05:52:54 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6BCqssq018845; Fri, 11 Jul 2008 05:52:54 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp105.biz.mail.re2.yahoo.com (smtp105.biz.mail.re2.yahoo.com [206.190.52.174]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m6BCqqYa018839 for ; Fri, 11 Jul 2008 05:52:53 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 85110 invoked from network); 11 Jul 2008 12:52:52 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@71.191.6.202 with login) by smtp105.biz.mail.re2.yahoo.com with SMTP; 11 Jul 2008 12:52:52 -0000 X-YMail-OSG: XL0vpWIVM1kkYM1scbqewb.ssyMI9OHYeH87pviJk0nAUxOdniX9g2.EirATwX5oVpHNlAHLoDmyZG7P.FLsgxXCwUK4F53t7WPSCix5iB6T8Gv_CQCONEVlIoTTL.yrEhay4p7pNH6fMCpEvw0hhOsj X-Yahoo-Newman-Property: ymail-3 From: "Turner, Sean P." To: References: <373A0D028EBE4F25A40803CA88D88D8E@Wylie> Subject: RE: I-D ACTION:draft-gennai-smime-cnipa-pec-00.txt Date: Fri, 11 Jul 2008 08:52:32 -0400 Organization: IECA, Inc. Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcjbAOiqtudPQIjWSrCr8UaW88UJ+gBgawnQAbR35AA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 In-Reply-To: <373A0D028EBE4F25A40803CA88D88D8E@Wylie> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Since the S/MIME WG is not meeting in Dublin, the authors of this ID have indicated to me that they would like to meet with anybody interested in discussing their ID. Contact either Francesco Gennai or Alba Shahin . spt >-----Original Message----- >From: owner-ietf-smime@mail.imc.org >[mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Turner, Sean P. >Sent: Wednesday, July 02, 2008 4:38 PM >To: ietf-smime@imc.org >Subject: FW: I-D ACTION:draft-gennai-smime-cnipa-pec-00.txt > >I'd like to draw attention to this ID. Alba and Francesco >described the PEC (Posta Elettronica Certificata) at IETF 71 >(https://www3.ietf.org/proceedings/08mar/slides/smime-4.pdf) >and this is the ID that provides a much more detailed >technical description of PEC. Many at the meeting indicated >they were willing to review - so please do and provide >comments to the authors. > >spt > >-----Original Message----- >From: i-d-announce-bounces@ietf.org >[mailto:i-d-announce-bounces@ietf.org] >On Behalf Of Internet-Drafts@ietf.org >Sent: Monday, June 30, 2008 6:30 PM >To: i-d-announce@ietf.org >Subject: I-D ACTION:draft-gennai-smime-cnipa-pec-00.txt > >A New Internet-Draft is available from the on-line >Internet-Drafts directories. > > > Title : Certified Electronic Mail > Author(s) : F. Gennai, A. Shahin, C. Petrucci, A. >Vinciarelli > Filename : draft-gennai-smime-cnipa-pec-00.txt > Pages : 62 > Date : 2008-6-30 > >Since 1997, the Italian Laws have recognized electronic delivery > systems as legally usable. After 2 years of technical tests, in > 2005 the characteristics of an official electronic delivery > service, named certified electronic mail (in Italian "Posta > Elettronica Certificata") were defined, giving the system legal > value. > > Design of the entire system was carried out by the National > Center for Informatics in the Public Administration of Italy > (CNIPA), followed by efforts for the implementation and testing > of the service. The CNIPA has given the Italian National > Research Council (CNR), and in particular The Institute of > Information Science and Technologies at the CNR (ISTI), the task > to run tests on providers of the service to guarantee the > correct implementation and interoperability.This document > describes the certified email system adopted in Italy. It > represents the system as it is at the moment of writing, > following the technical regulations that were written based upon > the Italian Law DPR. November 2, 2005. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-gennai-smime-cnipa-pec-00.txt > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >Below is the data which will enable a MIME compliant mail >reader implementation to automatically retrieve the ASCII >version of the Internet-Draft. > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6AHFI1g011006 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Jul 2008 10:15:19 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6AHFIvH011005; Thu, 10 Jul 2008 10:15:18 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6AHFHjE010991 for ; Thu, 10 Jul 2008 10:15:18 -0700 (MST) (envelope-from root@core3.amsl.com) Received: by core3.amsl.com (Postfix, from userid 0) id 9BC4A3A67A3; Thu, 10 Jul 2008 10:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ietf-smime@imc.org Subject: I-D Action:draft-ietf-smime-new-asn1-01.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080710171501.9BC4A3A67A3@core3.amsl.com> Date: Thu, 10 Jul 2008 10:15:01 -0700 (PDT) Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : New ASN.1 Modules for CMS and S/MIME Author(s) : P. Hoffman, J. Schaad Filename : draft-ietf-smime-new-asn1-01.txt Pages : 56 Date : 2008-07-10 The Cryptographic Message Syntax (CMS) format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates those ASN.1 modules to conform to the 2002 version of ASN.1. There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-new-asn1-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-smime-new-asn1-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-07-10100238.I-D@ietf.org> --NextPart-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m69K9pOs095980 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Jul 2008 13:09:52 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m69K9pjU095979; Wed, 9 Jul 2008 13:09:51 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp100.biz.mail.re2.yahoo.com (smtp100.biz.mail.re2.yahoo.com [206.190.52.46]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m69K9nGT095972 for ; Wed, 9 Jul 2008 13:09:50 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 30503 invoked from network); 9 Jul 2008 20:09:44 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@96.231.129.42 with login) by smtp100.biz.mail.re2.yahoo.com with SMTP; 9 Jul 2008 20:09:44 -0000 X-YMail-OSG: CY5b7_wVM1mT.1kQARRcloXGko2BieKngh5OtfUJ6BYtgctuM8FebyDj1RNLtn.Gf.oZFcEwIvrWk2unJaIxatPYAVrIP1eqf9F_FYf8Demsaqd0TWtuXfNwi7KflAAw7_s7.I9qIt5AM3ffb7gu6V8a X-Yahoo-Newman-Property: ymail-3 From: "Turner, Sean P." To: Subject: IPR # 896 Date: Wed, 9 Jul 2008 16:09:33 -0400 Organization: IECA, Inc. Message-ID: <5B921CCBFBCB4E22A0642B7801065209@Wylie> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0152_01C8E1DE.2D2B7070" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 Thread-Index: Acjh/7PFyVzYaDBISmy6/Dp/xjzYww== Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0152_01C8E1DE.2D2B7070 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit FYI https://datatracker.ietf.org/ipr/896/ ------=_NextPart_000_0152_01C8E1DE.2D2B7070 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable IPR # 896

FYI

https://datatracker.ietf.org/ipr/896/

------=_NextPart_000_0152_01C8E1DE.2D2B7070-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m644t1Em092577 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Jul 2008 21:55:01 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m644t18T092576; Thu, 3 Jul 2008 21:55:01 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from mailhost.auckland.ac.nz (moe.its.auckland.ac.nz [130.216.12.35]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m644sxXa092549 for ; Thu, 3 Jul 2008 21:54:59 -0700 (MST) (envelope-from pgut001@cs.auckland.ac.nz) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 7C821480DC9; Fri, 4 Jul 2008 16:54:57 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SBf4XQSOxruD; Fri, 4 Jul 2008 16:54:57 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 33520480DAA; Fri, 4 Jul 2008 16:54:55 +1200 (NZST) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 46A3C19EC0BA; Fri, 4 Jul 2008 16:54:54 +1200 (NZST) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1KEdJu-00041v-4x; Fri, 04 Jul 2008 16:54:54 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-smime@imc.org, spv@CryptoPro.ru, yasir.khan@ascertia.com Subject: RE: Using Signature Policy in RFC-5126 In-Reply-To: <003c01c8dd8e$f5a11bd0$e0e35370$@ru> Message-Id: Date: Fri, 04 Jul 2008 16:54:54 +1200 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Pavel V. Smirnov" writes: >Julien mentioned a point considered in Note 3: "Unless DER is used >throughout, it is recommended that the binary encoding of the ASN.1 >structures being time-stamped be preserved when being archived to ensure >that the recalculation of the data hash is consistent". Oh, I'm surprised this isn't the default for everything - are implementors really trying to decode and re-encode data and expecting the signature to still validate? Doing this violates the primary enoding rule, "There is only one (re-)encoding mechanism and memcpy() is its name". Peter. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m644WZfn091228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Jul 2008 21:32:35 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m644WZfI091227; Thu, 3 Jul 2008 21:32:35 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from mx4.cryptopro.ru (mx4.cryptopro.ru [89.221.56.34]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m644WVgV091218 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 3 Jul 2008 21:32:33 -0700 (MST) (envelope-from spv@cryptopro.ru) Received: from mx4.cryptopro.ru (192.168.68.5) by jake.cp.ru (192.168.68.8) with Microsoft SMTP Server id 8.1.263.0; Fri, 4 Jul 2008 08:32:25 +0400 Received: from smirnovxp64 ([192.168.68.187] RDNS failed) by mx4.cryptopro.ru with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Jul 2008 08:32:25 +0400 From: "Pavel V. Smirnov" To: "'Yasir Khan'" , References: <002c01c8d763$2c6d3db0$8547b910$@ru> In-Reply-To: Subject: RE: Using Signature Policy in RFC-5126 Date: Fri, 4 Jul 2008 08:32:23 +0400 Message-ID: <003c01c8dd8e$f5a11bd0$e0e35370$@ru> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003D_01C8DDB0.7CB2BBD0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcjWsEVkUJ9OGEWeQRKpgqvSmd/z7AAAX7AgACx4USAAAKjZYAFv/YPAABlXEyA= Content-Language: ru X-OriginalArrivalTime: 04 Jul 2008 04:32:25.0500 (UTC) FILETIME=[F58FDDC0:01C8DD8E] Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ------=_NextPart_000_003D_01C8DDB0.7CB2BBD0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable There are a couple of notes regarding archive timestamp that could help = you. =20 Note 4 says: "The hash is calculated over the concatenated data elements = as received/stored, including the Type and Length encoding". =20 Julien mentioned a point considered in Note 3: "Unless DER is used throughout, it is recommended that the binary encoding of the ASN.1 structures being time-stamped be preserved when being archived to ensure that the recalculation of the data hash is consistent". =20 So. To simplify your implementation you should use DER encoding = everywhere or just always keep original binary encoding. After that you have to concatenate binary representations of all the fields listed not trying = to throw away Type and Length tags, or getting all certificates or crls = from Certificates or crls elements of SignedData and concatenating them. Just concatenate full binary encodings of the listed elements in the = mentioned order. But you have to turn over a SignerInfo sequence: you should not include outer SignerInfo Type and Length tags in hashing, but rather = include every element of SignerInfo starting from version and finising with unsignedAttrs. =20 Said above is enough to add an archive timestamp attribute. Concerning verifying of this timestamp you should do the same concatenation, but = throw away all archive timestamps with time later then in the timestamp being verified from unsignedAttrs element and encode it over again. =20 Pavel Smirnov Crypto-Pro Tel./Fax: +7 495 780-4820 WWW: http://www.CryptoPro.ru e-mail: spv@CryptoPro.ru =20 From: Yasir Khan [mailto:yasir.khan@ascertia.com]=20 Sent: Thursday, July 03, 2008 8:07 PM To: =F3=CD=C9=D2=CE=CF=D7 =F0=C1=D7=C5=CC = =F7=CC=C1=C4=C9=CD=C9=D2=CF=D7=C9=DE; ietf-smime@imc.org Subject: RE: Using Signature Policy in RFC-5126 =20 RFC 5126 explains how to create archived time stamp i.e. =20 =20 ArchiveTimeStampToken ::=3D TimeStampToken =20 The value of the messageImprint field within TimeStampToken shall be a hash of the concatenation of: =20 - the encapContentInfo element of the SignedData sequence; =20 - any external content being protected by the signature, if the eContent element of the encapContentInfo is omitted; =20 - the Certificates and crls elements of the SignedData sequence, when present, and; =20 - all data elements in the SignerInfo sequence including all signed and unsigned attributes. =20 =20 The ArchiveTimeStamp will be added as an unsigned attribute in the SignerInfo sequence. =20 According to the RFC, it is clear that message imprint will be the hash = of above concatenated values but it is not explained how to concatenate = these values? Please clarify this point. Some hint for implementing this would = be highly appreciated. Thanks! =20 -------------------------------------------------------------------------= --- ------ YASIR KHAN Development Manager =20 Ascertia Limited www.ascertia.com =20 www.globaltrustfinder.com =20 -------------------------------------------------------------------------= --- ------ Delivering Trust for e-business Documents & Workflows -------------------------------------------------------------------------= --- ------ NOTICE: This message is intended for the recipient(s) only. This communication may contain privileged or other confidential information. If you are not the intended recipient, or = believe that you have received this communication in error, please do not print, copy, retransmit, disseminate, or otherwise = use the information. Please notify the sender that you have received this email in error, and delete the copy you received =20 _____ =20 From: owner-ietf-smime@mail.imc.org = [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Pavel V. Smirnov Sent: Thursday, June 26, 2008 1:04 PM To: 'Yasir Khan'; ietf-smime@imc.org Subject: RE: Using Signature Policy in RFC-5126 =20 Yes, I mean "digital signature policy" as a "policy document" present at SPUri. But I use SPUri only for example, you may specify a SigPolicyId = and omit sigPolicyQualifiers at all. In this case you have to rely on some = other means to convey a correspondence between SigPolicyIds and "policy documents". =20 In case of SPuri you have to retrieve a "policy document" by its URI and hash it. =20 Note that if your infrastructure provides a trusted source of "policy documents", and there will never be two different (versions of) "policy documents" identified by the same OID, you don't have to hash them at = all. Just use zero policy hash value. =20 Pavel Smirnov Crypto-Pro Tel./Fax: +7 495 780-4820 WWW: http://www.CryptoPro.ru e-mail: spv@CryptoPro.ru =20 From: owner-ietf-smime@mail.imc.org = [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Yasir Khan Sent: Thursday, June 26, 2008 12:19 PM To: =F3=CD=C9=D2=CE=CF=D7 =F0=C1=D7=C5=CC = =F7=CC=C1=C4=C9=CD=C9=D2=CF=D7=C9=DE; ietf-smime@imc.org Subject: RE: Using Signature Policy in RFC-5126 =20 You wrote: "You have to hash a digital signature policy represented as a sequence of bytes in some format and place the computed value in SigPolicyHash." =20 To which item you are naming as "digital signature policy". You mean = policy document present at SPUri? If Yes then it makes some sense. But if only SPUserNotice is present or nothing is present as sigPolicyQualifiers as = it is an OPTIONAL element: =20 sigPolicyQualifiers SEQUENCE SIZE (1..MAX) OF SigPolicyQualifierInfo OPTIONAL =20 then on which item the hash would be computed? =20 Regards, Yasir Khan =20 =20 _____ =20 From: Pavel V. Smirnov [mailto:spv@cryptopro.ru]=20 Sent: Wednesday, June 25, 2008 4:07 PM To: 'Yasir Khan'; ietf-smime@imc.org Subject: RE: Using Signature Policy in RFC-5126 =20 Hello Yasir, =20 There is no need to protect by SigPolicyHash other fields of SignaturePolicyId structure because it is placed in a signed attribute. = All signed attributes are protected by the signature itself. =20 In most cases the policy would be an external document not included in = your signed message, and you have to unambiguously indicate specific policy = with respect to which your document should be treated. E.g., you may only = have an URI pointing to the policy as a SigPolicyQualifier. =20 You have to hash a digital signature policy represented as a sequence of bytes in some format and place the computed value in SigPolicyHash. =20 Pavel Smirnov Crypto-Pro Tel./Fax: +7 495 780-4820 WWW: http://www.CryptoPro.ru e-mail: spv@CryptoPro.ru =20 From: owner-ietf-smime@mail.imc.org = [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Yasir Khan Sent: Wednesday, June 25, 2008 2:43 PM To: ietf-smime@imc.org Subject: Using Signature Policy in RFC-5126 =20 We have a question related to using the signature policy in the CAdES signatures (EPES) defined in RFC-5126. Here is the relevant structure: =20 SignaturePolicyId ::=3D SEQUENCE { sigPolicyIdentifier SigPolicyId, sigPolicyHash SigPolicyHash, sigPolicyQualifiers SEQUENCE SIZE (1..MAX) OF SigPolicyQualifierInfo OPTIONAL } =20 SigPolicyId ::=3D OBJECT IDENTIFIER =20 SigPolicyHash ::=3D OtherHashAlgAndValue =20 OtherHashAlgAndValue ::=3D SEQUENCE { hashAlgorithm AlgorithmIdentifier, hashValue OtherHashValue=20 } =20 SigPolicyQualifierInfo ::=3D SEQUENCE { sigPolicyQualifierId SigPolicyQualifierId, sigQualifier ANY DEFINED BY sigPolicyQualifierId } =20 SigPolicyQualifierId ::=3D OBJECT IDENTIFIER id-spq-ets-uri OBJECT IDENTIFIER ::=3D {=20 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) = pkcs9(9) smime(16) id-spq(5) 1=20 } SPuri ::=3D IA5String =20 id-spq-ets-unotice OBJECT IDENTIFIER ::=3D {=20 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) = pkcs9(9) smime(16) id-spq(5) 2=20 } SPUserNotice ::=3D SEQUENCE { noticeRef NoticeReference OPTIONAL, explicitText DisplayText OPTIONAL } =20 NoticeReference ::=3D SEQUENCE { organization DisplayText, noticeNumbers SEQUENCE OF INTEGER } =20 DisplayText ::=3D CHOICE { visibleString VisibleString (SIZE (1..200)), bmpString BMPString (SIZE (1..200)), utf8String UTF8String (SIZE (1..200)) } =20 In the given structure for CAdES-EPES signature, its is not clear that whether are we computing the hash "SigPolicyHash" over the document at "SPuri" and/or over the "SPUserNotice" =20 Are the following combinations valid? =20 1) Only compute hash over document present at SPURI if only SPUri is set = 2) Only compute hash over SPUserNotice if only SPUserNotice is set 3) Compute hash over document at SPURI and SPUserNotice if both are set =20 Please clarify it. Thanks! =20 Regards, =20 Yasir Khan Development Manager =20 Ascertia Ltd 40 Occam Road=20 Surrey Research Park Guildford Surrey, GU2 7YG United Kingdom =20 t. +44 (0)1483 685500 f. +44 (0)1483 573704=20 =20 www.ascertia.com =20 =20 ----------------------------------------------------------------- Identity Proven, Trust Delivered ----------------------------------------------------------------- =20 =20 ------=_NextPart_000_003D_01C8DDB0.7CB2BBD0 Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable

There are a couple of notes regarding archive timestamp = that could help you.

 

Note 4 says: “The hash is calculated over the = concatenated data elements as received/stored, including the Type and Length = encoding”.

 

Julien mentioned a point considered in Note 3: = “Unless DER is used throughout, it is recommended that the binary encoding of the = ASN.1 structures being time-stamped be preserved when being archived to ensure = that the recalculation of the data hash is = consistent”.

 

So. To simplify your implementation you should use DER = encoding everywhere or just always keep original binary encoding. After that you = have to concatenate binary representations of all the fields listed not trying = to throw away Type and Length tags, or getting all certificates or crls from Certificates or crls elements of SignedData and concatenating them. Just concatenate full binary encodings of the listed elements in the = mentioned order. But you have to turn over a SignerInfo sequence: you should not = include outer SignerInfo Type and Length tags in hashing, but rather include = every element of SignerInfo starting from version and finising with = unsignedAttrs.

 

Said above is enough to add an archive timestamp = attribute. Concerning verifying of this timestamp you should do the same concatenation, but = throw away all archive timestamps with time later then in the timestamp being = verified from unsignedAttrs element and encode it over = again.

 

Pavel Smirnov

Crypto-Pro
Tel./Fax: +7 495 780-4820
WWW: http://www.CryptoPro.ru=
e-mail: spv@CryptoPro.ru

 

From:= Yasir Khan [mailto:yasir.khan@ascertia.com]
Sent: Thursday, July 03, 2008 8:07 PM
To: =F3=CD=C9=D2=CE=CF=D7 =F0=C1=D7=C5=CC = =F7=CC=C1=C4=C9=CD=C9=D2=CF=D7=C9=DE; ietf-smime@imc.org
Subject: RE: Using Signature Policy in = RFC-5126

 

RFC 5126 explains how to create archived time stamp = i.e.

 

 

ArchiveTimeStampToken ::=3D = TimeStampToken

 

   The value of the messageImprint field within TimeStampToken shall be

   a hash of the concatenation = of:

 

      - the encapContentInfo = element of the SignedData sequence;

 

      - any external content being protected by the signature, if the

        eContent element = of the encapContentInfo is omitted;

 

      - the Certificates and crls = elements of the SignedData sequence,

        when present, = and;

 

      - all data elements in the SignerInfo sequence including all

        signed and = unsigned attributes.

 

 

The ArchiveTimeStamp will be added as an unsigned attribute = in the SignerInfo sequence.

 

According to the RFC, it is clear that message imprint will = be the hash of above concatenated values but it is not explained how to = concatenate these values? Please clarify this point. Some hint for implementing this = would be highly appreciated. Thanks!

 

-------------= ---------------------------------------------------------------------

YASIR KHAN Development Manager

 

Ascertia Limited www.ascertia.com  

www.globaltrustfinder.com =

-------------= ---------------------------------------------------------------------

Delivering Trust for e-business Documents & = Workflows

-------------= ---------------------------------------------------------------------

NOTICE: This message is intended for the recipient(s) only. = This communication may contain privileged or other

confidential information. If you are not the intended = recipient, or believe that you have received this communication = in

error, please do not print, copy, retransmit, disseminate, = or otherwise use the information. Please notify the sender = that

you have received this email in error, and delete the copy = you received

 

From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Pavel V. = Smirnov
Sent: Thursday, June 26, 2008 1:04 PM
To: 'Yasir Khan'; ietf-smime@imc.org
Subject: RE: Using Signature Policy in RFC-5126

 

Yes, I mean “digital signature policy” as a “policy document” present at SPUri. But I use SPUri only for example, you may specify a SigPolicyId and omit sigPolicyQualifiers at = all. In this case you have to rely on some other means to convey a = correspondence between SigPolicyIds and “policy = documents”.

 

In case of SPuri you have to retrieve a “policy document” by its URI and hash it.

 

Note that if your infrastructure provides a trusted = source of “policy documents”, and there will never be two different = (versions of) “policy documents” identified by the same OID, you = don’t have to hash them at all. Just use zero policy hash = value.

 

Pavel Smirnov

Crypto-Pro
Tel./Fax: +7 495 780-4820
WWW: http://www.CryptoPro.ru=
e-mail: spv@CryptoPro.ru

 

From:= owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] = On Behalf Of Yasir Khan
Sent: Thursday, June 26, 2008 12:19 PM
To: =F3=CD=C9=D2=CE=CF=D7 =F0=C1=D7=C5=CC = =F7=CC=C1=C4=C9=CD=C9=D2=CF=D7=C9=DE; ietf-smime@imc.org
Subject: RE: Using Signature Policy in = RFC-5126

 

You wrote: ”You have to hash a digital signature = policy represented as a sequence of bytes in some format and place the computed = value in SigPolicyHash.”

 

To which item you are naming as “digital signature policy”. You mean policy document present at SPUri? If Yes then it = makes some sense. But if only SPUserNotice is present or nothing is present as = si= gPolicyQualifiers as it is an OPTIONAL element= :

 

  &= nbsp;         sigPolicyQualifiers SEQUENCE SIZE (1..MAX) OF SigPolicyQualifierInfo = OPTIONAL

 

then on which item the hash would be = computed?

 

Regards,

Yasir Khan

 

 

From: Pavel V. Smirnov = [mailto:spv@cryptopro.ru]
Sent: Wednesday, June 25, 2008 4:07 PM
To: 'Yasir Khan'; ietf-smime@imc.org
Subject: RE: Using Signature Policy in RFC-5126

 

Hello Yasir,

 

There is no need to protect by SigPolicyHash other fields = of SignaturePolicyId structure because it is placed in a signed attribute. = All signed attributes are protected by the signature = itself.

 

In most cases the policy would be an external document = not included in your signed message, and you have to unambiguously indicate specific policy with respect to which your document should be treated. = E.g., you may only have an URI pointing to the policy as a = SigPolicyQualifier.

 

You have to hash a digital signature policy represented = as a sequence of bytes in some format and place the computed value in = SigPolicyHash.

 

Pavel Smirnov

Crypto-Pro
Tel./Fax: +7 495 780-4820
WWW: http://www.CryptoPro.ru=
e-mail: spv@CryptoPro.ru

 

From:= owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] = On Behalf Of Yasir Khan
Sent: Wednesday, June 25, 2008 2:43 PM
To: ietf-smime@imc.org
Subject: Using Signature Policy in RFC-5126

 

We have a question related to using the signature policy in the CAdES = signatures (EPES) defined in RFC-5126. Here is the relevant = structure:

 

SignaturePoli= cyId ::=3D SEQUENCE {

  &= nbsp;         sigPolicyIdentifier SigPolicyId,

  &= nbsp;         sigPolicyHash SigPolicyHash,

  &= nbsp;         sigPolicyQualifiers SEQUENCE SIZE (1..MAX) OF

  &= nbsp;         SigPolicyQualifierInfo OPTIONAL

}<= /span>

 

SigPolicyId ::=3D OBJECT IDENTIFIER

 

SigPolicyHash ::=3D = OtherHashAlgAndValue

 

OtherHashAlgAndValue ::=3D SEQUENCE = {

            hashAlgorithm   AlgorithmIdentifier,

        hashValue       OtherHashValue =

}

 

SigPolicyQual= ifierInfo ::=3D SEQUENCE {

  &= nbsp;         sigPolicyQualifierId SigPolicyQualifierId,

  &= nbsp;         sigQualifier ANY DEFINED BY sigPolicyQualifierId

}<= /span>

 

SigPolicyQual= ifierId ::=3D OBJECT IDENTIFIER

id-spq-ets-ur= i OBJECT IDENTIFIER ::=3D {

  &= nbsp;         iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) id-spq(5) 1

}<= /span>

SPuri ::=3D IA5String

 

id-spq-ets-un= otice OBJECT IDENTIFIER ::=3D {

  &= nbsp;         iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) id-spq(5) 2

}<= /span>

SPUserNotice ::=3D SEQUENCE {

  &= nbsp;         noticeRef NoticeReference OPTIONAL,

  &= nbsp;         explicitText DisplayText OPTIONAL

}<= /span>

 

NoticeReferen= ce ::=3D SEQUENCE {

  &= nbsp;         organization DisplayText,

  &= nbsp;         noticeNumbers SEQUENCE OF INTEGER

}<= /span>

 

DisplayText ::=3D CHOICE {

  &= nbsp;         visibleString VisibleString (SIZE (1..200)),

  &= nbsp;         bmpString BMPString (SIZE (1..200)),

  &= nbsp;         utf8String UTF8String (SIZE (1..200))

}<= /span>

 

In the given structure for CAdES-EPES signature, its is not clear that = whether are we computing the hash "SigPolicyHash" over the document at "SPuri" and/or over the = "SPUserNotice"

 

Are the following combinations valid?

 

1) Only compute hash over document present at SPURI if only SPUri is set =

2) Only compute hash over SPUserNotice  if only SPUserNotice is = set

3) Compute hash over document at SPURI and SPUserNotice if both are = set

 

Please clarify it. Thanks!

 

Regards,=

 

Yasir Khan
Development Manager

 

Ascertia Ltd
40 Occam Road
Surrey Research Park
Guildford
Surrey, GU2 7YG
United Kingdom

 

t.  +44 (0)1483 685500
f.  +44 (0)1483 573704

 

www.ascertia.com &nb= sp; 

 

-------------= ----------------------------------------------------
         Identity Proven, Trust Delivered
-----------------------------------------------------------------

 

 

------=_NextPart_000_003D_01C8DDB0.7CB2BBD0-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m63FRhNo034036 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Jul 2008 08:27:43 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m63FRhXb034035; Thu, 3 Jul 2008 08:27:43 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from kraid.nerim.net (kraid.ipv6.nerim.net [IPv6:2001:7a8:1:1::95]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m63FRfJx034023 for ; Thu, 3 Jul 2008 08:27:42 -0700 (MST) (envelope-from julien.stern@cryptolog.com) Received: from uranus.cry.pto (cryptolog2.pck.nerim.net [213.41.184.9]) by kraid.nerim.net (Postfix) with ESMTP id 858CACF0C3; Thu, 3 Jul 2008 17:27:39 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id 79A3A4401B; Thu, 3 Jul 2008 17:27:39 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at cryptolog.com Received: from uranus.cry.pto ([127.0.0.1]) by localhost (uranus.cry.pto [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C4ddXW8MSGRN; Thu, 3 Jul 2008 17:27:34 +0200 (CEST) Received: from [10.0.1.15] (isonoe.cry.pto [10.0.1.15]) by uranus.cry.pto (Postfix) with ESMTP id CA3004400C; Thu, 3 Jul 2008 17:27:34 +0200 (CEST) Message-ID: <486CEFE6.7060103@cryptolog.com> Date: Thu, 03 Jul 2008 17:27:34 +0200 From: Julien Stern User-Agent: Icedove 1.5.0.14eol (X11/20080509) MIME-Version: 1.0 To: Yasir Khan Cc: "'Pavel V. Smirnov'" , ietf-smime@imc.org Subject: Re: Using Signature Policy in RFC-5126 References: <200807031506.m63F6qMi031818@balder-227.proper.com> In-Reply-To: <200807031506.m63F6qMi031818@balder-227.proper.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Yasir, this specific point has caused many interoperability issues. Not only is the concatenation method subject to interpretation, but also, if you have several archive timestamps, you have to use heuristics to guess the previous encoding of the attribute sequence because it can be in BER. I can give you my humble interpretation of the way to concatenate but I cannot promise it will be the same as everyone else. There are currently discussions regarding a change of this attribute, possibly mandating DER encoding to remove all ambiguities. Do you believe such a change would be worthwhile ? Regards, -- Julien Stern Yasir Khan wrote: > RFC 5126 explains how to create archived time stamp i.e. > > > > > > ArchiveTimeStampToken ::= TimeStampToken > > > > The value of the messageImprint field within TimeStampToken shall be > > a hash of the concatenation of: > > > > - the encapContentInfo element of the SignedData sequence; > > > > - any external content being protected by the signature, if the > > eContent element of the encapContentInfo is omitted; > > > > - the Certificates and crls elements of the SignedData sequence, > > when present, and; > > > > - all data elements in the SignerInfo sequence including all > > signed and unsigned attributes. > > > > > > The ArchiveTimeStamp will be added as an unsigned attribute in the > SignerInfo sequence. > > > > According to the RFC, it is clear that message imprint will be the hash > of above concatenated values but it is not explained how to concatenate > these values? Please clarify this point. Some hint for implementing this > would be highly appreciated. Thanks! > > > > ---------------------------------------------------------------------------------- > > **YASIR KHAN*** > *Development Manager**** > > > > **Ascertia Limited** > www.ascertia.com > > www.globaltrustfinder.com > > ---------------------------------------------------------------------------------- > > //Delivering Trust for e-business Documents & Workflows// > > ---------------------------------------------------------------------------------- > > NOTICE: This message is intended for the recipient(s) only. This > communication may contain privileged or other > > confidential information. If you are not the intended recipient, or > believe that you have received this communication in > > error, please do not print, copy, retransmit, disseminate, or otherwise > use the information. Please notify the sender that > > you have received this email in error, and delete the copy you received > > > > ------------------------------------------------------------------------ > > *From:* owner-ietf-smime@mail.imc.org > [mailto:owner-ietf-smime@mail.imc.org] *On Behalf Of *Pavel V. Smirnov > *Sent:* Thursday, June 26, 2008 1:04 PM > *To:* 'Yasir Khan'; ietf-smime@imc.org > *Subject:* RE: Using Signature Policy in RFC-5126 > > > > Yes, I mean “digital signature policy†as a “policy document†present at > SPUri. But I use SPUri only for example, you may specify a SigPolicyId > and omit sigPolicyQualifiers at all. In this case you have to rely on > some other means to convey a correspondence between SigPolicyIds and > “policy documentsâ€. > > > > In case of SPuri you have to retrieve a “policy document†by its URI and > hash it. > > > > Note that if your infrastructure provides a trusted source of “policy > documentsâ€, and there will never be two different (versions of) “policy > documents†identified by the same OID, you don’t have to hash them at > all. Just use zero policy hash value. > > > > Pavel Smirnov > > Crypto-Pro > Tel./Fax: +7 495 780-4820 > WWW: http://www.CryptoPro.ru > e-mail: spv@CryptoPro.ru > > > > *From:* owner-ietf-smime@mail.imc.org > [mailto:owner-ietf-smime@mail.imc.org] *On Behalf Of *Yasir Khan > *Sent:* Thursday, June 26, 2008 12:19 PM > *To:* Смирнов Павел Владимирович; ietf-smime@imc.org > *Subject:* RE: Using Signature Policy in RFC-5126 > > > > You wrote: â€You have to hash a *digital signature policy* represented as > a sequence of bytes in some format and place the computed value in > SigPolicyHash.†> > > > To which item you are naming as “digital signature policyâ€. You mean > policy document present at SPUri? If Yes then it makes some sense. But > if only SPUserNotice is present or nothing is present as > *sigPolicyQualifiers* as it is an OPTIONAL element: > > > > sigPolicyQualifiers SEQUENCE SIZE (1..MAX) OF > SigPolicyQualifierInfo OPTIONAL > > > > then on which item the hash would be computed? > > > > Regards, > > Yasir Khan > > > > > > ------------------------------------------------------------------------ > > *From:* Pavel V. Smirnov [mailto:spv@cryptopro.ru] > *Sent:* Wednesday, June 25, 2008 4:07 PM > *To:* 'Yasir Khan'; ietf-smime@imc.org > *Subject:* RE: Using Signature Policy in RFC-5126 > > > > Hello Yasir, > > > > There is no need to protect by SigPolicyHash other fields of > SignaturePolicyId structure because it is placed in a signed attribute. > All signed attributes are protected by the signature itself. > > > > In most cases the policy would be an external document not included in > your signed message, and you have to unambiguously indicate specific > policy with respect to which your document should be treated. E.g., you > may only have an URI pointing to the policy as a SigPolicyQualifier. > > > > You have to hash a digital signature policy represented as a sequence of > bytes in some format and place the computed value in SigPolicyHash. > > > > Pavel Smirnov > > Crypto-Pro > Tel./Fax: +7 495 780-4820 > WWW: http://www.CryptoPro.ru > e-mail: spv@CryptoPro.ru > > > > *From:* owner-ietf-smime@mail.imc.org > [mailto:owner-ietf-smime@mail.imc.org] *On Behalf Of *Yasir Khan > *Sent:* Wednesday, June 25, 2008 2:43 PM > *To:* ietf-smime@imc.org > *Subject:* Using Signature Policy in RFC-5126 > > > > We have a question related to using the signature policy in the CAdES > signatures (EPES) defined in RFC-5126. Here is the relevant structure: > > > > SignaturePolicyId ::= SEQUENCE { > > sigPolicyIdentifier SigPolicyId, > > *sigPolicyHash SigPolicyHash,* > > sigPolicyQualifiers SEQUENCE SIZE (1..MAX) OF > > SigPolicyQualifierInfo OPTIONAL > > } > > > > SigPolicyId ::= OBJECT IDENTIFIER > > > > *SigPolicyHash ::= OtherHashAlgAndValue* > > * * > > *OtherHashAlgAndValue ::= SEQUENCE {* > > * hashAlgorithm AlgorithmIdentifier,* > > * hashValue OtherHashValue * > > *}* > > > > SigPolicyQualifierInfo ::= SEQUENCE { > > sigPolicyQualifierId SigPolicyQualifierId, > > sigQualifier ANY DEFINED BY sigPolicyQualifierId > > } > > > > SigPolicyQualifierId ::= OBJECT IDENTIFIER > > id-spq-ets-uri OBJECT IDENTIFIER ::= { > > iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) > pkcs9(9) smime(16) id-spq(5) 1 > > } > > SPuri ::= IA5String > > > > id-spq-ets-unotice OBJECT IDENTIFIER ::= { > > iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) > pkcs9(9) smime(16) id-spq(5) 2 > > } > > SPUserNotice ::= SEQUENCE { > > noticeRef NoticeReference OPTIONAL, > > explicitText DisplayText OPTIONAL > > } > > > > NoticeReference ::= SEQUENCE { > > organization DisplayText, > > noticeNumbers SEQUENCE OF INTEGER > > } > > > > DisplayText ::= CHOICE { > > visibleString VisibleString (SIZE (1..200)), > > bmpString BMPString (SIZE (1..200)), > > utf8String UTF8String (SIZE (1..200)) > > } > > > > In the given structure for CAdES-EPES signature, its is not clear that > whether are we computing the hash "SigPolicyHash" over the document at > "SPuri" and/or over the "SPUserNotice" > > > > Are the following combinations valid? > > > > 1) Only compute hash over document present at SPURI if only SPUri is set > > 2) Only compute hash over SPUserNotice if only SPUserNotice is set > > 3) Compute hash over document at SPURI and SPUserNotice if both are set > > > > Please clarify it. Thanks! > > > > Regards, > > > > Yasir Khan > Development Manager > > > > Ascertia Ltd > 40 Occam Road > Surrey Research Park > Guildford > Surrey, GU2 7YG > United Kingdom > > > > t. +44 (0)1483 685500 > f. +44 (0)1483 573704 > > > > www.ascertia.com > > > > ----------------------------------------------------------------- > Identity Proven, Trust Delivered > ----------------------------------------------------------------- > > > > > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m63F7GUf031842 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Jul 2008 08:07:16 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m63F7GqL031841; Thu, 3 Jul 2008 08:07:16 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from ascertia.com (server5852.dedicated.webfusion.co.uk [81.21.74.134]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m63F6qMi031818 for ; Thu, 3 Jul 2008 08:06:53 -0700 (MST) (envelope-from yasir.khan@ascertia.com) Message-Id: <200807031506.m63F6qMi031818@balder-227.proper.com> Received: from ascertiajtl1 ([203.128.26.18]) by ds5852.dedicated.turbodns.co.uk with MailEnable ESMTP; Thu, 03 Jul 2008 15:08:31 +0100 From: "Yasir Khan" To: "'Pavel V. Smirnov'" , Subject: RE: Using Signature Policy in RFC-5126 Date: Thu, 3 Jul 2008 21:07:15 +0500 Organization: Ascertia Limited MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcjWsEVkUJ9OGEWeQRKpgqvSmd/z7AAAX7AgACx4USAAAKjZYAFv/YPA Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_039F_01C8DD50.C5132EB0" In-Reply-To: <002c01c8d763$2c6d3db0$8547b910$@ru> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_039F_01C8DD50.C5132EB0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_03A0_01C8DD50.C5132EB0" ------=_NextPart_001_03A0_01C8DD50.C5132EB0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable RFC 5126 explains how to create archived time stamp i.e. =20 =20 ArchiveTimeStampToken ::=3D TimeStampToken =20 The value of the messageImprint field within TimeStampToken shall be a hash of the concatenation of: =20 - the encapContentInfo element of the SignedData sequence; =20 - any external content being protected by the signature, if the eContent element of the encapContentInfo is omitted; =20 - the Certificates and crls elements of the SignedData sequence, when present, and; =20 - all data elements in the SignerInfo sequence including all signed and unsigned attributes. =20 =20 The ArchiveTimeStamp will be added as an unsigned attribute in the SignerInfo sequence. =20 According to the RFC, it is clear that message imprint will be the hash = of above concatenated values but it is not explained how to concatenate = these values? Please clarify this point. Some hint for implementing this would = be highly appreciated. Thanks! =20 -------------------------------------------------------------------------= --- ------ YASIR KHAN Development Manager =20 Ascertia Limited www.ascertia.com =20 www.globaltrustfinder.com =20 -------------------------------------------------------------------------= --- ------ Delivering Trust for e-business Documents & Workflows -------------------------------------------------------------------------= --- ------ NOTICE: This message is intended for the recipient(s) only. This communication may contain privileged or other confidential information. If you are not the intended recipient, or = believe that you have received this communication in error, please do not print, copy, retransmit, disseminate, or otherwise = use the information. Please notify the sender that you have received this email in error, and delete the copy you received =20 _____ =20 From: owner-ietf-smime@mail.imc.org = [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Pavel V. Smirnov Sent: Thursday, June 26, 2008 1:04 PM To: 'Yasir Khan'; ietf-smime@imc.org Subject: RE: Using Signature Policy in RFC-5126 =20 Yes, I mean "digital signature policy" as a "policy document" present at SPUri. But I use SPUri only for example, you may specify a SigPolicyId = and omit sigPolicyQualifiers at all. In this case you have to rely on some = other means to convey a correspondence between SigPolicyIds and "policy documents". =20 In case of SPuri you have to retrieve a "policy document" by its URI and hash it. =20 Note that if your infrastructure provides a trusted source of "policy documents", and there will never be two different (versions of) "policy documents" identified by the same OID, you don't have to hash them at = all. Just use zero policy hash value. =20 Pavel Smirnov Crypto-Pro Tel./Fax: +7 495 780-4820 WWW: http://www.CryptoPro.ru e-mail: spv@CryptoPro.ru =20 From: owner-ietf-smime@mail.imc.org = [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Yasir Khan Sent: Thursday, June 26, 2008 12:19 PM To: =F3=CD=C9=D2=CE=CF=D7 =F0=C1=D7=C5=CC = =F7=CC=C1=C4=C9=CD=C9=D2=CF=D7=C9=DE; ietf-smime@imc.org Subject: RE: Using Signature Policy in RFC-5126 =20 You wrote: "You have to hash a digital signature policy represented as a sequence of bytes in some format and place the computed value in SigPolicyHash." =20 To which item you are naming as "digital signature policy". You mean = policy document present at SPUri? If Yes then it makes some sense. But if only SPUserNotice is present or nothing is present as sigPolicyQualifiers as = it is an OPTIONAL element: =20 sigPolicyQualifiers SEQUENCE SIZE (1..MAX) OF SigPolicyQualifierInfo OPTIONAL =20 then on which item the hash would be computed? =20 Regards, Yasir Khan =20 =20 _____ =20 From: Pavel V. Smirnov [mailto:spv@cryptopro.ru]=20 Sent: Wednesday, June 25, 2008 4:07 PM To: 'Yasir Khan'; ietf-smime@imc.org Subject: RE: Using Signature Policy in RFC-5126 =20 Hello Yasir, =20 There is no need to protect by SigPolicyHash other fields of SignaturePolicyId structure because it is placed in a signed attribute. = All signed attributes are protected by the signature itself. =20 In most cases the policy would be an external document not included in = your signed message, and you have to unambiguously indicate specific policy = with respect to which your document should be treated. E.g., you may only = have an URI pointing to the policy as a SigPolicyQualifier. =20 You have to hash a digital signature policy represented as a sequence of bytes in some format and place the computed value in SigPolicyHash. =20 Pavel Smirnov Crypto-Pro Tel./Fax: +7 495 780-4820 WWW: http://www.CryptoPro.ru e-mail: spv@CryptoPro.ru =20 From: owner-ietf-smime@mail.imc.org = [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Yasir Khan Sent: Wednesday, June 25, 2008 2:43 PM To: ietf-smime@imc.org Subject: Using Signature Policy in RFC-5126 =20 We have a question related to using the signature policy in the CAdES signatures (EPES) defined in RFC-5126. Here is the relevant structure: =20 SignaturePolicyId ::=3D SEQUENCE { sigPolicyIdentifier SigPolicyId, sigPolicyHash SigPolicyHash, sigPolicyQualifiers SEQUENCE SIZE (1..MAX) OF SigPolicyQualifierInfo OPTIONAL } =20 SigPolicyId ::=3D OBJECT IDENTIFIER =20 SigPolicyHash ::=3D OtherHashAlgAndValue =20 OtherHashAlgAndValue ::=3D SEQUENCE { hashAlgorithm AlgorithmIdentifier, hashValue OtherHashValue=20 } =20 SigPolicyQualifierInfo ::=3D SEQUENCE { sigPolicyQualifierId SigPolicyQualifierId, sigQualifier ANY DEFINED BY sigPolicyQualifierId } =20 SigPolicyQualifierId ::=3D OBJECT IDENTIFIER id-spq-ets-uri OBJECT IDENTIFIER ::=3D {=20 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) = pkcs9(9) smime(16) id-spq(5) 1=20 } SPuri ::=3D IA5String =20 id-spq-ets-unotice OBJECT IDENTIFIER ::=3D {=20 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) = pkcs9(9) smime(16) id-spq(5) 2=20 } SPUserNotice ::=3D SEQUENCE { noticeRef NoticeReference OPTIONAL, explicitText DisplayText OPTIONAL } =20 NoticeReference ::=3D SEQUENCE { organization DisplayText, noticeNumbers SEQUENCE OF INTEGER } =20 DisplayText ::=3D CHOICE { visibleString VisibleString (SIZE (1..200)), bmpString BMPString (SIZE (1..200)), utf8String UTF8String (SIZE (1..200)) } =20 In the given structure for CAdES-EPES signature, its is not clear that whether are we computing the hash "SigPolicyHash" over the document at "SPuri" and/or over the "SPUserNotice" =20 Are the following combinations valid? =20 1) Only compute hash over document present at SPURI if only SPUri is set = 2) Only compute hash over SPUserNotice if only SPUserNotice is set 3) Compute hash over document at SPURI and SPUserNotice if both are set =20 Please clarify it. Thanks! =20 Regards, =20 Yasir Khan Development Manager =20 Ascertia Ltd 40 Occam Road=20 Surrey Research Park Guildford Surrey, GU2 7YG United Kingdom =20 t. +44 (0)1483 685500 f. +44 (0)1483 573704=20 =20 www.ascertia.com =20 =20 ----------------------------------------------------------------- Identity Proven, Trust Delivered ----------------------------------------------------------------- =20 =20 ------=_NextPart_001_03A0_01C8DD50.C5132EB0 Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable

RFC 5126 explains how to create = archived time stamp i.e.

=9A

 

ArchiveTimeStampToken ::=3D = TimeStampToken

 

=9A=9A The value of the = messageImprint field within TimeStampToken shall be

=9A=9A a hash of the concatenation = of:

 

=9A=9A=9A=9A=9A - the = encapContentInfo element of the SignedData sequence;

 

=9A=9A=9A=9A=9A - any external = content being protected by the signature, if the

=9A=9A=9A=9A=9A=9A=9A eContent = element of the encapContentInfo is omitted;

 

=9A=9A=9A=9A=9A - the Certificates = and crls elements of the SignedData sequence,

=9A=9A=9A=9A=9A=9A=9A when present, = and;

 

=9A=9A=9A=9A=9A - all data elements = in the SignerInfo sequence including all

=9A=9A=9A=9A=9A=9A=9A signed and = unsigned attributes.

=9A

 

The ArchiveTimeStamp will be added = as an unsigned attribute in the SignerInfo = sequence.

 

According to the RFC, it is clear = that message imprint will be the hash of above concatenated values but it is = not explained how to concatenate these values? Please clarify this point. Some hint = for implementing this would be highly appreciated. Thanks!

 

------------------------------------------------------= ----------------------------

YASIR = KHAN
Development Manager

 

Ascertia = Limited
www.ascertia.com  

www.globaltrustfinder.com

------------------------------------------------------= ----------------------------

Delivering Trust for e-business Documents & = Workflows

------------------------------------------------------= ----------------------------

NOTICE: This message is intended = for the recipient(s) only. This communication may contain privileged or = other

confidential information. If you = are not the intended recipient, or believe that you have received this = communication in

error, please do not print, copy, retransmit, disseminate, or otherwise use the information. Please notify = the sender that

you have received this email in = error, and delete the copy you received

 

From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] = On Behalf Of Pavel V. Smirnov
Sent: Thursday, June 26, = 2008 1:04 PM
To: 'Yasir Khan'; ietf-smime@imc.org
Subject: RE: Using = Signature Policy in RFC-5126

 

Yes, I mean = “digital signature policy” as a “policy document” present at = SPUri. But I use SPUri only for example, you may specify a SigPolicyId and omit sigPolicyQualifiers at all. In this case you have to rely on some other = means to convey a correspondence between SigPolicyIds and “policy = documents”.

 <= /o:p>

In case of = SPuri you have to retrieve a “policy document” by its URI and hash = it.

 <= /o:p>

Note that = if your infrastructure provides a trusted source of “policy = documents”, and there will never be two different (versions of) “policy = documents” identified by the same OID, you don’t have to hash them at all. = Just use zero policy hash value.

 <= /o:p>

Pavel = Smirnov

Crypto-Pro
Tel./Fax: +7 495 780-4820
WWW: http://www.CryptoPro.ru
e-mail: spv@CryptoPro.ru<= /span>

 <= /o:p>

From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] = On Behalf Of Yasir Khan
Sent: Thursday, June 26, = 2008 12:19 PM
To: =F3=CD=C9=D2=CE=CF=D7 = =F0=C1=D7=C5=CC =F7=CC=C1=C4=C9=CD=C9=D2=CF=D7=C9=DE; ietf-smime@imc.org
Subject: RE: Using = Signature Policy in RFC-5126

 

You wrote: = ”You have to hash a digital signature = policy represented as a sequence of bytes in some format and place the computed = value in SigPolicyHash.”

 <= /o:p>

To which item you are naming as = “digital signature policy”. You mean policy document present at SPUri? If = Yes then it makes some sense. But if only SPUserNotice is present or nothing is = present as sigPolicyQualifiers= as it is an OPTIONAL = element:

 <= /o:p>

         =    sigPolicyQualifiers SEQUENCE SIZE (1..MAX) OF SigPolicyQualifierInfo = OPTIONAL

 

then on which item the hash would = be computed?

 

Regards,

Yasir = Khan

 

 

From: Pavel = V. Smirnov [mailto:spv@cryptopro.ru]
Sent: Wednesday, June 25, = 2008 4:07 PM
To: 'Yasir Khan'; ietf-smime@imc.org
Subject: RE: Using = Signature Policy in RFC-5126

 

Hello = Yasir,

 <= /o:p>

There is no = need to protect by SigPolicyHash other fields of SignaturePolicyId structure = because it is placed in a signed attribute. All signed attributes are protected by = the signature itself.

 <= /o:p>

In most = cases the policy would be an external document not included in your signed = message, and you have to unambiguously indicate specific policy with respect to which = your document should be treated. E.g., you may only have an URI pointing to = the policy as a SigPolicyQualifier.

 <= /o:p>

You have to = hash a digital signature policy represented as a sequence of bytes in some = format and place the computed value in SigPolicyHash.

 <= /o:p>

Pavel = Smirnov

Crypto-Pro
Tel./Fax: +7 495 780-4820
WWW: http://www.CryptoPro.ru
e-mail: spv@CryptoPro.ru<= /span>

 <= /o:p>

From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] = On Behalf Of Yasir Khan
Sent: Wednesday, June 25, = 2008 2:43 PM
To: = ietf-smime@imc.org
Subject: Using Signature = Policy in RFC-5126

 

We have a question related to using the signature = policy in the CAdES signatures (EPES) defined in RFC-5126. Here is the relevant structure:

 

SignaturePolicyId ::=3D SEQUENCE = {

         =    sigPolicyIdentifier SigPolicyId,

         =    sigPolicyHash = SigPolicyHash,

         =    sigPolicyQualifiers SEQUENCE SIZE (1..MAX) = OF

         =    SigPolicyQualifierInfo OPTIONAL

}

 

SigPolicyId ::=3D OBJECT = IDENTIFIER

 

SigPolicyHash ::=3D = OtherHashAlgAndValue

 

OtherHashAlgAndValue ::=3D SEQUENCE = {

            hashAlgorithm   AlgorithmIdentifier,

      &= nbsp; hashValue       OtherHashValue =

}

 

SigPolicyQualifierInfo ::=3D SEQUENCE = {

         =    sigPolicyQualifierId SigPolicyQualifierId,

         =    sigQualifier ANY DEFINED BY = sigPolicyQualifierId

}

 

SigPolicyQualifierId ::=3D OBJECT = IDENTIFIER

id-spq-ets-uri OBJECT IDENTIFIER ::=3D { =

         =    iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) id-spq(5) 1

}

SPuri ::=3D IA5String

 

id-spq-ets-unotice OBJECT IDENTIFIER ::=3D { =

         =    iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) id-spq(5) 2

}

SPUserNotice ::=3D SEQUENCE = {

         =    noticeRef NoticeReference OPTIONAL,

         =    explicitText DisplayText OPTIONAL

}

 

NoticeReference ::=3D SEQUENCE = {

         =    organization DisplayText,

         =    noticeNumbers SEQUENCE OF INTEGER

}

 

DisplayText ::=3D CHOICE = {

         =    visibleString VisibleString (SIZE = (1..200)),

         =    bmpString BMPString (SIZE (1..200)),

         =    utf8String UTF8String (SIZE (1..200))

}

 

In the given structure for CAdES-EPES signature, its = is not clear that whether are we computing the hash "SigPolicyHash" = over the document at "SPuri" and/or over the = "SPUserNotice"

 

Are the following combinations = valid?

 

1) Only compute hash over document present at SPURI = if only SPUri is set

2) Only compute hash over SPUserNotice  if only SPUserNotice is set

3) Compute hash over document at SPURI and = SPUserNotice if both are set

 

Please clarify it. = Thanks!

 

Regards,

 

Yasir Khan
Development Manager

 

Ascertia Ltd
40 Occam = Road
Surrey Research Park
Guildford
Surrey, = GU2 7YG
United = Kingdom

 

t.  +44 (0)1483 685500
f.  +44 (0)1483 573704

 

www.ascertia.com &nb= sp; 

 

------------------------------------------------------= -----------
         Identity Proven, Trust Delivered
-----------------------------------------------------------------

 

 

------=_NextPart_001_03A0_01C8DD50.C5132EB0-- ------=_NextPart_000_039F_01C8DD50.C5132EB0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKrDCCA2Yw ggJOoAMCAQICAgCiMA0GCSqGSIb3DQEBBQUAMDsxCzAJBgNVBAYTAkdCMREwDwYDVQQKEwhBc2Nl cnRpYTEZMBcGA1UEAxMQQXNjZXJ0aWEgUm9vdCBDQTAeFw0wNzA4MjkxMTMyNDFaFw0xMjA3MzAx NDAwMDBaMD8xCzAJBgNVBAYTAkdCMREwDwYDVQQKEwhBc2NlcnRpYTEdMBsGA1UEAxMUQXNjZXJ0 aWEgSW50ZXJuYWwgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALuLrYfKGZYthbhiDOuw MAnoE5tOiOWRRg4M8V/EVy40jznn4rv7uxD7a0QFGu3FpDSB5sF+scoFnPRQOTxzl356ZJi1buOy Uyh/5CuPA/rwhi9rdpCISxR6yRyHZZ/XflR/Yv7dF5MXVJey/JVOx5v79PUV5cQPiLRbB82V42Nl AgMBAAGjgfMwgfAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFLet N082zMwCpLTUC2CLHoP+PHSwME4GA1UdHwRHMEUwQ6BBoD+GPWh0dHA6Ly93d3cuYXNjZXJ0aWEu Y29tL09ubGluZUNBL2NybHMvYXNjZXJ0aWFyb290Y2Evcm9vdC5jcmwwPQYIKwYBBQUHAQEEMTAv MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC5nbG9iYWx0cnVzdGZpbmRlci5jb20wHwYDVR0jBBgw FoAUsVNxoCj95wxTmh1rEDzuyBrNXs4wDQYJKoZIhvcNAQEFBQADggEBABPox5Vj8s+4lemtxQ3z cj93BL232DlSIeOoo9gnO4Kkfk0aIw5dfEUrTOKE5BNbaRoivpbwLkTsLuSBYBUX75UbImLlVDHQ yxw/iFSzMGvQJnzOAIEXt0ppZizrNadPxA7QlurT+aU6IEkVXk2dTBIsAQm7eYKcyvnF1GG8srHy AOaUL2syBzih9yEtRC+PQa4FyouraGmF/xZKvtrRyqgla/95nJF+Adm9+zlcNh+Kesb9tovxTEoD /QuyR8kdlxpCif8TmeJqZcU5yDT4gByn4bocrcwOIu7m5ohOoKwv0fhZ4XXLBPlco+pUZu4aFbUT HeUnO28GZ3QS/Xq70UYwggNqMIICUqADAgECAgEBMA0GCSqGSIb3DQEBBQUAMDsxCzAJBgNVBAYT AkdCMREwDwYDVQQKEwhBc2NlcnRpYTEZMBcGA1UEAxMQQXNjZXJ0aWEgUm9vdCBDQTAeFw0wMzAz MDQwODA2MTJaFw0xMzAzMDQwODAxMjdaMDsxCzAJBgNVBAYTAkdCMREwDwYDVQQKEwhBc2NlcnRp YTEZMBcGA1UEAxMQQXNjZXJ0aWEgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBANH4095uJr+IYSU0bdAj1OVBJYT6/CGH03WnrTyG3HBfccbY9EQOi7yE/+vekiSQkSx+UbG3 dFVcr5S3sjIooHXuuGVRIaauppEvZ8DHIKwJu1qTq4uqHtp8Nh6wjWjMufixgwV4VYYJYqSQ0HMZ 8O8p5uNcDP3I3GEXIsZsH5lSQSx+NADcYngPNrgUBtZQf9D2Nal3xFT1bH0eL5BN9c5NppZOf5Ax GD1Ba4/qmSVKwYDrmP1hagF34421IRQzRpfen+K55xKoL8iN9LFruFYKyRBH5vOqDfEwlNpHUmkJ B2zpnU6olflHdQSHvUVrELZNMyAaE0OHBW6jESBI+GUCAwEAAaN5MHcwDgYDVR0PAQH/BAQDAgEG MA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFLFTcaAo/ecMU5odaxA87sgazV7OMDUGCCsGAQUF BwEBBCkwJzAlBggrBgEFBQcwAYYZd3d3Lmdsb2JhbHRydXN0ZmluZGVyLmNvbTANBgkqhkiG9w0B AQUFAAOCAQEApGux/r8DwvMyoQUlwqXemrjV89cfuAMttrIZjG9EnXktEzDHLoDwDZKtjmtXy7w9 K0pwwYqP/VHirXNj+HZMfR4gcM3MhxeICd1kU0EhE+yRDWogoiVO079NgLV/6qyz2vt4pzBiT3Ra F2R1nST+vbVnslAy0sa+A77YxzgsRvh/UuL9N0HczR0GrSdGsNfnCIzeGhFtiRaf7Ss20eXh9Wqn kzRL0F5a53+M0iI+7Y5IUJ2JcOBhVg/no59Vge5RC5MZ+xE/wQje5QTlEWog8GP5XH8PDO38uc1H YJ8q/oc9LkCy0plavTiT9Eqx6sgGYku7GiGB+dS4tYmi8sU8mTCCA9AwggM5oAMCAQICAgCyMA0G CSqGSIb3DQEBBQUAMD8xCzAJBgNVBAYTAkdCMREwDwYDVQQKEwhBc2NlcnRpYTEdMBsGA1UEAxMU QXNjZXJ0aWEgSW50ZXJuYWwgQ0EwHhcNMDcxMDA1MDUzNDM4WhcNMDkxMjMxMTcyOTQ3WjBLMQsw CQYDVQQGEwJHQjERMA8GA1UEChMIQXNjZXJ0aWExFDASBgNVBAsTC0RldmVsb3BtZW50MRMwEQYD VQQDEwpZYXNpciBLaGFuMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEJ5Ic8Cm+Cbqmt1FW keRqBAGa9RuSMhmaNLiwh739XsZzr5uZd4A47GNIGukrOp0b7Dg7W5Ueu8yQboZF5rQOifWwC7KH o+aw3MegJcRLjFVq7HNr4hR/BnmGbs0fmxlfnfqopQK1qQ8MsaffnIiYmZEcPmufun/G8flKIvGa dwIDAQABo4IBzTCCAckwCwYDVR0PBAQDAgP4MIGpBgNVHSAEgaEwgZ4wgZsGCisGAQQB/EkBAgEw gYwwgYkGCCsGAQUFBwICMH0ae1RoaXMgY2VydGlmaWNhdGUgaXMgZm9yIHRoZSBzb2xlIHVzZSBv ZiBBc2NlcnRpYSBhbmQgaXRzIGN1c3RvbWVycywgZm9yIGRlbW9uc3RyYXRpb24gcHVycG9zZXMg b25seS4gTk8gTElBQklMSVRZIEFDQ0VQVEVELjAdBgNVHQ4EFgQU7q3EWPOWa4yyK5/5d5OuKirv e9YwYAYDVR0fBFkwVzBVoFOgUYZPaHR0cDovL3d3dy5hc2NlcnRpYS5jb20vT25saW5lQ0EvY3Js cy9Bc2NlcnRpYUludGVybmFsQ0EvQXNjZXJ0aWFJbnRlcm5hbENBLmNybDA9BggrBgEFBQcBAQQx MC8wLQYIKwYBBQUHMAGGIWh0dHA6Ly9vY3NwLmdsb2JhbHRydXN0ZmluZGVyLmNvbTAJBgNVHRME AjAAMCIGA1UdEQQbMBmBF3lhc2lyLmtoYW5AYXNjZXJ0aWEuY29tMB8GA1UdIwQYMBaAFLetN082 zMwCpLTUC2CLHoP+PHSwMA0GCSqGSIb3DQEBBQUAA4GBAJUwo7tBgjcPPBqKjuKr7oeBvL+/sk8a it05k3lm5iK7u8IhDQjldhaN8ldI2F1El5xoMGpq6pZnujFasJUdEcokDIm0zHrjo3Tq6BGxHf8J ZPaRaL/UUBxD/2tr8zB986r3+kWByLzP08Du0+hpXAh4u81Qg4KT8OVMOAPgV51HMYICYzCCAl8C AQEwRTA/MQswCQYDVQQGEwJHQjERMA8GA1UEChMIQXNjZXJ0aWExHTAbBgNVBAMTFEFzY2VydGlh IEludGVybmFsIENBAgIAsjAJBgUrDgMCGgUAoIIBdDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wODA3MDMxNjA3MTVaMCMGCSqGSIb3DQEJBDEWBBSWueZ3oGk2fb0G XxmVAP7+D3kOzDBUBgkrBgEEAYI3EAQxRzBFMD8xCzAJBgNVBAYTAkdCMREwDwYDVQQKEwhBc2Nl cnRpYTEdMBsGA1UEAxMUQXNjZXJ0aWEgSW50ZXJuYWwgQ0ECAgCyMFYGCyqGSIb3DQEJEAILMUeg RTA/MQswCQYDVQQGEwJHQjERMA8GA1UEChMIQXNjZXJ0aWExHTAbBgNVBAMTFEFzY2VydGlhIElu dGVybmFsIENBAgIAsjBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG 9w0CBTANBgkqhkiG9w0BAQEFAASBgHjIRBPnjQ/bq33Kj1KKl3IgcD+eVICZlgTcVLVtHa0LDeW1 OEJ2M1Mm9FJb2hsSflKnsNPjFfSjlgD+zwfrrLRk4RRmvKQQ6FB63Fbu7Nz2GybnI5KbN4h+MueE 346cOBCv1O0axgFjJxaqTSnDpcBUSDN+AfMyWJBZI86KR241AAAAAAAA ------=_NextPart_000_039F_01C8DD50.C5132EB0-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m62KcIVs048098 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Jul 2008 13:38:18 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m62KcItY048097; Wed, 2 Jul 2008 13:38:18 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp104.biz.mail.re2.yahoo.com (smtp104.biz.mail.re2.yahoo.com [206.190.52.173]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m62KcHKp048090 for ; Wed, 2 Jul 2008 13:38:17 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 5469 invoked from network); 2 Jul 2008 20:38:16 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@71.191.0.199 with login) by smtp104.biz.mail.re2.yahoo.com with SMTP; 2 Jul 2008 20:38:15 -0000 X-YMail-OSG: l32ClMIVM1nj9ZE.42afA30ZnpxELIPIAWIoL7xz0VKO.RqKDKlPWt3VrwwziVIo1gnAIClN6IFRDCBu0iCbxfGXz0xWaK6hJalgdph35vn6PLR6fJyGNSxlVuQN3Ocd6fkOuJ9ZJUU_lkYladTNEifx X-Yahoo-Newman-Property: ymail-3 From: "Turner, Sean P." To: Subject: FW: I-D ACTION:draft-gennai-smime-cnipa-pec-00.txt Date: Wed, 2 Jul 2008 16:38:05 -0400 Organization: IECA, Inc. Message-ID: <373A0D028EBE4F25A40803CA88D88D8E@Wylie> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0000_01C8DC62.01556AE0" X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcjbAOiqtudPQIjWSrCr8UaW88UJ+gBgawnQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C8DC62.01556AE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I'd like to draw attention to this ID. Alba and Francesco described the PEC (Posta Elettronica Certificata) at IETF 71 (https://www3.ietf.org/proceedings/08mar/slides/smime-4.pdf) and this is the ID that provides a much more detailed technical description of PEC. Many at the meeting indicated they were willing to review - so please do and provide comments to the authors. spt -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Monday, June 30, 2008 6:30 PM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-gennai-smime-cnipa-pec-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Certified Electronic Mail Author(s) : F. Gennai, A. Shahin, C. Petrucci, A. Vinciarelli Filename : draft-gennai-smime-cnipa-pec-00.txt Pages : 62 Date : 2008-6-30 Since 1997, the Italian Laws have recognized electronic delivery systems as legally usable. After 2 years of technical tests, in 2005 the characteristics of an official electronic delivery service, named certified electronic mail (in Italian "Posta Elettronica Certificata") were defined, giving the system legal value. Design of the entire system was carried out by the National Center for Informatics in the Public Administration of Italy (CNIPA), followed by efforts for the implementation and testing of the service. The CNIPA has given the Italian National Research Council (CNR), and in particular The Institute of Information Science and Technologies at the CNR (ISTI), the task to run tests on providers of the service to guarantee the correct implementation and interoperability.This document describes the certified email system adopted in Italy. It represents the system as it is at the moment of writing, following the technical regulations that were written based upon the Italian Law DPR. November 2, 2005. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-gennai-smime-cnipa-pec-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------=_NextPart_000_0000_01C8DC62.01556AE0 Content-Type: Message/External-body; name="draft-gennai-smime-cnipa-pec-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-gennai-smime-cnipa-pec-00.txt" Content-Type: text/plain Content-ID: <2008-6-30151947.I-D@ietf.org> ------=_NextPart_000_0000_01C8DC62.01556AE0 Content-Type: text/plain; name="ATT00115.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT00115.txt" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ------=_NextPart_000_0000_01C8DC62.01556AE0-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m61HFGn6088073 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Jul 2008 10:15:16 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m61HFGsc088071; Tue, 1 Jul 2008 10:15:16 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m61HFDgk088041 for ; Tue, 1 Jul 2008 10:15:13 -0700 (MST) (envelope-from root@core3.amsl.com) Received: by core3.amsl.com (Postfix, from userid 0) id 6A9693A6BA1; Tue, 1 Jul 2008 10:15:00 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ietf-smime@imc.org Subject: I-D ACTION:draft-ietf-smime-3278bis-01.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080701171501.6A9693A6BA1@core3.amsl.com> Date: Tue, 1 Jul 2008 10:15:01 -0700 (PDT) Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS) Author(s) : S. Turner, D. Brown Filename : draft-ietf-smime-3278bis-01.txt Pages : 50 Date : 2008-7-1 This document describes how to use Elliptic Curve Cryptography (ECC) public-key algorithms in the Cryptographic Message Syntax (CMS). The ECC algorithms support the creation of digital signatures and the exchange of keys to encrypt or authenticate content. The definition of the algorithm processing is based on the ANSI X9.62 standard, developed by the ANSI X9F1 working group, the IEEE 1363 standard, and the SEC 1 standard. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-3278bis-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-smime-3278bis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-7-1101220.I-D@ietf.org> --NextPart-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m61HFEsG088060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Jul 2008 10:15:14 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m61HFEAF088058; Tue, 1 Jul 2008 10:15:14 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m61HFCmR088040 for ; Tue, 1 Jul 2008 10:15:13 -0700 (MST) (envelope-from root@core3.amsl.com) Received: by core3.amsl.com (Postfix, from userid 0) id 66C9E3A6B99; Tue, 1 Jul 2008 10:15:00 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ietf-smime@imc.org Subject: I-D ACTION:draft-ietf-smime-3851bis-04.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080701171501.66C9E3A6B99@core3.amsl.com> Date: Tue, 1 Jul 2008 10:15:01 -0700 (PDT) Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification Author(s) : B. Ramsdell, S. Turner Filename : draft-ietf-smime-3851bis-04.txt Pages : 46 Date : 2008-7-1 This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 3.2. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 3851. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-3851bis-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-smime-3851bis-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-7-1100110.I-D@ietf.org> --NextPart--