From owner-ietf-smime@mail.imc.org Mon Jun 2 13:22:19 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 460AE3A687D for ; Mon, 2 Jun 2008 13:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 YCdpSiWZdWBu for ; Mon, 2 Jun 2008 13:22:18 -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 EA4383A687B for ; Mon, 2 Jun 2008 13:22:17 -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 m52K1nNI029407 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Jun 2008 13:01: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 m52K1nPu029405; Mon, 2 Jun 2008 13:01:49 -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 smtp106.biz.mail.re2.yahoo.com (smtp106.biz.mail.re2.yahoo.com [206.190.52.175]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m52K1lN2029384 for ; Mon, 2 Jun 2008 13:01:48 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 38978 invoked from network); 2 Jun 2008 20:01:46 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@96.231.128.64 with login) by smtp106.biz.mail.re2.yahoo.com with SMTP; 2 Jun 2008 20:01:46 -0000 X-YMail-OSG: KOhLDoMVM1lxQNecY6O4htb1vCJgZAP3pcyYZa.qXufSr7TAAfPKT.CqNUURb9UuTmVUADiSCG2TYAE.zWSOErNGjIr5eDZ0YMZKq1FY3Q-- X-Yahoo-Newman-Property: ymail-3 From: "Turner, Sean P." To: "=?iso-8859-1?Q?'Alfred_H=CEnes'?=" , References: <200805211634.SAA16803@TR-Sys.de> Subject: RE: draft-ietf-smime-3850bis-02 (fwd) Date: Mon, 2 Jun 2008 16:01:42 -0400 Organization: IECA, Inc. Message-ID: <625EF9D4612F4D01B9F427CF37EF12EE@Wylie> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 Thread-Index: Aci7ZHmFwbths/PsSm6VTnmnlcDGFwJg23oQ In-Reply-To: <200805211634.SAA16803@TR-Sys.de> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alfred, Thanks for the review. Responses inline. spt >-----Original Message----- >(1) Conventions used ... > >a) I have not followed the progress of > draft-hoffman-additional-key-words, > but it looks like the evolution of that document might > be worth being monitored or coordinated with, in order > to avoid repeated re-specification of the new keywords. > >b) last paragraph: > > MUST- This term means the same as MUST. However, we >expect at some > point that this algorithm will no longer be a MUST in a future > document. [...] > >I'd give preference to the word-shuffled variant: > >| MUST- This term means the same as MUST. However, we >expect that at >| some point this algorithm will no longer be a MUST in a future > document. [...] We're following Paul's draft. I copied the text from Paul's ID so the text is now aligned. >(2) Section 2.2 > >Without explanation, the draft says: > > Receiving agents MUST support v1 X.509 and v3 X.509 identity > certificates as profiled in [KEYM]. [...] > >This comes to surprise. Why are v2 certificates excluded? > >The deliberations in RFC 5280 seem to make v1 much less preferable. > >If there ideed are reasons for this particular requirement, a >hint on the rationale would be useful. v1 is required for backwards compatibility. v2 isn't used because they add issuerUniqueIdentifier and subjectUniqueIdentifer - both of which were SHOULD NOT in RFCs 2459/3280 and are MUST NOT in RFC5280. >(3) Section 3 > >Below the ASN.1 fragment, please > > s/an upper bounds/an upper bound/ > ^ Fixed >(4) Section 4.3 > >The last paragraph says: > > A receiving agent MUST be capable of verifying the signatures on > certificates and CRLs with key sizes from 512 bits to 2048 bits. > >This requirement seems to be taylored to RSA/DSA key sizes, >but possibly not appropriate for the developing ECDSA context. > >To not inappropriately exclude shorter ECDSA key sizes and >request support for unusually large ECDSA key sizes, the above >statement should perhaps be restricted in scope. Matching the >algorithm support requirements in the earlier parts of 4.3, >but not precluding future more previce specification of ECDSA >use with PKIX, CMS, and S/MIME, I propose to amend the above >statement to say: > > vvvvvvvvvvvvv >| A receiving agent MUST be capable of verifying RSA and DSA >signatures > on certificates and CRLs with key sizes from 512 bits to 2048 bits. Somebody else also noted this. In the next version I added a table and noted that it's for RSA and DSA. >(5) Sections 6 > >The lenghty deliberations on MD2 in this section seem to be >aged, or almost historical now. Shouldn't there be some words >pointing out more recent developments, in particular the >perceived issues with / reduced confidence in MD5 (and perhaps >also SHA-1) as well? We're working on updating the security considerations section in both 3850bis/3851bis. I'm hoping to get the algorithm security considerations text agreed in 3850bis then we can also copy it to 3850bis. >(6) Appendix A > >It is very unusual to label these sections "Appendix". >I suggest to renumber "Appendix A" to "Section 7". This is historical and at this point I guess I'd like to leave the numbering alone so the sections align. If the RFC-editor complains then we'll change it. >"[RFC-2822]" is the only ref. tag used incorporating an RFC number. >I do not know the planned schedule, but it might happen that >2822-upd will be faster on the publication track, making a ref. >update necessary. To prepare for it, and to arrive at a more >homogenous ref. tag style, I suggest replacing "[RFC-2822]" >by "[IMF]". Changed it to IMF noted the work-in-progress. >For clerical completeness, I note the race condition that has >occurred by nearly concurrent publication events, making the >draft miss the ref. update: [KEYM] --> RFC 5280. Fixed From owner-ietf-smime@mail.imc.org Tue Jun 3 12:58: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 172393A6941 for ; Tue, 3 Jun 2008 12:58:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 eCPWioj4eYfH for ; Tue, 3 Jun 2008 12:58:10 -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 5E7473A67AD for ; Tue, 3 Jun 2008 12:58:09 -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 m53Jg4ZM053814 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Jun 2008 12:42: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 m53Jg41Z053813; Tue, 3 Jun 2008 12:42: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 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 m53Jg22a053806 for ; Tue, 3 Jun 2008 12:42:03 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 71823 invoked from network); 3 Jun 2008 19:42:02 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@96.231.124.17 with login) by smtp104.biz.mail.re2.yahoo.com with SMTP; 3 Jun 2008 19:42:02 -0000 X-YMail-OSG: 9syXZJoVM1nCPHOPwLg5HcaTDcxw2BNH9Yacfw0H1_mfpeWs1j8ReHHTvY3dnZKZTnSxS7zCZ3NgoomflOJaqNyMy4ywv6VKNKtrcxL_ob5KFPUeOgZUllgu7LhHUC37XnM- X-Yahoo-Newman-Property: ymail-3 From: "Turner, Sean P." To: References: <200805190921.LAA12918@TR-Sys.de> Subject: RE: draft-ietf-smime-3851bis-02 (notes, part 1) Date: Tue, 3 Jun 2008 15:41:54 -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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 Thread-Index: Aci6acDbQCzqJFdbSIqytOgr/nmchQKgdIGw In-Reply-To: <200805190921.LAA12918@TR-Sys.de> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alfred, Thanks for the review. Responses inline. All, Alfred suggests demoting UTCTime to a SHOULD- in his last comment. I think we should stay aligned with CMS/PKIX - curious what others think. spt >-----Original Message----- >(1) Conventions used ... > >- The RFC Editor will want to make that a proper (numbered) section. > I suggest to move it to between the current sub-sections 1.1 and 1.2. Fixed. >- The comments I sent on the same part of draft-ietf-smime-3850bis-02 > also apply. Fixed. >(2) Section 1 > >(2a) 1st paragraph > >For completeness (and matching of what is said in the >Abtract), I suggest to add a short note on message compression >to the end of the first paragraph of Section 1, for instance: > > As a supplementary service, S/MIME provides for message compression. Added the sentence. >(2b) 2nd paragraph > >Perhaps the most important usage scenario for S/MIME now is >bound to SIP (using the 'sips' URIs) to protect the >negotioation of multimedia session parameters (cf. RFC 3261). >Therefore, I suggest to replace in the second paragraph of >Section 1 the clause "such as HTTP" by "such as HTTP or SIP". Added the SIP reference. >(3) General -- terminology > >It has been generally recognized that the media type concept >defined in [MIME-SPEC] has outgrown the narrow context of >MIME, and RFC 4288 (BCP 13) has confirmed that the popular >sluggish term "MIME Type" >should not be used, in favor of the proper term "Media Type", >which already had been used throughout [MIME-SPEC]. > >Therefore, I recommend to also change in this draft all >occurrences of "MIME type" to "media type" (inclusive of the >title of Section 3.4.3.1). > >Also, when refering to MIME header fields, their names should >be quoted faithfully for clarity and precision; in particular, >the hyphen should always be included after "Content", e.g., > "Content type" --> "Content-type". Agreed >(4) Section 1.1 > >(4a) 1st paragraph > >The draft says: > > This document describes a protocol for adding cryptographic >signature > and encryption services to MIME data. The MIME standard [MIME-SPEC] >| provides a general structure for the content type of Internet >| messages and allows extensions for new content type applications. > >There are two issues with the use of "content type": > >- "structure of the content type" is a slight abuse of language; > "structure of content" is the proper designation. It does say "structure for the content type :) I changed it to ...structure for the content of Internet messages... >- "content type applications" seems to be vague and unclear. > I suggest to use "content type specific applications" or > "content type based applications" instead Choose the later >(4b) 2ns and 3rd paragraph > >Please apply (3) -- 3 occurrences. I did a search for MIME type and replaced them with media type >(5) Section 1.3 > >For clarity, please add another comma after the first instance >of "inclusive", or place this word in parentheses. I tweaked it a bit but I think it's fixed now. >(6) Section 1.4 > >(6a) section title > >The legacy section title obviously is outdated, turning it ambiguous. >It should better be changed: > > 1.4. Changes Since S/MIME v3 >--- >| 1.4. Changes From S/MIME v3 to S/MIME v3.1 > >This should properly complement the correctly entitled new section, > > 1.5. Changes Since S/MIME v3.1 Fixed >(6b) last two paragraphs > >Please apply (3) -- two occurrences. Fixed >(7) Section 1.5 -- typo > >Please replace "in parantheticals" by either "parenthetical" >or "in parenthesis". I deleted "in parantheticals" - it wasn't needed. >(7) Section 1.5 -- typo > >Please replace > vv v > "AES-CBC" in parantheticals. >by either: > parenthetical "AES-CBC". >or: > parenthetic "AES-CBC". >or: > "AES-CBC" in parenthesis. Accepted - I just removed the in parenthesis. >(8) Section 2 -- clarification of the role of [ESS] > >I suggest to add a note to the text in Section 2 clarifying >that RFC 2634 [ESS] is applicable for S/MIME v3.2 as well. > >This is intended to complement the remarks in Section 1.3 >stating that RFC 2634 is part of the S/MIME v3 and S/MIME v3.1 >specification. ESS gets pulled in in section 2.5 when discussing attributes. I did add text to address ESS in section 2. >(9) Section 2.3 > >Please replace > using rsaEncryption algorithm. >by either: > using the rsaEncryption algorithm. >or: > using rsaEncryption. Accepted >(10) Section 2.4.1 > >The draft says: > > vvvvvvvvvvvv > ... the MIME content MUST be stored in the SignedData > encapContentInfo eContent OCTET STRING ... > >This is misleading; the Content-Type has to be stored there, >not the "content". >In line with (3) above, I suggest to use the phrase: > > vvvvvvvvvvv >| ... the media type MUST be stored in the SignedData > encapContentInfo eContent OCTET STRING ... Accepted >(11) Section 2.4.4, 1st paragraph > >I suggest to insert the article "the" giving "reduce the message size". Accepted >(12) Section 2.5 > >(12a) 1st paragraph > >The draft says, using redundant/replicated wording: > > vvvvvvvvvvvvv > The SignerInfo type allows the inclusion of unsigned and signed > attributes to be included along with a signature. > ^^^^^^^^^^^^^^ >I suggest to simplify the wording to: > > The SignerInfo type allows the inclusion of unsigned and signed >| attributes along with a signature. > ^ Accepted >(12b) 2nd-to-last paragraph > >The draft says: > > [..]. Receiving agents SHOULD handle attributes or > values that it does not recognize in a graceful manner. > >The wording "receiving agents ... it does not" should be improved upon. >I suggest either to turn to singular: > > vv vv >| [..]. A Receiving agent SHOULD handle >attributes or > values that it does not recognize in a graceful manner. > >or substitute "they" in the last line: > > [..]. Receiving agents SHOULD handle attributes or >| values they do not recognize in a graceful manner. > ^^^^^^^ Accepted (used the 2nd one) >(13) Section 2.5.1 > >The rules for UTCTime vs. GeneralizedTime are unfortunate for >several reasons, as I have pointed out in recent comments on >RFC 5280. They violate the lessons learned during Y2K that >4 decimal digits should *always* be encoded for year numbers, >and they cause general non-exercising of 'MUST implement' >code, generating a new security risk. > >I strongly recommend to, at a minimum, demote the "MUST" to >encode signing-time through 2049 as UTCTime to a "MUST-", >preferably "SHOULD", to promote starting general migration to >GeneralizedTime. I think we should stay aligned with CMS & PKIX on this. But, I think we should add that receiving agents must support both UTCTime and GeneralizedTime. spt From owner-ietf-smime@mail.imc.org Tue Jun 3 13:26: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 CFFC83A67AD for ; Tue, 3 Jun 2008 13:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.224 X-Spam-Level: X-Spam-Status: No, score=-0.224 tagged_above=-999 required=5 tests=[AWL=-2.225, BAYES_50=0.001, SARE_RAND_1=2] 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 h3vSR1Ivl8mP for ; Tue, 3 Jun 2008 13:26:05 -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 2C85228C1E5 for ; Tue, 3 Jun 2008 13:22: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 m53JgGCM053852 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Jun 2008 12:42: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 m53JgGoa053851; Tue, 3 Jun 2008 12:42: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 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 m53JgFow053839 for ; Tue, 3 Jun 2008 12:42:15 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 75328 invoked from network); 3 Jun 2008 19:42:14 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@96.231.124.17 with login) by smtp105.biz.mail.re2.yahoo.com with SMTP; 3 Jun 2008 19:42:13 -0000 X-YMail-OSG: eywVsjMVM1ld2DGdWIpO5tvpWP3aKG20ApkLE1bNN23P.Hc8BK6uWNUm1mkJXqVDRTdMFez5Mb56N8op9dn8oeB72_0AraYtU77vqLD91HYgJ5lxGTwAH6KO9u0XURuGS7500UOJh87Mlbdu.gszNzyp X-Yahoo-Newman-Property: ymail-3 From: "Turner, Sean P." To: References: <200805201421.QAA14861@TR-Sys.de> Subject: RE: draft-ietf-smime-3851bis-02 (notes, part 2) Date: Tue, 3 Jun 2008 15:42:06 -0400 Organization: IECA, Inc. Message-ID: <2F75B5E58B954B87B7814C09AE730F1A@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: Aci6hPPfZipj3DO/Rqei+xwSrAK2ugKasBDA In-Reply-To: <200805201421.QAA14861@TR-Sys.de> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alfred, Thanks again for the review. Responses inline. In the version I'm about to post I haven't addressed comment (0) or (29). All, Curious what others feel about (0) and (29). spt >-----Original Message----- >(0) Front Matter / Standards Actions > >The draft already indicates in its front matter: > Obsoletes: 3851 > >During supporting investigations, it became clear that, due to >specific circumstances, this will let us end up with two "valid" >sets of S/MIME specifications -- those for S/MIME v3.2 and >those for S/MIME v2 ! > >The historic reason for this scenario seems to be buried in >the S/MIME v2 specifications being published as Informational >RFCs and not expressly being Obsoleted by the S/MIME v3 RFCs. > >In Section 1.3, this draft lists RFCs 2311 through 2315 as the >documents originally specifying S/MIME v2. In the RFC index, >the entries for all these RFCs list INFORMATIONAL status, > - RFC 2313 is tagged (Obsoleted by RFC2437), > - RFC 2314 is tagged (Obsoleted by RFC2986), but > - RFCs 2311, 2312, and 2315 look like being current. > >Arguably, it would be a matter of CMS to take action for RFC >2315, but at least RFC 2311 and RFC 2312 are clearly within >scope of the S/MIME v3.2 drafts. > >I suggest to take the opportunity to clean up the RFC metadata >and either: > > - also formally Obsolete the S/MIME v2 RFCs with the publication > of the corresponding intended S/MIME v3.2 RFCs, > (i.e. add RFC 2311 to the Obsoletes list of this draft, > add RFC 2312 to the Obsoletes list of [CERT32], and > defer action for RFC 2315 to CMS), or > > - to explicitely declare the S/MIME v2 RFCs as Historic in one place. We should address this one coment (0) and (25) togther seperately. >(14) Section 2.5.3.1 > >The second bullet there says: > > - If an SMIMEEncryptionKeyPreference attribute is not found in a > SignedData object received from the desired recipient, the set of > X.509 certificates SHOULD be searched for a X.509 certificate >| with the same subject name as the signing of a X.509 certificate > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >| which can be used for key management. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >I really do not understand precisely what the last two lines >want to say. Please clean up and clarify. > > >(15) Section 2.7.1.2 > >The visible paragraph structure there is broken; the section >looks like: > > If the following two conditions are met: > > - ... > > - ... > > [[end of section]] > >More closely looking at the text, it turns out that >fortunately the situation can be cured by inserting a >paragraph break in the second bullet. For grammatical >consistency, also the initial capitalization of the bullets >should be changed. > >Thus, the section should be changed to: > > If the following two conditions are met: > > - the sending agent has no knowledge of the encryption capabilities > of the recipient; and, > > - the sending agent has no knowledge of the version of >S/MIME of the > recipient, > > then the sending agent SHOULD use AES 128 because it is a stronger > algorithm and is required by S/MIME v3.2. If the sending agent > chooses not to use AES 128 in this step, it SHOULD use tripleDES. > >Additionally, the punctuation at the end of the first bullet now could >be easily simplified: s/; and,/, and/ Accepted >(16) Section 3.1 ff. -- terminological issues > >Being a designated Standards Track document, the draft should >precisely use established IETF terminology and not >occasionally fall back to common, yet sluggish (ab)use of the >terms regarding the Internet message structure. > >Section 3.1.1 of RFC 4249 summarizes the terms established in >the Internet Mail and MIME RFCs, which I will explain again in my own >words: > > - at each conceptual protocol layer, a protocol data unit is > comprised of a header and a payload (i.e., the "body" in textual > protocols like email), and sometimes a trailer, as well; > > - the header within a protocol layer is comprised of header fields. > > Thus, each Internet (email) message has a single message header > (Section 2.1 of I-D.2822-upd now even uses the term "message header > section"). > In a structured MIME message body, each nesting level has a single > "MIME header", "MIME entity header", or "MIME part header" of its > own (cf. RFC 2045). > (We are not interested in lower level details, like MIME prologue > and epilogue, etc., for the purpose of this draft.) > > Each message header or MIME header is comprised of header fields, > with in turn consist of a field name, the colon separator, and a > field value. > > At the MIME top level, the MIME-related header fields are > integrated in the RFC[2]822 message header; they sometimes > collectively are denoted as the "MIME message header". > >Furthermore, as explained in BCP 13, RFC 4288, the IETF should >not use the popular term "MIME type", in favor of "media type". >The former had not even been defined in [MIME-SPEC], and it >has become even more misleading with the spread of other >protocols making use of these media types. > >I strongly recommend to update the draft to always use this >precise terminology. > >As a side-show, I also recommend consistently using the same >spelling and capitalization for header field names -- >preferably the spelling and case used in the original document >defining the header field --, e.g., replace "content type" and >"Content type" by "Content-Type". > >Because there are some subtle cases, I try to address most >affected instances of these issues I found in the draft text >in detail below. Agree >(17) Section 3.1 -- details > >(17a) 1st paragraph > >Applying the rationale of (16), I suggest to change (also >deleting the repeated second "used" near the end of the third >sentence, to streamline the language a bit): > > S/MIME is used to secure MIME entities. A MIME entity can be a sub- > part, sub-parts of a message, or the whole message with all its sub- > parts. A MIME entity that is the whole message includes only the >| MIME headers and MIME body, and does not include the >RFC-822 headers. > ^ ^ vvvvvv ^ >| Note that S/MIME can also be used to secure MIME entities used in > applications other than Internet mail. If protection of the RFC-822 >| headers is required, the use of the message/rfc822 MIME type is > explained later in this section. >--- ^^^^ > S/MIME is used to secure MIME entities. A MIME entity can be a sub- > part, sub-parts of a message, or the whole message with all its sub- > parts. A MIME entity that is the whole message includes only the >| MIME message headers and MIME body, and does not include >the RFC-822 >| header. Note that S/MIME can also be used to secure MIME entities in > applications other than Internet mail. If protection of the RFC-822 >| header is required, the use of the message/rfc822 media type is > explained later in this section. Accepted >(17b) 1st paragraph below 'Step 3.' > >Please remove the comma after "where" -- or put it in front of >that "where". Deleted the comma >(17c) 2nd paragraph below 'Step 3.' > >Correcting a typo and applying (16), I suggest to change: > >| In order to protect outer, non-content related message headers (for > v v ^^^^^^^ >| nstance, the "Subject", "To", "From" and "CC" fields), the sending > client MAY wrap a full MIME message in a message/rfc822 wrapper in >| order to apply S/MIME security services to these headers. It is up > ^^^^^^^ >| to the receiving client to decide how to present these "inner" > ^^^^^ >| headers along with the unprotected "outer" headers. >--- ^ ^ >| In order to protect outer, non-content related message >header fields >| (for instance, the "Subject", "To", "From" and "Cc" fields), the > sending client MAY wrap a full MIME message in a message/rfc822 >| wrapper in order to apply S/MIME security services to these header >| fields. It is up to the receiving client to decide how to present >| this "inner" header along with the unprotected "outer" header. Accepted >(18) Section 3.1.1, 2nd paragraph > >According to (16), please s/MIME type/media type/ (2x). I only found one. >(19) Section 3.1.2 > >According to (16): > > [...] If no Content-Transfer-Encoding header is > present, the transfer encoding is presumed to be 7BIT. >--- vvvvvv >| [...] If no Content-Transfer-Encoding >header field is > present, the transfer encoding is presumed to be 7BIT. Accepted >(20) Section 3.1.4 > >The legacy example of BITNET seems to be rather aged and of >very low interest -- if any; cf. http://en.wikipedia.org/wiki/BITNET . > >I therefore suggest to simply delete " (like BITNET)" While aged it is part of an example so I think we can leave it. >(21) Section 3.2 > >(21a) section title > >For added precision and consistency, I suggest to add "Media" >in front of "Type" -- cf. 3.4.3.1, discussed in (2x) below: > > 3.2. The application/pkcs7-mime Type >--- > 3.2. The application/pkcs7-mime Media Type Accepted >(21b) 3rd paragraph > >According to (16), please s/MIME type/media type/ (1x). > >(21c) last paragraph > >For added precision, and with respect to (16), the last >sentence should be amended: > >| [...]. The MIME headers of all > application/pkcs7-mime objects SHOULD include the optional "smime- > type" parameter, as described in the following sections. >--- >| [...]. The Content-Type header >| field of all application/pkcs7-mime objects SHOULD include the > optional "smime-type" parameter, as described in the following > sections. Accepted >(22) Section 3.2.1, last paragraph > >According to (16), please s/MIME type/media type/ (1x), and > s/MIME types/media types/ (1x). Fixed >(23) Section 3.2.2, last numbered bullet > >Please correct punctuation and case: > vvvv >| 3. If no common string is assigned. Then the common string of > "OID." is recommended (for example, "OID.1.3.6.1.5.5.7.6.1" > would be DES40). >--- vvv >| 3. If no common string is assigned, then the common string of > "OID." is recommended (for example, "OID.1.3.6.1.5.5.7.6.1" > would be DES40). Accepted >(24) Section 3.4.3 > >According to (16), please s/MIME type/media type/ (2x). Fixed >(25) Section 3.4.3.1 > >(25a) section title > >With respect to (16) please change: > > 3.4.3.1. The application/pkcs7-signature MIME Type >--- > 3.4.3.1. The application/pkcs7-signature Media Type > ^^^^^ > >(25b) 1st paragraph > >According to (16), please s/MIME type/media type/ (1x). Accepted >(26) Section 3.4.3.2 > >(26a) 1st paragraph below 'Step 5' > >Please adjust: > vv >| The multipart/signed Content type has two required parameters: the > protocol parameter and the micalg parameter. >--- vv >| The multipart/signed Content-Type has two required parameters: the > protocol parameter and the micalg parameter. Accepted >(26b) last paragraph: > >The draft says: > >| The SHA-224 algorithm [SHA224] and SHA-384 and SHA-512 algorithms > [FIPS180-3] are not currently recommended in S/MIME, and >are included > here for completeness. > >There's an apparent disparity. SHA-224 is also covered by >FIPS 180-3, and SHA-384 as well as SHA-512 are also covered by >RFC 4634 not even listed as a Reference. Perhaps this has >historical reasonse related to the delayed introduction of >SHA-224 via a Change Notice to FIPS 180-2. > >Since the requirements statement is "not recommended", adding >a bulk of references might be overkill; the basic Ref. should suffice. >Thus, I suggest to drop [SHA224] and simplify the language: > >| The SHA-224, SHA-384, and SHA-512 algorithms [FIPS180-3] are not > currently recommended in S/MIME, and are included here for > completeness. Accepted and I deleted the [SHA224] reference >(27) Setcion 3.9 > >(27a) 2nd paragraph > >According to (16), please change: > > The file suffix in the table below comes from the "name" >parameter in >| the content-type header, or the "filename" parameter on the content- > v ^ ^ vv ^^ ^ >| disposition header. These parameters that give the file suffix are > not listed below as part of the parameter section. >--- > The file suffix in the table below comes from the "name" >parameter in >| the Content-Type header field, or the "filename" parameter on the >| Content-Disposition header field. These parameters that give the > file suffix are not listed below as part of the parameter section. Accepted >(27b) table > >According to (16), please s/MIME type/media type/ (3x). Accepted >(28) Section 4.1 > >The draft says: > > All generated key pairs MUST be generated from a good source of non- > deterministic random input [RANDOM] and the private key MUST be > protected in a secure fashion. > >IMO, this 'MUST' requirement constitutes a *Normative* >Reference; so please promote '[RANDOM]' to Normative, moving >the entry from >B.2 to B.1. Agreed >(29) Section 5 > >Independent on the decision to be made regarding (0) above, >this section needs to be amended. > >(29a) Scenario 1: RFC 2311 *not* Obsoleted / made HISTORIC > >In this case, IANA should at least be directed to update the >media type registrations for > > "application/pkcs7-mime" >and > "application/pkcs7-signature" > >by adding an additional reference to [RFCTHIS], in order to >point the reader to the most current update of the media type >information. > >On the other hand, updating an old media type's information >arguably could require updating the registration entirely, >using the new registration template from BCP 13, RFC 4288. > >I leave it to the high priests of exegesis (or lawyers) to >figure out whether RFC 4288 in fact even normatively requests to do so. > >(29b) Scenario 2: RFC 2311 beinf Obsoleted or made HISTORIC > >In this case, the draft should substantially be amended with >the two new media type registration templates, filled for both >media types, "application/pkcs7-mime" and >"application/pkcs7-signature", and IANA should be directed to >update the registrations to incorporate this new information. Address this with (0). >(30) Section 6, 7th paragraph > >I suggest to make the statement on key size more specific >(again, to not interfere with the future addition of other >signing algorithms having other key size requirements), and to >correct the placement of hyphens, as follows: > > Some S/MIME agents created in the United States have chosen >to create >| 512 bit keys in order to get more advantageous export licenses. >| However, 512 bit keys are considered by many to be cryptographically > insecure. >--- > Some S/MIME agents created in the United States have chosen >to create >| 512-bit RSA keys in order to get more advantageous export licenses. > ^ ^^^^ v vvvv >| However, 512-bit RSA keys are considered by many to be > cryptographically insecure. This paragraph got overtaken by events. >(31) Appendix A > >(31a) general > >At first glance, it comes to surprise that there's a "~~V3dot1" >ASN.1 module. > >For clarity, I suggest adding an introductory statement >indicating that this module has been taken essentially >unchanged from RFC 3851 and still applies to S/MIME v3.2. Since there are no changes listed in Section 1.6 it would be clear but I added the NOTE anyway and the corresponding informative reference to MSG3.1. >(31b) ASN.1 comment below id-cap OID definition > >I suggest to improve the language a bit, by inserting "OID": > > -- The preferBinaryInside indicates an ability to receive messages > -- with binary encoding inside the CMS wrapper >--- vvvvv > -- The preferBinaryInside OID indicates an ability to receive > -- messages with binary encoding inside the CMS wrapper. Accepted >(32) Appendix B > >[ Interestingly, the last item for v3.2 happens to be #32 :-) ] > >(32a) section numbering > >The RFC Editor prefers References as a numbered section, not >as an Appendix. Therefore, I suggest to shuffle the >Appendices and turn this one into Section 7. I guess I'm going to leave this one alone like I did in 3850bis. >(32b) B.1, [FIPS180-3] { oooops } > vvvvvvvvvvv > [FIPS180-3] "Secure Hash Signature Standard (SHS)", National > Institute of Standards and Technology (NIST). FIPS > Publication 180-3. >--- >| [FIPS180-3] "Secure Hash Standard (SHS)", National Institute of > Standards and Technology (NIST), FIPS Publication >| 180-3, June 2007. > ^^^^^^^^^^^ >or better, listing the source first (as also done for ITU-T documents): > >| [FIPS180-3] National Institute of Standards and Technology (NIST), >| "Secure Hash Standard (SHS)", FIPS Publication 180-3, >| June 2007. Fixed >(32c) B.2, [RANDOM] > >Please add "BCP 106, " in front of "RFC 4086". >regarding eventual promotion to Normative, please see item (28) above. Fixed From owner-ietf-smime@mail.imc.org Tue Jun 3 15:41: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 6B57A3A6CBA for ; Tue, 3 Jun 2008 15:41:51 -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 ZhR9z6It2q-L for ; Tue, 3 Jun 2008 15:41: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 E2D6B3A6CF1 for ; Tue, 3 Jun 2008 15:38: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 m53MKDWd091369 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Jun 2008 15:20:13 -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 m53MKDha091368; Tue, 3 Jun 2008 15:20:13 -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 m53MKCMM091351 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 3 Jun 2008 15:20:13 -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 m53MNj7C028367 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 3 Jun 2008 15:23:45 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sendmail.com; s=ladle.dkim; t=1212531825; bh=ht3qW2wVX7rl1GWBI7Dmty5YUZ0IA32kpHdP p8aPYoo=; 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=dzpLHd hNS777G4buIfcmEwsAfqGPDyRj1uCogo+i2QoknDBixwfq7LYLvEiOL12klg2/Ql+fM ELkiD/X9MYeun0qvKWYur8dUFBXK8sPqq6Wtwqu1jSuJldFjfFV/c2WV5t/YQyg3RFQ y9RayH1jaJctL2Xvs3y5FwUKcXCLKNo= 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 m53MJu5d028831 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Jun 2008 15:20:02 -0700 X-DKIM: Sendmail DKIM Filter v2.2.3 spork.sendmail.com m53MJu5d028831 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sendmail.com; s=spork.dkim; t=1212531605; bh=ht3qW2wVX7rl1GWBI7Dmty5YUZ0IA32kpHdP p8aPYoo=; 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=GK6yCdWnx+o7jOxzb/ny1BuUq7LS59ZfqbJ026 8CUfI23EQcVz7ukgf3lCkFwAErjX1SzIWH0UpaVrbebMNqw39S521QHa8TdpRPtskts bAWQvpQCF8TJseVvMX51ig0AihskDWI6SJXbUEtZzuUjY1Fm5UUtPHnN5DrS55gCms= Date: Tue, 3 Jun 2008 15:20:13 -0700 From: Blake Ramsdell To: "Turner, Sean P." Cc: ietf-smime@imc.org Subject: Re: draft-ietf-smime-3851bis-02 (notes, part 1) Message-ID: <20080603222011.GA2406@dell-desktop.example.com> References: <200805190921.LAA12918@TR-Sys.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-MM-Ex-RefId: 149371::080603152003-1AEDCB90-10316A73/0-0/0-1 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, Jun 03, 2008 at 03:41:54PM -0400, Turner, Sean P. wrote: > Alfred suggests demoting UTCTime to a SHOULD- in his last comment. I think > we should stay aligned with CMS/PKIX - curious what others think. Either UTCTime or GeneralizedTime needs to be a MUST in order for implementations to be compatible with each other. Have the historical problems with UTCTime (now that we're almost nine years into the 2000's) been that much of an issue? The migration to GeneralizedTime is already in place. We have addressed the expressed concern of the two digit ambiguity already. I think it's fine as is. Blake From owner-ietf-smime@mail.imc.org Tue Jun 3 19:02: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 E3FAB3A6BF1 for ; Tue, 3 Jun 2008 19:02:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.768 X-Spam-Level: X-Spam-Status: No, score=-99.768 tagged_above=-999 required=5 tests=[AWL=-1.416, BAYES_00=-2.599, FH_HAS_XAIMC=2.696, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1, 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 T8ZC8bXmY0to for ; Tue, 3 Jun 2008 19:02:19 -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 1CA3B3A6807 for ; Tue, 3 Jun 2008 19:02: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 m541meZ0040204 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Jun 2008 18:48:41 -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 m541mesH040202; Tue, 3 Jun 2008 18:48: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 people.com.cn ([202.99.23.227]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m541mbEP040185 for ; Tue, 3 Jun 2008 18:48:39 -0700 (MST) (envelope-from iesg-secretary@ietf.org) Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm3548464076; Wed, 04 Jun 2008 10:02:01 +0800 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm1448413845; Sat, 31 May 2008 16:01:26 +0800 Received: from mail.ietf.org([64.170.98.32]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm6b483c2d8f; Tue, 27 May 2008 22:00:18 +0800 Received: from mail.ietf.org([64.170.98.32]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Tue, 27 May 2008 22:00:16 +0800 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A82643A6C41; Tue, 27 May 2008 06:44:07 -0700 (PDT) X-Original-To: ietf-announce@ietf.org Delivered-To: ietf-announce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 6DA9F3A692C; Tue, 27 May 2008 06:44:05 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Subject: Protocol Action: 'Multiple Signatures in S/MIME' to Proposed Standard Message-Id: <20080527134405.6DA9F3A692C@core3.amsl.com> Date: Tue, 27 May 2008 06:44:05 -0700 (PDT) Cc: Internet Architecture Board , smime chair , smime mailing list , RFC Editor X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.9 List-Id: IETF Announcements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-AIMC-AUTH: (null) X-AIMC-MAILFROM: ietf-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: iesg-secretary@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: iesg-secretary@ietf.org X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG has approved the following document: - 'Multiple Signatures in S/MIME ' as a Proposed Standard This document is the product of the S/MIME Mail Security Working Group. The IESG contact persons are Tim Polk and Pasi Eronen. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-multisig-05.txt Technical Summary CMS SignedData includes the SignerInfo structure to convey per-signer information. SignedData supports multiple signers and multiple signature algorithms per-signer with multiple SignerInfo structures. If a signer attaches more than one SignerInfo, there are concerns that an attacker could perform a downgrade attack by removing the SignerInfo(s) with the 'strong' algorithm(s). This document defines the multiple-signatures attribute, its generation rules, and its processing rules to allow signers to convey multiple SignerInfo while protecting against downgrade attacks. Additionally, this attribute may assist during periods of algorithm migration. Working Group Summary This ID was discussed on the smime mailing list and at several IETF meetings. Initially, there was some confusion about the problem being solved but moving the general attacks against CMS hashes text to an Appendix addressed the WG's concerns. This initial confusion has really been the only major issue. Document Quality This document is new and there are no implementations - yet. There has been interest from multiple vendors about when it will be published as an RFC. Personnel Blake Ramsdell is the document Shepherd. Tim Polk is the responsible Security Area AD. RFC Editor Note Please make the following changes: a) Please remove the "Discussion" section preceding the Table of Contents. b) Please replace all occurrences of "pkcs9(9)" with "pkcs-9(9)". c) In section 2 list item 1), please make the following substitution OLD If both SignerInfo objects are not present, the relying party can easily determine that another SignerInfo has been removed. NEW Relying parties can easily determine that a SignerInfo has been removed if another SignerInfo contains a multi-sig attribute that refers to it. d) In section 8.1, Normative References, please make the following substitution: OLD [PROFILE] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002. NEW [PROFILE] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce From owner-ietf-smime@mail.imc.org Wed Jun 4 01:50:23 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 797473A6939 for ; Wed, 4 Jun 2008 01:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.494 X-Spam-Level: X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] 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 icIUKtwBuq0u for ; Wed, 4 Jun 2008 01:50: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 C79FD3A6934 for ; Wed, 4 Jun 2008 01:50:20 -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 m548avgA043978 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Jun 2008 01:36: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 m548avDd043977; Wed, 4 Jun 2008 01:36: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 UKCRN08.crn.thales-esecurity.com ([193.112.44.5]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m548atOB043960 for ; Wed, 4 Jun 2008 01:36:56 -0700 (MST) (envelope-from Nick.Pope@thales-esecurity.com) Received: by webmail.thales-esecurity.com with Internet Mail Service (5.5.2653.19) id ; Wed, 4 Jun 2008 09:36:53 +0100 Message-ID: <6FC9E49ED3472043A38619BFA97F37B5018746B1@webmail.thales-esecurity.com> From: "Pope, Nick" To: "'Pavel V. Smirnov'" , ESI@LIST.ETSI.ORG, ietf-smime@imc.org Subject: RE: Extending CAdES to support usual signature upgrading to CAdES -T and further Date: Wed, 4 Jun 2008 09:36:50 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8C61E.2203C4D0" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C8C61E.2203C4D0 Content-Type: text/plain Pavel, I personally have some sympathy for your view. I will add this issue to those for discussion at the next ETSI meeting later in June. Nick -----Original Message----- From: Pavel V. Smirnov [mailto:spv@cryptopro.ru] Sent: 26 May 2008 11:50 To: 'Pope, Nick'; ESI@LIST.ETSI.ORG; ietf-smime@imc.org Subject: Extending CAdES to support usual signature upgrading to CAdES-T and further Hello all and personally Nick, In current CAdES wording a regular signature without at least one signed attribute (Signing certificate reference) cannot be added with timestamps and validation data to achieve CAdES-T or more advanced CAdES signature. This need arises, e.g., in a system with existing regular signatures. There is no chance to add the required attribute to the already computed signature, but there is a strong need to add CAdES properties to such signatures. There is rather simple approach to achieve the same properties without including signing certificate reference as a signed attribute. Let us include this reference as an extension in the CAdES-T timestamp (signature timestamp). To get such timestamp one would need to include this extension in a timestamp request and a TSA would have to shift this extension to a timestamp token. Let us define the proposed extension to a timestamp protocol and call the signature we get a valid CAdES-T signature. More advanced CAdES signature types turn out from this new CAdES-T perfectly without any modification. What do you think? Pavel Smirnov Crypto-Pro Tel./Fax: +7 495 780-4820 WWW: http://www.CryptoPro.ru e-mail: spv@CryptoPro.ru Consider the environment before printing this mail. "Thales e-Security Limited is incorporated in England and Wales with company registration number 2518805. Its registered office is located at 2 Dashwood Lang Road, The Bourne Business Park, Addlestone, Nr. Weybridge, Surrey KT15 2NX. The information contained in this e-mail is confidential. It may also be privileged. It is only intended for the stated addressee(s) and access to it by any other person is unauthorised. If you are not an addressee or the intended addressee, you must not disclose, copy, circulate or in any other way use or rely on the information contained in this e-mail. Such unauthorised use may be unlawful. If you have received this e-mail in error please delete it (and all copies) from your system, please also inform us immediately on +44 (0)1844 201800 or email postmaster@thales-esecurity.com. Commercial matters detailed or referred to in this e-mail are subject to a written contract signed for and on behalf of Thales e-Security Limited". ------_=_NextPart_001_01C8C61E.2203C4D0 Content-Type: text/html

Pavel,

 

I personally have some sympathy for your view.  I will add this issue to those for discussion at the next ETSI meeting later in June.

 

Nick

 

 

-----Original Message-----
From: Pavel V. Smirnov [mailto:spv@cryptopro.ru]
Sent: 26 May 2008 11:50
To: 'Pope, Nick'; ESI@LIST.ETSI.ORG; ietf-smime@imc.org
Subject: Extending CAdES to support usual signature upgrading to CAdES-T and further

 

Hello all and personally Nick,

 

In current CAdES wording a regular signature without at least one signed attribute (Signing certificate reference) cannot be added with timestamps and validation data to achieve CAdES-T or more advanced CAdES signature. This need arises, e.g., in a system with existing regular signatures. There is no chance to add the required attribute to the already computed signature, but there is a strong need to add CAdES properties to such signatures.

 

There is rather simple approach to achieve the same properties without including signing certificate reference as a signed attribute. Let us include this reference as an extension in the CAdES-T timestamp (signature timestamp). To get such timestamp one would need to include this extension in a timestamp request and a TSA would have to shift this extension to a timestamp token.

 

Let us define the proposed extension to a timestamp protocol and call the signature we get a valid CAdES-T signature. More advanced CAdES signature types turn out from this new CAdES-T perfectly without any modification. What do you think?

 

Pavel Smirnov

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

 

Consider the environment before printing this mail.

"Thales e-Security Limited is incorporated in England and Wales with company registration number 2518805. Its registered office is located at 2 Dashwood Lang Road, The Bourne Business Park, Addlestone, Nr. Weybridge, Surrey KT15 2NX.

The information contained in this e-mail is confidential. It may also be privileged. It is only intended for the stated addressee(s) and access to it by any other person is unauthorised. If you are not an addressee or the intended addressee, you must not disclose, copy, circulate or in any other way use or rely on the information contained in this e-mail. Such unauthorised use may be unlawful. If you have received this e-mail in error please delete it (and all copies) from your system, please also inform us immediately on +44 (0)1844 201800 or email postmaster@thales-esecurity.com. Commercial matters detailed or referred to in this e-mail are subject to a written contract signed for and on behalf of Thales e-Security Limited".

------_=_NextPart_001_01C8C61E.2203C4D0-- From owner-ietf-smime@mail.imc.org Wed Jun 4 01:54:56 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 B691D3A6C57 for ; Wed, 4 Jun 2008 01:54:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.494 X-Spam-Level: X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] 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 HmnkxGkyUL7b for ; Wed, 4 Jun 2008 01:54:55 -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 268BE3A6CA4 for ; Wed, 4 Jun 2008 01:54:41 -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 m548UUsf041967 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Jun 2008 01:30:30 -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 m548UUon041964; Wed, 4 Jun 2008 01:30:30 -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 UKCRN08.crn.thales-esecurity.com ([193.112.44.5]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m548URA8041939 for ; Wed, 4 Jun 2008 01:30:28 -0700 (MST) (envelope-from Nick.Pope@thales-esecurity.com) Received: by webmail.thales-esecurity.com with Internet Mail Service (5.5.2653.19) id ; Wed, 4 Jun 2008 09:30:24 +0100 Message-ID: <6FC9E49ED3472043A38619BFA97F37B5018746B0@webmail.thales-esecurity.com> From: "Pope, Nick" To: "'Pavel V. Smirnov'" , ESI@LIST.ETSI.ORG, ietf-smime@imc.org Subject: RE: CAdES. Storing validation data. Date: Wed, 4 Jun 2008 09:30:20 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8C61D.39C7B640" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C8C61D.39C7B640 Content-Type: text/plain Pavel, Apologies for the delay in responding. I think this area requires some consideration, and will bring it up with other related TS 101 733 issues at the next ESI meeting later this month. Nick -----Original Message----- From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Pavel V. Smirnov Sent: 26 May 2008 11:50 To: 'Pope, Nick'; ESI@LIST.ETSI.ORG; ietf-smime@imc.org Subject: CAdES. Storing validation data. Hello all and personally Nick, I want to draw your attention to the following problem. There is only limited possible transformation between CAdES-X Type 1 signature and CAdES-X Long Type 1 signature. Notably, one must store certificate and revocation values for signature-timestamp validation in the timestamp itself, hence, after receiving CAdES-C-timestamp one cannot add or remove these values from signature-timestamp. An obvious solution is to allow to include timestamp validation data in certificate-values and revocation-values attributes of the signature itself. What do you think? Pavel Smirnov Crypto-Pro Tel./Fax: +7 495 780-4820 WWW: http://www.CryptoPro.ru e-mail: spv@CryptoPro.ru Consider the environment before printing this mail. "Thales e-Security Limited is incorporated in England and Wales with company registration number 2518805. Its registered office is located at 2 Dashwood Lang Road, The Bourne Business Park, Addlestone, Nr. Weybridge, Surrey KT15 2NX. The information contained in this e-mail is confidential. It may also be privileged. It is only intended for the stated addressee(s) and access to it by any other person is unauthorised. If you are not an addressee or the intended addressee, you must not disclose, copy, circulate or in any other way use or rely on the information contained in this e-mail. Such unauthorised use may be unlawful. If you have received this e-mail in error please delete it (and all copies) from your system, please also inform us immediately on +44 (0)1844 201800 or email postmaster@thales-esecurity.com. Commercial matters detailed or referred to in this e-mail are subject to a written contract signed for and on behalf of Thales e-Security Limited". ------_=_NextPart_001_01C8C61D.39C7B640 Content-Type: text/html

Pavel,

 

Apologies for the delay in responding.

 

I think this area requires some consideration, and will bring it up with other related TS 101 733 issues at the next ESI meeting later this month.

 

Nick

 

 

-----Original Message-----
From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Pavel V. Smirnov
Sent: 26 May 2008 11:50
To: 'Pope, Nick'; ESI@LIST.ETSI.ORG; ietf-smime@imc.org
Subject: CAdES. Storing validation data.

 

Hello all and personally Nick,

 

I want to draw your attention to the following problem.

 

There is only limited possible transformation between CAdES-X Type 1 signature and CAdES-X Long Type 1 signature. Notably, one must store certificate and revocation values for signature-timestamp validation in the timestamp itself, hence, after receiving CAdES-C-timestamp one cannot add or remove these values from signature-timestamp.

 

An obvious solution is to allow to include timestamp validation data in certificate-values and revocation-values attributes of the signature itself. What do you think?

 

Pavel Smirnov

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

 

Consider the environment before printing this mail.

"Thales e-Security Limited is incorporated in England and Wales with company registration number 2518805. Its registered office is located at 2 Dashwood Lang Road, The Bourne Business Park, Addlestone, Nr. Weybridge, Surrey KT15 2NX.

The information contained in this e-mail is confidential. It may also be privileged. It is only intended for the stated addressee(s) and access to it by any other person is unauthorised. If you are not an addressee or the intended addressee, you must not disclose, copy, circulate or in any other way use or rely on the information contained in this e-mail. Such unauthorised use may be unlawful. If you have received this e-mail in error please delete it (and all copies) from your system, please also inform us immediately on +44 (0)1844 201800 or email postmaster@thales-esecurity.com. Commercial matters detailed or referred to in this e-mail are subject to a written contract signed for and on behalf of Thales e-Security Limited".

------_=_NextPart_001_01C8C61D.39C7B640-- From owner-ietf-smime@mail.imc.org Wed Jun 4 07:15: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 445B928C117 for ; Wed, 4 Jun 2008 07:15:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3WzYOoI4xtAb for ; Wed, 4 Jun 2008 07:15:23 -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 AB08228C10A for ; Wed, 4 Jun 2008 07:15:22 -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 m54DrF4B025273 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Jun 2008 06:53:15 -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 m54DrFZ2025272; Wed, 4 Jun 2008 06:53:15 -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 prospect.joyent.us (prospect.joyent.us [8.12.36.36]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m54DrDNh025250; Wed, 4 Jun 2008 06:53:13 -0700 (MST) (envelope-from pmhesse@geminisecurity.com) Received: from PeterVT43 (static-68-163-72-26.res.east.verizon.net [68.163.72.26]) by prospect.joyent.us (Postfix) with ESMTP id 07AF288883; Wed, 4 Jun 2008 13:53:11 +0000 (GMT) From: "Peter Hesse" To: "'pkix'" , Subject: Web-based ASN.1 decoding tool available Date: Wed, 4 Jun 2008 09:53:10 -0400 Message-ID: <50a001c8c64a$543e55b0$fcbb0110$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_50A1_01C8C628.CD2CB5B0" X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcjGSlK0B56RJ/K4QmuS9tqZTIyH0A== Content-Language: en-us Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. ------=_NextPart_000_50A1_01C8C628.CD2CB5B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit All, We have recently made available a web-based tool for doing an ASN.1 dump. It displays the ASCII HEX and the ASN structure, and when you hover over the structure, it highlights the relevant portion of the hex. (Clicking makes the highlight stick.) Due to PHP's inefficiency and memory usage during parsing, we have limited it to files 64K and smaller. Still, it is useful for displaying smaller objects when you don't have dumpasn1 installed or available. It can be found here: http://geminisecurity.com/features-downloads/tools#fd_5 Click on "Click to try the application" under PHPdumpASN. Enjoy! Please send me any feedback. --Peter Hesse _____ Peter Hesse pmhesse@geminisecurity.com Phone: 703-378-5808 x105 Gemini Security Solutions, Inc. Visit our relaunched website! http://geminisecurity.com "A good programmer is someone who always looks both ways before crossing a one-way street." --Doug Linder ------=_NextPart_000_50A1_01C8C628.CD2CB5B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

 

We have recently made available a web-based tool = for doing an ASN.1 dump.  It displays the ASCII HEX and the ASN structure, = and when you hover over the structure, it highlights the relevant portion of the = hex.  (Clicking makes the highlight stick.)

 

Due to PHP’s inefficiency and memory usage = during parsing, we have limited it to files 64K and smaller.  Still, it is = useful for displaying smaller objects when you don’t have dumpasn1 installed or = available.

 

It can be found here: http://g= eminisecurity.com/features-downloads/tools#fd_5

Click on “Click to try the application” = under PHPdumpASN.

 

Enjoy!  Please send me any = feedback.

 

--Peter Hesse

 

 Peter Hesse           &n= bsp;           pmhesse@gemini= security.com

 Phone: = 703-378-5808 x105      Gemini Security Solutions, = Inc.

    Visit our relaunched website! http://geminisecurity.com

"A good programmer is someone who always looks both = ways before
 crossing a one-way street." --Doug = Linder

 

------=_NextPart_000_50A1_01C8C628.CD2CB5B0-- From owner-ietf-smime@mail.imc.org Wed Jun 4 09:20:29 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 DE5BD28C15E for ; Wed, 4 Jun 2008 09:20:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 U6AUQmq8RTIV for ; Wed, 4 Jun 2008 09:20:25 -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 B5C1028C1D3 for ; Wed, 4 Jun 2008 09:19:45 -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 m54G3qmi053225 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Jun 2008 09:03: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 m54G3q7p053223; Wed, 4 Jun 2008 09:03:52 -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 wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m54G3pg0053206 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL); Wed, 4 Jun 2008 09:03:52 -0700 (MST) (envelope-from aramp@qualcomm.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=aramp@qualcomm.com; q=dns/txt; s=qcdkim; t=1212595432; x=1244131432; h=from:to:date:subject:thread-topic:thread-index: message-id:in-reply-to:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:acceptlanguage: content-type:mime-version:x-ironport-av; z=From:=20"Perez,=20Aram"=20|To:=20PKI X=20,=20"ietf-smime@imc.org"=20|Date:=20Wed,=204=20Jun=202008=2009:03:47=20 -0700|Subject:=20Re:=20Web-based=20ASN.1=20decoding=20too l=20available|Thread-Topic:=20Web-based=20ASN.1=20decodin g=20tool=20available|Thread-Index:=20AcjGSlK0B56RJ/K4QmuS 9tqZTIyH0AAEj9f7|Message-ID:=20|In-Reply-To:=20<50a001c8c64a$543e55b0$fcbb0110$@ com>|Accept-Language:=20en-US|Content-Language:=20en |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20multipart/alternative=3B=0D=0A =09boundary=3D"_000_C46C0AF3F950arampqualcommcom_" |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 200,2160,5309"=3B=20a=3D"3673079"; bh=AnTuq5KFYeB8xBRr15aB8mR9qciaTkpwkm7gN2kPfvM=; b=hcsaii9veicIk67RE2REQPaG/uvkRsUraHECzsRIpx6RQ+Z+2gU0PTSL 9cl681oGsRAtxuuNw+DWz5WstKzAMtEEbagdYh8IAtV90grXLXT73cAWf CqetJeMUugnnADdBKy4I1s5AKs/Bzp5SGbbWx7Qc6ttwu7hmmghRMLMF9 A=; X-IronPort-AV: E=McAfee;i="5200,2160,5309"; a="3673079" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Jun 2008 09:03:51 -0700 Received: from msgtransport05.qualcomm.com (msgtransport05.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m54G3p6Y004910 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 4 Jun 2008 09:03:51 -0700 Received: from nasanexhc02.na.qualcomm.com (nasanexhc02.na.qualcomm.com [172.30.33.23]) by msgtransport05.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m54G3oR9025029 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 4 Jun 2008 09:03:51 -0700 Received: from nasanex01a.na.qualcomm.com (129.46.132.246) by nasanexhc02.na.qualcomm.com (172.30.33.23) with Microsoft SMTP Server (TLS) id 8.1.278.0; Wed, 4 Jun 2008 09:03:50 -0700 Received: from NASANEXMB05.na.qualcomm.com ([129.46.52.178]) by nasanex01a.na.qualcomm.com ([129.46.132.246]) with mapi; Wed, 4 Jun 2008 09:03:50 -0700 From: "Perez, Aram" To: PKIX , "ietf-smime@imc.org" Date: Wed, 4 Jun 2008 09:03:47 -0700 Subject: Re: Web-based ASN.1 decoding tool available Thread-Topic: Web-based ASN.1 decoding tool available Thread-Index: AcjGSlK0B56RJ/K4QmuS9tqZTIyH0AAEj9f7 Message-ID: In-Reply-To: <50a001c8c64a$543e55b0$fcbb0110$@com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C46C0AF3F950arampqualcommcom_" MIME-Version: 1.0 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --_000_C46C0AF3F950arampqualcommcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On 6/4/08 6:53 AM, Peter Hesse wrote: > All, > > We have recently made available a web-based tool for doing an ASN.1 dump.= It > displays the ASCII HEX and the ASN structure, and when you hover over the > structure, it highlights the relevant portion of the hex. (Clicking makes= the > highlight stick.) > > Due to PHP's inefficiency and memory usage during parsing, we have limite= d it > to files 64K and smaller. Still, it is useful for displaying smaller obj= ects > when you don't have dumpasn1 installed or available. > > It can be found here: http://geminisecurity.com/features-downloads/tools#= fd_5 > Click on "Click to try the application" under PHPdumpASN. For Windows, you can also try BERViewer . I haven'= t had time to remove the nag dialog box from the Mac version. Regards, Aram Perez --_000_C46C0AF3F950arampqualcommcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: Web-based ASN.1 decoding tool available O= n 6/4/08 6:53 AM, Peter Hesse  wrote:

> All,
>  
> We have recently made available a web-based tool for doing an ASN.1 du= mp.  It
> displays the ASCII HEX and the ASN structure, and when you hover over = the
> structure, it highlights the relevant portion of the hex. (Clicking ma= kes the
> highlight stick.)
>  
> Due to PHP’s inefficiency and memory usage during parsing, we ha= ve limited it
> to files 64K and smaller.  Still, it is useful for displaying sma= ller objects
> when you don’t have dumpasn1 installed or available.
>  
> It can be found here: http://geminisecurity.com/features-downloads/tools#fd_5=
> Click on “Click to try the application” under PHPdumpASN.<= BR>
For Windows, you can also try BERViewer <http://homepage.mac.com/aramperez/berviewer.h= tml>. I haven’t had time to remove the nag dialog box from the= Mac version.

Regards,
Aram Perez
 --_000_C46C0AF3F950arampqualcommcom_-- From owner-ietf-smime@mail.imc.org Wed Jun 4 10:17:47 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 24DD128C285 for ; Wed, 4 Jun 2008 10:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w+Pw5habMX3e for ; Wed, 4 Jun 2008 10:17:46 -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 D0E903A68A9 for ; Wed, 4 Jun 2008 10:13: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 m54H0pNb067527 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Jun 2008 10:00: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 m54H0pNM067525; Wed, 4 Jun 2008 10:00: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 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 m54H0oiJ067513 for ; Wed, 4 Jun 2008 10:00:50 -0700 (MST) (envelope-from root@core3.amsl.com) Received: by core3.amsl.com (Postfix, from userid 0) id 96FB728C217; Wed, 4 Jun 2008 10:00: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-3850bis-03.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080604170001.96FB728C217@core3.amsl.com> Date: Wed, 4 Jun 2008 10:00: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 Certificate Handling Author(s) : S. Turner, B. Ramsdell Filename : draft-ietf-smime-3850bis-03.txt Pages : 18 Date : 2008-6-4 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-03.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-3850bis-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-6-4095056.I-D@ietf.org> --NextPart-- From owner-ietf-smime@mail.imc.org Wed Jun 4 10:18:47 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 C475728C1E8 for ; Wed, 4 Jun 2008 10:18:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 9e7FpdfEP-Vu for ; Wed, 4 Jun 2008 10:18:47 -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 282C828C210 for ; Wed, 4 Jun 2008 10:14:17 -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 m54H0p8c067526 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Jun 2008 10:00: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 m54H0pE9067524; Wed, 4 Jun 2008 10:00: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 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 m54H0omt067512 for ; Wed, 4 Jun 2008 10:00:50 -0700 (MST) (envelope-from root@core3.amsl.com) Received: by core3.amsl.com (Postfix, from userid 0) id 7BE5F28C215; Wed, 4 Jun 2008 10:00: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-3278bis-00.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080604170001.7BE5F28C215@core3.amsl.com> Date: Wed, 4 Jun 2008 10:00: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-00.txt Pages : 39 Date : 2008-6-3 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-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 Content-Type: Message/External-body; name="draft-ietf-smime-3278bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-6-4094743.I-D@ietf.org> --NextPart-- From owner-ietf-smime@mail.imc.org Wed Jun 4 14:57: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 B2C6E3A6849 for ; Wed, 4 Jun 2008 14:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 jBk9qwU2OEJ8 for ; Wed, 4 Jun 2008 14:57:40 -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 90A9B3A6B1E for ; Wed, 4 Jun 2008 14:57:39 -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 m54Lj8JZ029142 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Jun 2008 14:45:08 -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 m54Lj8LG029141; Wed, 4 Jun 2008 14:45:08 -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 m54Lj7W0029125 for ; Wed, 4 Jun 2008 14:45:07 -0700 (MST) (envelope-from root@core3.amsl.com) Received: by core3.amsl.com (Postfix, from userid 0) id CA6B23A6B1E; Wed, 4 Jun 2008 14:45: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-3851bis-03.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080604214501.CA6B23A6B1E@core3.amsl.com> Date: Wed, 4 Jun 2008 14:45: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-03.txt Pages : 41 Date : 2008-6-4 his 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-03.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-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-6-4143956.I-D@ietf.org> --NextPart-- From owner-ietf-smime@mail.imc.org Thu Jun 5 02:24:41 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 854E63A6A9C for ; Thu, 5 Jun 2008 02:24:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.693 X-Spam-Level: X-Spam-Status: No, score=-0.693 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uh0D6EWbZ-og for ; Thu, 5 Jun 2008 02:24:39 -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 3BCD13A6C05 for ; Thu, 5 Jun 2008 02:24:37 -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 m5592LQc094279 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Jun 2008 02:02:21 -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 m5592LEj094278; Thu, 5 Jun 2008 02:02:21 -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.nbusr.sk (mail.nbusr.sk [84.245.65.227]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5592DKD094244 for ; Thu, 5 Jun 2008 02:02:16 -0700 (MST) (envelope-from rybar@nbusr.sk) From: "Peter Rybar" To: "'Pope, Nick'" , "'Pavel V. Smirnov'" , ESI@LIST.ETSI.ORG, ietf-smime@imc.org Cc: peterryb@gmail.com Subject: RE: Extending CAdES to support usual signature upgrading to CAdES-T and further Date: Thu, 5 Jun 2008 11:02:56 +0200 Message-ID: <200806050903.m5593V5d006047@mail.nbusr.sk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001B_01C8C6FB.B5C72F80" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcjGIpMmSh21HPObR1m3lQZM/IvlEAAtqK0Q X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <6FC9E49ED3472043A38619BFA97F37B5018746B1@webmail.thales-esecurity.com> X-NAI-Spam-Score: 0 X-NAI-Spam-Report: 1 Rules triggered * 0 -- RV3031 -- BODY: Version number 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_001B_01C8C6FB.B5C72F80 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Pavel, In my opinion, like in previous mail, the AdES signatures could in 3 = important sates from the time perspective. And for these 3 states there is important that the signature in the 1st = state contains the information about the signer certificate protected by = signature. The 2nd state of the signature is mainly important for validation of = expired certificates and in this case signature must contain evidence = that the signature was created before expiration of signer certificate = e. g. through signature timestamp and any revocation list or OCSP which = could contain information about potential revocation must be available = for verifier.=20 The 3rd state of the signature is important for the long term = validation. Signature in this state must contain not only all = certificates and revocation lists or OCSPs which could contain = information about potential revocation but also the integrity of all = this information must be protected because some algorithms can become = not secure. In this case the signature and all information must be = protected with additional more secure HASH (for integrity) in time when = lastly used integrity hash was considered as secure it is usually = achived by archive timestamp. =20 AdES offers for implementers many attributes which could be used to = satisfy these requirements of these 3 states and you NEED NOT to use all = of them. In my opinion it could be very helpful if some security annex of AdES = standard will contain any recommendation which attribute is useful to = protect which security attack or in which system its usage is important. =20 In this case, in my opinion, the following attributes are important for = the common usage.=20 =20 1st state id-contentType=20 id-messageDigest=20 id-aa-ets-signingCertificateV2 or id-aa-signingCertificate =20 2nd state id-contentType=20 id-messageDigest=20 id-aa-ets-signingCertificateV2 or id-aa-signingCertificate id-aa-signatureTimeStampToken Signature must contain certificates for validation of the signature and = the whole certification path with CRL or OCSP and if there are used = indirect CRL or OCSP then also certificates for its validation. =20 3rd state id-contentType=20 id-messageDigest=20 id-aa-ets-signingCertificateV2 or id-aa-signingCertificate id-aa-signatureTimeStampToken Signature must contain certificates for validation of the signature and = the whole certification path with CRL or OCSP and if there are used = indirect CRL or OCSP then also certificates for its validation. Each signature of the timestamp must contain certificates for validation = of the timestamp signature and the whole certification path with CRL or = OCSP and if there are used indirect CRL or OCSP then also certificates = for its validation. Any subsequent id-aa-ets-archiveTimestamp can be applied only if = previous one contains all verification information. =20 Timestamp itself is electronic signature and in this case the = verification information must only be added to the timestamp and not to = de signature which was time stamped. !!! =20 Peter =20 > Notably, one must store certificate and revocation values for = signature-timestamp validation in the timestamp itself, hence, after = receiving CAdES-C-timestamp one cannot add or remove these values from = signature-timestamp. =20 >An obvious solution is to allow to include timestamp validation data in = certificate-values and revocation-values attributes of the signature = itself. What do you think? =20 ---------- Forwarded message ---------- From: Peter Rybar g Date: Wed, 4 Jun 2008 17:41:55 +0200 Subject: Re: Extending CAdES to support usual signature upgrading to CAdES-T and further To: spv@cryptopro.ru Cc: ietf-smime@imc.org, ESI@list.etsi.org, = Nick.Pope@thales-esecurity.com =20 Pavel, A signer protects his certificate with his signature.=20 It must be only under his control that the verifier will use only his = certificate.=20 The signer certificate is usually protected by hash value of signer = certificate inside in the signed attributes signed by SIGNER or it could = by done when the certificate is present in the signed document like in = the PDF signature. The "security expiration" of the HASH algorithm used in the signed = attributes like reference to the signer certificate in the long term = validation is another important issue!!! !!!=20 It requires archive timestamp or secure HASH in archiving system used in = time when the hash algorithm in the signature was secure and must = include also the certificate value. Your suggest to use the timestamp for it but it is not correct because = the timestamp could be removed with another timestamp and in this case = there is no protection from the substitution attack of the signer = certificate. =20 It is the same as the usage of the MIME-TYPE of the signed document to = prevent signatures from the attack of changing the type of the = visualization of the signed document. Example is on the page: http://elpi2.szm.com/priklad.htm And one possible solution how to prevent the signature from this attack = is in the document http://www.nbusr.sk/en/electronic-signature/approved-formats/index.html http://www.nbusr.sk/ipublisher/files/nbusr.sk/elektronicky-podpis/legisla= tiva/9/specifyingcontentformalspecofdocqes_en_071.pdf =20 This attack is similar as the substitution attack of the signer = certificate.=20 Only the signer is able with his signature to protect important = information which must be used by the verifier in the visualization of = the signed document.=20 =20 It is the attack on the signed document which contains quite correct = information but not only for one type of the document but also for two = or more types of the document. Then if we try to view it as the first = type of the document then the viewer will read information which is = relevant for the first type and another one will be ignored. The same = situation happens if we view it as the second type of the document where = the viewer will only recognize the information relevant to the second = type of the document and so on.=20 The problem occurs if we sign the document without information about the = type of the document which was shown to the signer. Then the verifier could see the different information. =20 For solving this attack the application must be able to do: * In the XAdES signature =E2=80=93 the type of the signed document must = be present in the MIME-TYPE element of DataObjectFormat signed = attribute. * In the CAdES signature =E2=80=93 the type of the signed document must = be present in the MIME-TYPE which must be in the MIME header which = envelopes the signed document.=20 * Or the type of the signed document is implicitly defined by the signed = document content containing the signature and rules of manipulation of = the signed data and document like in PDF signature. =20 In this case the signatures of some data without protected information = about the type of the data like the MIME-TYPE protected by the signature = could be hazardous similarly as signatures without the protection of the = signer certificate. =20 Peter =20 _____ =20 From: owner-ietf-smime@mail.imc.org = [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Pope, Nick Sent: Wednesday, June 04, 2008 10:37 AM To: 'Pavel V. Smirnov'; ESI@LIST.ETSI.ORG; ietf-smime@imc.org Subject: RE: Extending CAdES to support usual signature upgrading to = CAdES-T and further =20 Pavel, =20 I personally have some sympathy for your view. I will add this issue to = those for discussion at the next ETSI meeting later in June. =20 Nick =20 =20 -----Original Message----- From: Pavel V. Smirnov [mailto:spv@cryptopro.ru]=20 Sent: 26 May 2008 11:50 To: 'Pope, Nick'; ESI@LIST.ETSI.ORG; ietf-smime@imc.org Subject: Extending CAdES to support usual signature upgrading to CAdES-T = and further =20 Hello all and personally Nick, =20 In current CAdES wording a regular signature without at least one signed = attribute (Signing certificate reference) cannot be added with = timestamps and validation data to achieve CAdES-T or more advanced CAdES = signature. This need arises, e.g., in a system with existing regular = signatures. There is no chance to add the required attribute to the = already computed signature, but there is a strong need to add CAdES = properties to such signatures. =20 There is rather simple approach to achieve the same properties without = including signing certificate reference as a signed attribute. Let us = include this reference as an extension in the CAdES-T timestamp = (signature timestamp). To get such timestamp one would need to include = this extension in a timestamp request and a TSA would have to shift this = extension to a timestamp token. =20 Let us define the proposed extension to a timestamp protocol and call = the signature we get a valid CAdES-T signature. More advanced CAdES = signature types turn out from this new CAdES-T perfectly without any = modification. What do you think? =20 Pavel Smirnov Crypto-Pro Tel./Fax: +7 495 780-4820 WWW: http://www.CryptoPro.ru e-mail: spv@CryptoPro.ru =20 Consider the environment before printing this mail. "Thales e-Security Limited is incorporated in England and Wales with = company registration number 2518805. Its registered office is located at = 2 Dashwood Lang Road, The Bourne Business Park, Addlestone, Nr. = Weybridge, Surrey KT15 2NX. The information contained in this e-mail is confidential. It may also be = privileged. It is only intended for the stated addressee(s) and access = to it by any other person is unauthorised. If you are not an addressee = or the intended addressee, you must not disclose, copy, circulate or in = any other way use or rely on the information contained in this e-mail. = Such unauthorised use may be unlawful. If you have received this e-mail = in error please delete it (and all copies) from your system, please also = inform us immediately on +44 (0)1844 201800 or email = postmaster@thales-esecurity.com. Commercial matters detailed or referred = to in this e-mail are subject to a written contract signed for and on = behalf of Thales e-Security Limited".=20 ------=_NextPart_000_001B_01C8C6FB.B5C72F80 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

 Pavel,=

In my opinion, like in previous mail, the AdES signatures could = in 3 important sates from the time perspective.

And for these 3 states there is important that the signature in = the 1st state contains the information about the signer certificate protected by signature.

The 2nd state of the signature is mainly important for = validation of expired certificates and in this case signature must contain evidence = that the signature was created before expiration of signer certificate e. g. = through signature timestamp and any revocation list or OCSP which could contain = information about potential revocation must be available for verifier. =

The 3rd state of the signature is important for the long term validation. Signature in this state must contain not only all = certificates and revocation lists or OCSPs which could contain information about potential = revocation but also the integrity of all this information must be protected because some = algorithms can become not secure. In this case the signature and all information = must be protected with additional more secure HASH (for integrity) in time when = lastly used integrity hash was considered as secure it is usually achived by = archive timestamp.

 

AdES offers for implementers many attributes which could be used = to satisfy these requirements of these 3 states and you NEED NOT to use all of = them.

In my opinion it could be very helpful if some security annex of = AdES standard will contain any recommendation which attribute is useful to = protect which security attack or in which system its usage is = important.

 

In this case, in my opinion, the following attributes are = important for the common usage.

 

1st state

id-contentType

id-messageDigest

id-aa-ets-signingCertificateV2 or id-aa-signingCertificate

 

2nd state

id-contentType

id-messageDigest

id-aa-ets-signingCertificateV2 or id-aa-signingCertificate

id-aa-signatureTimeStampToken=

Signature must contain = certificates for validation of the signature and the whole certification path with CRL or = OCSP and if there are used indirect CRL or OCSP then also certificates for its validation.

 

=C2=A03rd state

id-contentType

id-messageDigest

id-aa-ets-signingCertificateV2 or id-aa-signingCertificate

id-aa-signatureTimeStampToken=

Signature must contain = certificates for validation of the signature and the whole certification path with CRL or = OCSP and if there are used indirect CRL or OCSP then also certificates for its validation.

Each signature of the timestamp = must contain certificates for validation of the timestamp signature and the = whole certification path with CRL or OCSP and if there are used indirect CRL = or OCSP then also certificates for its validation.

Any subsequent id-aa-ets-archiveTimestamp can be = applied only if previous one contains all verification = information.

 

Timestamp itself is electronic signature and in this case the verification information must only be added to the timestamp and not to = de signature which was time stamped. !!!

 

Peter

 

> =C2=A0Notably, one must store certificate and revocation = values for signature-timestamp validation in the timestamp itself, hence, after = receiving CAdES-C-timestamp one cannot add or remove these values from signature-timestamp.

 

>An obvious solution is to allow to include timestamp = validation data in certificate-values and revocation-values attributes of the = signature itself. What do you think?

 

---------- Forwarded message = ----------

From: Peter Rybar g <peterryb@gmail.com>

Date: Wed, 4 Jun 2008 17:41:55 = +0200

Subject: Re: Extending CAdES to support usual signature upgrading to

CAdES-T and = further

To: = spv@cryptopro.ru

Cc: ietf-smime@imc.org, ESI@list.etsi.org, Nick.Pope@thales-esecurity.com

 

Pavel,=

A signer = protects his certificate with his signature.

It must be only = under his control that the verifier will use only his certificate. =

The signer = certificate is usually protected by hash value of signer certificate inside in the = signed attributes signed by SIGNER or it could by done when the certificate is = present in the signed document like in the PDF = signature.

The = "security expiration" of the HASH algorithm used in the signed attributes = like reference to the signer certificate in the long term validation is = another important issue!!! !!!

It requires = archive timestamp or secure HASH in archiving system used in time when the hash algorithm in the signature was secure and must include also the = certificate value.

Your suggest to = use the timestamp for it but it is not correct because the timestamp could be removed with another timestamp and in this case there is no protection from the = substitution attack of the signer certificate.

 =

It is the same = as the usage of the MIME-TYPE of the signed document to prevent signatures from = the attack of changing the type of the visualization of the signed document. Example is on the page:

http://elpi2.szm.com/priklad.ht= m

And one possible = solution how to prevent the signature from this attack is in the = document

http://www.nbusr.sk/en/electronic-signature/approved-formats/inde= x.html

http://www= .nbusr.sk/ipublisher/files/nbusr.sk/elektronicky-podpis/legislativa/9/spe= cifyingcontentformalspecofdocqes_en_071.pdf<= /p>

 =

This attack is = similar as the substitution attack of the signer certificate. =

Only the signer = is able with his signature to protect important information which must be used = by the verifier in the visualization of the signed document. =

 =

It is the attack = on the signed document which contains quite correct information but not only = for one type of the document but also for two or more types of the document. = Then if we try to view it as the first type of the document then the viewer will = read information which is relevant for the first type and another one will be ignored. The same situation happens if we view it as the second type of = the document where the viewer will only recognize the information relevant = to the second type of the document and so on.

The problem = occurs if we sign the document without information about the type of the document = which was shown to the signer.

Then the = verifier could see the different information.

 =

For solving this = attack the application must be able to do:

* In the XAdES = signature =E2=80=93 the type of the signed document must be present in the = MIME-TYPE element of DataObjectFormat signed attribute.

* In the CAdES = signature =E2=80=93 the type of the signed document must be present in the = MIME-TYPE which must be in the MIME header which envelopes the signed document. =

* Or the type of = the signed document is implicitly defined by the signed document content = containing the signature and rules of manipulation of the signed data and document = like in PDF signature.

 =

In this case the signatures of some data without protected information about the type of = the data like the MIME-TYPE protected by the signature could be hazardous = similarly as signatures without the protection of the signer = certificate.

 =

Peter<= /span>

 =

From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] = On Behalf Of Pope, Nick
Sent: Wednesday, June 04, = 2008 10:37 AM
To: 'Pavel V. Smirnov'; ESI@LIST.ETSI.ORG; ietf-smime@imc.org
Subject: RE: Extending = CAdES to support usual signature upgrading to CAdES-T and = further

 

Pavel,

 

I personally = have some sympathy for your view.  I will add this issue to those for = discussion at the next ETSI meeting later in June.

 

Nick

 

 

-----Original Message-----
From: Pavel V. Smirnov [mailto:spv@cryptopro.ru]
Sent: 26 May 2008 = 11:50
To: 'Pope, Nick'; ESI@LIST.ETSI.ORG; ietf-smime@imc.org
Subject: Extending CAdES = to support usual signature upgrading to CAdES-T and = further

 

Hello all and personally Nick,

 

In current CAdES wording a regular signature without at least = one signed attribute (Signing certificate reference) cannot be added with timestamps and validation data to achieve CAdES-T or more advanced CAdES signature. This need arises, e.g., in a system with existing regular signatures. There is no chance to add the required attribute to the = already computed signature, but there is a strong need to add CAdES properties = to such signatures.

 

There is rather simple approach to achieve the same properties = without including signing certificate reference as a signed attribute. Let us = include this reference as an extension in the CAdES-T timestamp (signature = timestamp). To get such timestamp one would need to include this extension in a = timestamp request and a TSA would have to shift this extension to a timestamp = token.

 

Let us define the proposed extension to a timestamp protocol and = call the signature we get a valid CAdES-T signature. More advanced CAdES = signature types turn out from this new CAdES-T perfectly without any modification. = What do you think?

 

Pavel Smirnov

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

 

Consider the environment before = printing this mail.

"Thales e-Security Limited is = incorporated in England and Wales with company registration number = 2518805. Its registered office is located at 2 Dashwood Lang Road, The = Bourne Business Park, Addlestone, Nr. Weybridge, Surrey KT15 = 2NX.

The information contained in this = e-mail is confidential. It may also be privileged. It is only intended = for the stated addressee(s) and access to it by any other person is = unauthorised. If you are not an addressee or the intended addressee, you = must not disclose, copy, circulate or in any other way use or rely on = the information contained in this e-mail. Such unauthorised use may be = unlawful. If you have received this e-mail in error please delete it = (and all copies) from your system, please also inform us immediately on = +44 (0)1844 201800 or email postmaster@thales-esecurity.com. Commercial = matters detailed or referred to in this e-mail are subject to a written = contract signed for and on behalf of Thales e-Security = Limited".

------=_NextPart_000_001B_01C8C6FB.B5C72F80-- From owner-ietf-smime@mail.imc.org Thu Jun 5 06:40: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 4BFCC3A6844 for ; Thu, 5 Jun 2008 06:40:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.694 X-Spam-Level: X-Spam-Status: No, score=-0.694 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555] 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 vvXyRjVpDxiT for ; Thu, 5 Jun 2008 06:40:29 -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 E3C413A6958 for ; Thu, 5 Jun 2008 06:40:28 -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 m55DNtLN059439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Jun 2008 06:23:55 -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 m55DNtGR059438; Thu, 5 Jun 2008 06:23:55 -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.nbusr.sk (mail.nbusr.sk [84.245.65.227]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m55DNqHj059413; Thu, 5 Jun 2008 06:23:53 -0700 (MST) (envelope-from rybar@nbusr.sk) Message-Id: <200806051325.m55DPCtJ009671@mail.nbusr.sk> From: "Peter Rybar" To: "'Perez, Aram'" , "'PKIX'" , ietf-smime@imc.org Subject: RE: Web-based ASN.1 decoding tool available Date: Thu, 5 Jun 2008 15:24:46 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcjGSlK0B56RJ/K4QmuS9tqZTIyH0AAEj9f7ACxVXxA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: X-NAI-Spam-Score: 0 X-NAI-Spam-Report: 2 Rules triggered * 0 -- MISSING_MSGID -- Missing Message-ID header * 0 -- RV3031 -- BODY: Version number Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, Have you any free tools which are not the simple dump of asn1 DER/BER = but which also can read a data according the 1988, 93 ASN.1 Syntax?=20 Like default values from DER... Peter -----Original Message----- From: owner-ietf-smime@mail.imc.org = [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Perez, Aram Sent: Wednesday, June 04, 2008 6:04 PM To: PKIX; ietf-smime@imc.org Subject: Re: Web-based ASN.1 decoding tool available On 6/4/08 6:53 AM, Peter Hesse wrote: > All, > =20 > We have recently made available a web-based tool for doing an ASN.1 = dump. It=20 > displays the ASCII HEX and the ASN structure, and when you hover over = the=20 > structure, it highlights the relevant portion of the hex. (Clicking = makes the=20 > highlight stick.) > =20 > Due to PHP=E2=80=99s inefficiency and memory usage during parsing, we = have limited it=20 > to files 64K and smaller. Still, it is useful for displaying smaller = objects=20 > when you don=E2=80=99t have dumpasn1 installed or available. > =20 > It can be found here: = http://geminisecurity.com/features-downloads/tools#fd_5 > Click on =E2=80=9CClick to try the application=E2=80=9D under = PHPdumpASN. For Windows, you can also try BERViewer = = . I haven=E2=80=99t = had time to remove the nag dialog box from the Mac version. Regards, Aram Perez From owner-ietf-smime@mail.imc.org Thu Jun 5 07:18: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 D2BB53A6D1D for ; Thu, 5 Jun 2008 07:18:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u53ykfD1Nzo9 for ; Thu, 5 Jun 2008 07:18: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 0CBB63A6A2D for ; Thu, 5 Jun 2008 07:17: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 m55E3I0I068342 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Jun 2008 07:03: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 m55E3ITD068341; Thu, 5 Jun 2008 07:03: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 smtpoutm.mac.com (smtpoutm.mac.com [17.148.16.68]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m55E3GL1068331; Thu, 5 Jun 2008 07:03:17 -0700 (MST) (envelope-from aramperez@mac.com) Received: from asmtp016-bge351000 (asmtp016-bge351000 [10.150.69.79]) by smtpoutm.mac.com (Xserve/smtpout005/MantshX 4.0) with ESMTP id m55E3G21024009; Thu, 5 Jun 2008 07:03:16 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_FkuvH/Tz1lYEXqbTGUCRSQ)" Received: from [192.168.1.3] ([76.88.67.30]) by asmtp016.mac.com (Sun Java(tm) System Messaging Server 6.3-6.03 (built Mar 14 2008; 32bit)) with ESMTPSA id <0K1Z00M9UTPD0P20@asmtp016.mac.com>; Thu, 05 Jun 2008 07:03:16 -0700 (PDT) Message-id: <7CF18E27-23FD-464F-8BCE-1D53E8257DF7@mac.com> From: Aram Perez To: PKIX , ietf-smime@imc.org In-reply-to: <200806051325.m55DPCtJ009671@mail.nbusr.sk> Subject: Re: Web-based ASN.1 decoding tool available Date: Thu, 05 Jun 2008 07:03:12 -0700 References: <200806051325.m55DPCtJ009671@mail.nbusr.sk> X-Mailer: Apple Mail (2.924) Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --Boundary_(ID_FkuvH/Tz1lYEXqbTGUCRSQ) Content-type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-transfer-encoding: quoted-printable Hi Peter, > > Have you any free tools which are not the simple dump of asn1 DER/=20 > BER but which also can read a data according the 1988, 93 ASN.1 =20 > Syntax? > Like default values from DER... I'm afraid I do not and I'm not aware of any such tool. To get the =20 default values, you would need the actual ASN.1 (which provides the =20 default values) and the BER/DER data. BERViewer, Peter Hesse's web tool, Peter Gutmann's dumpasn1 and others =20= similar tools just decode the BER/DER and present it in a "more" human =20= readable form. Regards, Aram > > > Peter > > > > -----Original Message----- > From: owner-ietf-smime@mail.imc.org = [mailto:owner-ietf-smime@mail.imc.org=20 > ] On Behalf Of Perez, Aram > Sent: Wednesday, June 04, 2008 6:04 PM > To: PKIX; ietf-smime@imc.org > Subject: Re: Web-based ASN.1 decoding tool available > > On 6/4/08 6:53 AM, Peter Hesse wrote: > >> All, >> >> We have recently made available a web-based tool for doing an ASN.1 =20= >> dump. It >> displays the ASCII HEX and the ASN structure, and when you hover =20 >> over the >> structure, it highlights the relevant portion of the hex. (Clicking =20= >> makes the >> highlight stick.) >> >> Due to PHP=92s inefficiency and memory usage during parsing, we have =20= >> limited it >> to files 64K and smaller. Still, it is useful for displaying =20 >> smaller objects >> when you don=92t have dumpasn1 installed or available. >> >> It can be found here: = http://geminisecurity.com/features-downloads/tools#fd_5 >> Click on =93Click to try the application=94 under PHPdumpASN. > > For Windows, you can also try BERViewer = > . I haven=92t had = =20 > time to remove the nag dialog box from the Mac version. > > Regards, > Aram Perez > > > --Boundary_(ID_FkuvH/Tz1lYEXqbTGUCRSQ) Content-type: text/html; charset=WINDOWS-1252 Content-transfer-encoding: quoted-printable Hi Peter,

Have you any free tools which are not the = simple dump of asn1 DER/BER but which also can read a data according the = 1988, 93 ASN.1 Syntax?
Like default values from = DER...

I'm afraid I do not and I'm = not aware of any such tool. To get the default values, you would need = the actual ASN.1 (which provides the default values) and the BER/DER = data.

BERViewer, Peter Hesse's web tool, Peter = Gutmann's dumpasn1 and others similar tools just decode the BER/DER and = present it in a "more" human readable = form.

Regards,
Aram



Peter



-----Original= Message-----
From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail= .imc.org] On Behalf Of Perez, Aram
Sent: Wednesday, June 04, 2008 = 6:04 PM
To: PKIX; ietf-smime@imc.org
Subject: = Re: Web-based ASN.1 decoding tool available

On 6/4/08 6:53 AM, = Peter Hesse  wrote:

All,

We have = recently made available a web-based tool for doing an ASN.1 dump. =  It
displays the ASCII = HEX and the ASN structure, and when you hover over the =
structure, it highlights the = relevant portion of the hex. (Clicking makes the =
highlight = stick.)

Due to PHP=92s = inefficiency and memory usage during parsing, we have limited it =
to files 64K and smaller. =  Still, it is useful for displaying smaller objects =
when you don=92t have = dumpasn1 installed or available.

It can be found = here: http://ge= minisecurity.com/features-downloads/tools#fd_5
Click on =93Click to try the application=94 under = PHPdumpASN.

For Windows, you can also try BERViewer = <http://homepage.= mac.com/aramperez/berviewer.html> <http://homepage.= mac.com/aramperez/berviewer.html> . I haven=92t had time to remove = the nag dialog box from the Mac version.

Regards,
Aram = Perez




= --Boundary_(ID_FkuvH/Tz1lYEXqbTGUCRSQ)-- From owner-ietf-smime@mail.imc.org Thu Jun 5 07:56:24 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 9A59D3A6D42 for ; Thu, 5 Jun 2008 07:56:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.694 X-Spam-Level: X-Spam-Status: No, score=-0.694 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555] 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 FdohYNcuCxVy for ; Thu, 5 Jun 2008 07:56:23 -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 B1D763A6D52 for ; Thu, 5 Jun 2008 07:56: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 m55EYqaw075369 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Jun 2008 07:34: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 m55EYqPD075368; Thu, 5 Jun 2008 07:34:52 -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.nbusr.sk (mail.nbusr.sk [84.245.65.227]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m55EYn7c075337; Thu, 5 Jun 2008 07:34:50 -0700 (MST) (envelope-from rybar@nbusr.sk) Message-Id: <200806051436.m55EaAf9010452@mail.nbusr.sk> From: "Peter Rybar" To: "'Aram Perez'" , "'PKIX'" , ietf-smime@imc.org Subject: RE: Web-based ASN.1 decoding tool available Date: Thu, 5 Jun 2008 16:35:43 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcjHGW+R09LPo1xoT+u+1UI0FfXXTQAALrmQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <7CF18E27-23FD-464F-8BCE-1D53E8257DF7@mac.com> X-NAI-Spam-Level: * X-NAI-Spam-Score: 1 X-NAI-Spam-Report: 3 Rules triggered * 1 -- INFO_TLD -- URI: Contains a URL in the INFO top-level domain * 0 -- MISSING_MSGID -- Missing Message-ID header * 0 -- RV3031 -- BODY: Version number Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi all, This one is also nice...=20 And somebody could try to use it in online PHP :-) with at least ASN.1 = modules which are described in PKIX, SMIME RFCs. http://lionet.info/asn1c/ Peter -----Original Message----- From: owner-ietf-smime@mail.imc.org = [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Aram Perez Sent: Thursday, June 05, 2008 4:03 PM To: PKIX; ietf-smime@imc.org Subject: Re: Web-based ASN.1 decoding tool available Hi Peter, =09 Have you any free tools which are not the simple dump of asn1 DER/BER = but which also can read a data according the 1988, 93 ASN.1 Syntax?=20 Like default values from DER... I'm afraid I do not and I'm not aware of any such tool. To get the = default values, you would need the actual ASN.1 (which provides the = default values) and the BER/DER data. BERViewer, Peter Hesse's web tool, Peter Gutmann's dumpasn1 and others = similar tools just decode the BER/DER and present it in a "more" human = readable form. Regards, Aram Peter =09 =09 =09 -----Original Message----- From: owner-ietf-smime@mail.imc.org = [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Perez, Aram Sent: Wednesday, June 04, 2008 6:04 PM To: PKIX; ietf-smime@imc.org Subject: Re: Web-based ASN.1 decoding tool available =09 On 6/4/08 6:53 AM, Peter Hesse wrote: =09 =09 All, =09 We have recently made available a web-based tool for doing an ASN.1 = dump. It=20 =09 displays the ASCII HEX and the ASN structure, and when you hover over = the=20 =09 structure, it highlights the relevant portion of the hex. (Clicking = makes the=20 =09 highlight stick.) =09 Due to PHP=E2=80=99s inefficiency and memory usage during parsing, we = have limited it=20 =09 to files 64K and smaller. Still, it is useful for displaying smaller = objects=20 =09 when you don=E2=80=99t have dumpasn1 installed or available. =09 It can be found here: = http://geminisecurity.com/features-downloads/tools#fd_5 =09 Click on =E2=80=9CClick to try the application=E2=80=9D under = PHPdumpASN. =09 For Windows, you can also try BERViewer = = . I haven=E2=80=99t = had time to remove the nag dialog box from the Mac version. =09 Regards, Aram Perez =09 =09 =09 =09 From owner-ietf-smime@mail.imc.org Thu Jun 5 10:30: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 08FCF3A6A61 for ; Thu, 5 Jun 2008 10:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eif2XrPo863v for ; Thu, 5 Jun 2008 10:30:23 -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 006823A6C32 for ; Thu, 5 Jun 2008 10:30:22 -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 m55HEpVA008663 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Jun 2008 10:14: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 m55HEpbt008662; Thu, 5 Jun 2008 10:14: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 mail.multicert.com (mail.multicert.com [62.48.217.200]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m55HEmPi008641; Thu, 5 Jun 2008 10:14:49 -0700 (MST) (envelope-from ricardo.barroso@multicert.com) Received: from 10.0.0.194 (webmail.multicert.com [10.0.0.194]) by mail.multicert.prod (Postfix) with SMTP id D7DB072E46; Thu, 5 Jun 2008 18:14:47 +0100 (WEST) X-Spambayes-Classification: unsure; 0.26 Received: from teste.multicert.com (unknown [62.48.177.165]) by mail.multicert.com (Postfix) with ESMTP id E07E272F2E; Thu, 5 Jun 2008 18:14:45 +0100 (WEST) Received: from [192.168.10.88] (unknown [192.168.10.88]) by teste.multicert.com (Postfix) with ESMTP id 1025D5B764; Thu, 5 Jun 2008 18:14:44 +0100 (WEST) Message-ID: <48481F06.5010301@multicert.com> Date: Thu, 05 Jun 2008 18:14:46 +0100 From: Ricardo Barroso User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Aram Perez Cc: PKIX , ietf-smime@imc.org Subject: Re: Web-based ASN.1 decoding tool available References: <200806051325.m55DPCtJ009671@mail.nbusr.sk> <7CF18E27-23FD-464F-8BCE-1D53E8257DF7@mac.com> In-Reply-To: <7CF18E27-23FD-464F-8BCE-1D53E8257DF7@mac.com> Content-Type: multipart/alternative; boundary="------------020908070306050005030907" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------020908070306050005030907 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi all! I would like to mention ASN.1 Editor (for Windows) which is not a web-based tool and although it can't provide default values from DER, it lets you: - inspect ASN.1 structures and encapsulate parts of the structures in a more user-friendly way than simple dump tools; - edit ASN.1 structures; - save sub-parts/structures to a new file; - etc. It also includes a simple but nice data converter between PEM, HEX and BASE64 formats. Best regards, Ricardo Barroso Aram Perez wrote: > Hi Peter, >> >> Have you any free tools which are not the simple dump of asn1 DER/BER >> but which also can read a data according the 1988, 93 ASN.1 Syntax? >> Like default values from DER... > > I'm afraid I do not and I'm not aware of any such tool. To get the > default values, you would need the actual ASN.1 (which provides the > default values) and the BER/DER data. > > BERViewer, Peter Hesse's web tool, Peter Gutmann's dumpasn1 and others > similar tools just decode the BER/DER and present it in a "more" human > readable form. > > Regards, > Aram > >> >> >> Peter >> >> >> >> -----Original Message----- >> From: owner-ietf-smime@mail.imc.org >> [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Perez, Aram >> Sent: Wednesday, June 04, 2008 6:04 PM >> To: PKIX; ietf-smime@imc.org >> Subject: Re: Web-based ASN.1 decoding tool available >> >> On 6/4/08 6:53 AM, Peter Hesse wrote: >> >>> All, >>> >>> We have recently made available a web-based tool for doing an ASN.1 >>> dump. It >>> displays the ASCII HEX and the ASN structure, and when you hover >>> over the >>> structure, it highlights the relevant portion of the hex. (Clicking >>> makes the >>> highlight stick.) >>> >>> Due to PHP’s inefficiency and memory usage during parsing, we have >>> limited it >>> to files 64K and smaller. Still, it is useful for displaying >>> smaller objects >>> when you don’t have dumpasn1 installed or available. >>> >>> It can be found here: >>> http://geminisecurity.com/features-downloads/tools#fd_5 >>> Click on “Click to try the application” under PHPdumpASN. >> >> For Windows, you can also try BERViewer >> >> . I haven’t had >> time to remove the nag dialog box from the Mac version. >> >> Regards, >> Aram Perez >> >> >> > -- * Ricardo Barroso* *Telefone:* +351 217 123 010 *Telemóvel:* +351 968 332 327 *Fax:* +351 217 123 011 *Email:* ricardo.barroso@multicert.com *MULTICERT S.A.* Estrada do Casal do Canas, Lote 6, Alfragide 2720-092 Amadora - Portugal --------------020908070306050005030907 Content-Type: multipart/related; boundary="------------060705050402080307010006" --------------060705050402080307010006 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi all!

I would like to mention ASN.1 Editor (for Windows) which is not a web-based tool and although it can't provide default values from DER,
it lets you:
    - inspect ASN.1 structures and encapsulate parts of the structures in a more user-friendly way than simple dump tools;
    - edit ASN.1 structures;
    - save sub-parts/structures to a new file;
    - etc.

It also includes a simple but nice data converter between PEM, HEX and BASE64 formats.

Best regards,
Ricardo Barroso


Aram Perez wrote:
Hi Peter,

Have you any free tools which are not the simple dump of asn1 DER/BER but which also can read a data according the 1988, 93 ASN.1 Syntax?
Like default values from DER...

I'm afraid I do not and I'm not aware of any such tool. To get the default values, you would need the actual ASN.1 (which provides the default values) and the BER/DER data.

BERViewer, Peter Hesse's web tool, Peter Gutmann's dumpasn1 and others similar tools just decode the BER/DER and present it in a "more" human readable form.

Regards,
Aram



Peter



-----Original Message-----
From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Perez, Aram
Sent: Wednesday, June 04, 2008 6:04 PM
To: PKIX; ietf-smime@imc.org
Subject: Re: Web-based ASN.1 decoding tool available

On 6/4/08 6:53 AM, Peter Hesse  wrote:

All,

We have recently made available a web-based tool for doing an ASN.1 dump.  It
displays the ASCII HEX and the ASN structure, and when you hover over the
structure, it highlights the relevant portion of the hex. (Clicking makes the
highlight stick.)

Due to PHP’s inefficiency and memory usage during parsing, we have limited it
to files 64K and smaller.  Still, it is useful for displaying smaller objects
when you don’t have dumpasn1 installed or available.

It can be found here: http://geminisecurity.com/features-downloads/tools#fd_5
Click on “Click to try the application” under PHPdumpASN.

For Windows, you can also try BERViewer <http://homepage.mac.com/aramperez/berviewer.html> <http://homepage.mac.com/aramperez/berviewer.html> . I haven’t had time to remove the nag dialog box from the Mac version.

Regards,
Aram Perez






--
MySignatura2008
    Ricardo Barroso
Telefone: +351 217 123 010
Telemóvel: +351 968 332 327
Fax: +351 217 123 011		 Email:
ricardo.barroso@multicert.com		 MULTICERT S.A.
Estrada do Casal do Canas,
 Lote 6, Alfragide
2720-092 Amadora - Portugal

--------------060705050402080307010006 Content-Type: image/jpeg; name="MailLogoMULTICERT.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="MailLogoMULTICERT.jpg" /9j/4AAQSkZJRgABAQEAeAB4AAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRof Hh0aHBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwh MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAAR CAAtAaYDASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAA AgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWG h4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl 5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREA AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYk NOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk 5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDkKdHTadHX0h8eiylTpUCVOlSzRFmOp46g jqeOoZoixHVlOgqtHVlOgrNmiJ0qzHVZKsx1mzVFiPtU8dQR9qnjqGaIsrU6VAtTpUGqLMdW EqvHVhKzZoiwnarCVXTtVhKhmqLMfap4+tQR9qnj61DNEWI6njqCOp46zZqiynSn0xOlPqDQ KKKKACiiigAooooAKKKKACimu6xozuwVFGWYnAA9a4ab4v8Ag+KZ4/ts8gU43pbsVP0OKlyU d2a06FSr/Di36Hd0VzGo+P8AQdJsrO5vpZ4TdrvihaE+bt/vFeqj61BpfxK8MavqEVjb3kiT ynbGJYigY9hk8ZrZUako86i7HPKpCMuST1OuopryJEu6R1RfVjgUoIYAggg8gisyxaKYZog5 QyoGAyV3DIFEcscoJjkVwOpU5oHYfRUfnw7ynmx7h1XcMiljmjlBMciPjrtYHFAWY+ioTd2w JBuIgR1G8Uoubds7Z4zgZOHHAoCzJaKakkcq7o3Vx0ypzTGurdSQ08QI6guKAsyWiml0Cbyy 7MZ3Z4xTFurd2CrPEzHoA4JNAWZLRUP2u2/5+Iv++xUiSxyjMbq4HdTmgLMdRUP2u2/5+If+ +xTo54pSRHKjkddrA0BZklFFFAj5Rp0dNp0dfSHx6LKVOlQJU6VLNEWY6njqCOp46hmiLEdW U6Cq0dWU6Cs2aInSrMdVkqzHWbNUWI+1Tx1BH2qeOoZoiytTpUC1OlQaosx1YSq8dWErNmiL CdqsJVdO1WEqGaosx9qnj61BH2qePrUM0RYjqeOoI6njrNmqLKdKfTE6U+oNAooooAKKKKAC iiigAooooAyfFHHhLWcf8+M//otq8X8M33h/QPh3Dqt5pFre6vJdyLaGWME5Xack+i5Fe1eJ Y3l8LavHGpZ3splVQOSShwK8H8N674Qh8KWlrrqXst7Y3EtxBHACFYttIBPTkqKmLpRrRdX4 T0KUK9TBVI4f4rotWOmx3lvN4y8Y3BkglzJbQmUKb113Zj9VHygAelGsXWk6lJ4V1TSdIi0t J7t0eKPGSUkQAkgD1NVy998QtSuNY1ic6Z4dtSDNtcmNCBjbGD1dvYd/wq9r+r6FrOreFdP8 MwSrBZzCMRGIr1dD+J4JJr0sLXrYiv7S1oK/psebj8HhsFh1RbvWbTfkd38Zv+RAf/r6i/ma 4TwD8RR4d8MarYXshd4IzNp6vzljxs+mSD9N1ei/FbTb3VfBT22n2k11ObiNvLiXc2ATk4rk tO+FLa5oHhy4vN1hcQK0d9DJGQ8iCRiB7HBxn0I9K8aal7S8ex72Fnh/qfJX2cv+D/wDiPBt xPd6/q1xcyPLPLpV67u5yWJjPNei/An/AJF7VP8Ar7X/ANAFZeieEdSPxQ1rztMubbS7lLuB J/KIQI42rg9OnSqehQeP/h5Ne2FjoP2+CVw28RNIjEcblKkEZGODUQTi035nVipQxEJU4NJt Re5T/wCav+Iv+uV9/wCiWro/gN/yDta/66w/+gtVLwv4O8R3mqa34m1qze2nmtbgRwFcPLJI hHC9gAcc+1ZXg+Xx34MguorHwrcTC5ZWcz278FQRxgj1ojeMlJruFflq0ZUoSV0orfsHxM8B 2/hiFdWiv5Z3vbxw0boAE3bm4IrVsPA0GifDrUvEUd9LLJfaKQ0LIAqbwrcH2xitb4j2Wu+J PAmhSLpM76g0qy3FvDESYiYznjqOTXQXWm3r/Bv+zltZje/2UsX2fb8+/YBtx61XIuZ2XQ53 i6nsKalLXms9tkzyaz1y90f4RPFYzPC97qzxSSIcMEESkgHtnium0b4LW2p6JZX1xrVwktzC szKkQIXcM4yeT1qnYeANa1T4XTWbWUtvqNtqTXMUE42GVTGqkDP6fSr2m+KviTpOmW+nr4Ta ZbaMRLI9s+SFGBnBwePSpil9taWOirUm1L6tNKXM76r5bmJ8R7yWLxJYeFrjUZYNI0+3giZ1 UnPyjMhUfeOMYFXfAuh+ELjxjYNpWv39xeQMZkiltNittHOTVvxx4T8RXmr6b4sstLW7mlgh a6szHv8ALlVRlSh6qemOvFXvC+peJF8SWKy+ALDTYZJNkt1DYNG0aEcndnii3v6ol1P9lSpy 6O+qWvW63PMtFsND1DWL6PXdXfTIFLGORIi+9t3TAB7Vt+HriLQfiPp1t4Y1afULK4ljilYx lBIGOGBXvgc5x2rf+HngSS48Rap/wkugSm1KEwm6iIUtv7e+KuWfhK98P/GaCfSdKuI9Gz/r VQtGitH8w3Hp81TGDsn5m1bFU5SnT5r+7tpbb77nJfETwJb+CksZIL+W6N20mRIgXbtweMfW vVvh94Dt/CqvqEV/LcNe28e5HQAL/Fxj61i/GfRNU1mDSBpmn3N4YzNv8mMttyFxnH0NelaY jxaTZxupV1gRWU9QQo4raFNKo9DzcVi6k8HBOV273276Fqiiiug8c+UadHTadHX0h8eiylTp UCVOlSzRFmOp46gjqeOoZoixHVlOgqtHVlOgrNmiJ0qzHVZKsx1mzVFiPtU8dQR9qnjqGaIs rU6VAtTpUGqLMdWEqvHVhKzZoiwnarCVXTtVhKhmqLMfap4+tQR9qnj61DNEWI6njqCOp46z ZqiynSn0xOlPqDQKKKKACiiigAooooAKKKKACsWXwh4cnlaWXQtOaRzlmNsuSfXpW1RSaT3K jOUfhdjNfw9o0thFYvpdo1pCd0cBiGxT6hemaSy8O6Lp1wLiy0qyt5gMCSOFVYfQ4rToq1KS Vk9CGk3zPcKKKKkYUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAH/2Q== --------------060705050402080307010006-- --------------020908070306050005030907-- From ca3x@bestofhealth.com Fri Jun 6 08:40:34 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 214933A69FA; Fri, 6 Jun 2008 08:40:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -87.369 X-Spam-Level: X-Spam-Status: No, score=-87.369 tagged_above=-999 required=5 tests=[BAYES_60=1, FH_RELAY_NODNS=1.451, HELO_EQ_MODEMCABLE=0.768, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, 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 LJaFK-h7Q8WK; Fri, 6 Jun 2008 08:40:33 -0700 (PDT) Received: from Dynamic-IP-19015910953.cable.net.co (unknown [190.159.109.53]) by core3.amsl.com (Postfix) with SMTP id 08B6B3A6967; Fri, 6 Jun 2008 08:40:18 -0700 (PDT) X-Originating-IP: 229.52.32.170 by smtp.190.159.109.53; Fri, 06 Jun 2008 11:40:27 -0500 Message-ID: From: "Darnell Campbell" Reply-To: "Darnell Campbell" To: sipping-bounces@ietf.org Subject: Impressive Glashutte timepieces Date: Fri, 06 Jun 2008 11:40:27 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit An IWC watch is a uniquely handcrafted time piece that combines a classical element with a timeless elegance. Its appeal comes from their traditional beauty and their superb performance. But this sophistication has always come with a high price tag. Except of course, when you buy an IWC replica. And Prestige Replicas has dozens of IWC replica watches at prices so incredibly low that you can rest assured they won't last long! So, why not head over to Prestige Replicas right now and take a look at their IWC watches? After all, isn't it time you wore a splendid wristwatch without having to spend a fortune? http://panyrosovin43.blogspot.com/ From caceres@boliviagiros.com Fri Jun 6 14:36:08 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 615473A69EF; Fri, 6 Jun 2008 14:36:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -81.68 X-Spam-Level: X-Spam-Status: No, score=-81.68 tagged_above=-999 required=5 tests=[BAYES_60=1, FH_HELO_EQ_D_D_D_D=1.597, FH_RELAY_NODNS=1.451, HELO_DYNAMIC_IPADDR2=4.395, J_CHICKENPOX_24=0.6, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_RECV_SPEEDY_AR=0.808, TVD_RCVD_IP=1.931, 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 HNnTmaGpWQCu; Fri, 6 Jun 2008 14:36:07 -0700 (PDT) Received: from 190-172-167-217.speedy.com.ar (unknown [190.172.167.217]) by core3.amsl.com (Postfix) with SMTP id E5D133A6911; Fri, 6 Jun 2008 14:35:46 -0700 (PDT) X-Originating-IP: 160.96.12.17 by smtp.190.172.167.217; Fri, 06 Jun 2008 17:35:57 -0500 Message-ID: From: "Gilbert Chin" Reply-To: "Gilbert Chin" To: qy@megatron.ietf.org Subject: The affordable watch alternative Date: Fri, 06 Jun 2008 17:35:57 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit A Bvlgari watch is an extraordinary masterpiece that is born from the marriage of watch making and jewelry expertise. Only the most discriminating and sophisticated watch users dare put a Bv1gari on their wrists, but once the metal touches their skin, they are bound forever... How would you like to become one of the lucky few that have experienced the pleasure of sporting a Bvlgari timepiece? Now you can, and at a very reduced cost! Prestige Replicas offers a tremendous collection of Bvlgari replicas starting just a little above $200... So now there is no reason why you can't have your very own Bvlgari today! http://fysyzenanyr16.blogspot.com/ From c.poulin@sphere-qc.ca Fri Jun 6 20:11:26 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 F31A23A67F8; Fri, 6 Jun 2008 20:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -59.056 X-Spam-Level: X-Spam-Status: No, score=-59.056 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FB_QUALITY_REPLICA=10.357, FH_HELO_EQ_D_D_D_D=1.597, FH_RELAY_NODNS=1.451, FS_REPLICA=0.994, GB_ROLEX=5, HELO_DYNAMIC_IPADDR2=4.395, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_RECV_SPEEDY_AR=0.808, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX=1.666, SARE_SPEC_ROLEX_HIQLT=1.666, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_REP=1.666, TVD_RCVD_IP=1.931, 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 XKb6lc1ah2GA; Fri, 6 Jun 2008 20:11:25 -0700 (PDT) Received: from 190-51-127-62.speedy.com.ar (unknown [190.51.127.62]) by core3.amsl.com (Postfix) with SMTP id 44D253A67AA; Fri, 6 Jun 2008 20:11:20 -0700 (PDT) X-Originating-IP: 134.72.223.48 by smtp.190.51.127.62; Fri, 06 Jun 2008 23:11:31 -0500 Message-ID: From: "Pauline Connell" Reply-To: "Pauline Connell" To: smime-archive@megatron.ietf.org Subject: Rolex replica is a ultimate gift Date: Fri, 06 Jun 2008 23:11:31 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Prestige Replicas is now bigger and better than ever before! I'm sure you're familiar with this popular replica store, so I'm glad to announce that Prestige Replicas has been completely redesigned and now offers not only the highest quality replica watches but also handbags and jewelry! In addition, they're running a 15% special these days when you buy two watches! There's never been a better time to buy a replica watch, especially a Tag Heuer! With prices as low as $200, and the store unmatched privacy assurance guarantee, I'm sure you won't want to wait to get your superior quality Tag Heuer replica! http://rusaxuhelop33.blogspot.com/ From c.reichert@oneeleven.de Fri Jun 6 23:38: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 36E843A6902; Fri, 6 Jun 2008 23:38:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -70.405 X-Spam-Level: X-Spam-Status: No, score=-70.405 tagged_above=-999 required=5 tests=[BAYES_80=2, FH_HELO_EQ_D_D_D_D=1.597, FH_RELAY_NODNS=1.451, FS_REPLICA=0.994, FS_REPLICAWATCH=10.357, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_CPE=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, 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 ZxpotYBS+B62; Fri, 6 Jun 2008 23:38:38 -0700 (PDT) Received: from cpe-190-55-103-55.telecentro.com.ar (unknown [190.55.103.55]) by core3.amsl.com (Postfix) with SMTP id 2DAEC3A67EB; Fri, 6 Jun 2008 23:38:30 -0700 (PDT) X-Originating-IP: 245.132.56.225 by smtp.190.55.103.55; Sat, 07 Jun 2008 02:38:42 -0500 Message-ID: From: "Domingo Petersen" Reply-To: "Domingo Petersen" To: sipping-bounces@ietf.org Subject: Hot replica watches from 2008 Date: Sat, 07 Jun 2008 02:38:42 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit A Breitling watch is a statement not just of wealth, but of sophistication... it's a way to show the world that you are a man in charge of your life and that you know exactly what you want. Surely, among those things you do want is a bigger budget. So, why not kill two birds with one stone? Getting a replica Breitling wristwatch and keeping your budget practically untouched! http://newicumavis20.blogspot.com/ Thanks to Prestige Replicas it is now possible! With an astonishing collection of replica Breitling timepieces at rock bottom prices, Selissia will make the delights of quality watches lovers. It offers excellent quality timepieces at unsurpassed prices; a privacy-assured guarantee, incomparable customer service, and what's better: 15% off when you buy two watches! http://newicumavis20.blogspot.com/ From owner-ietf-smime@mail.imc.org Sat Jun 7 01:41: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 708833A6A4E for ; Sat, 7 Jun 2008 01:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.128 X-Spam-Level: X-Spam-Status: No, score=-1.128 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, 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 GD2J2RUM5tL3 for ; Sat, 7 Jun 2008 01:41:47 -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 7256B3A6A28 for ; Sat, 7 Jun 2008 01:41:46 -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 m578NaZb059761 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 7 Jun 2008 01:23:36 -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 m578Na8h059760; Sat, 7 Jun 2008 01:23:36 -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 m578NTIg059718 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Sat, 7 Jun 2008 01:23:31 -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; Sat, 7 Jun 2008 12:26:45 +0400 Received: from smirnovxp64 ([192.168.68.187] RDNS failed) by mx4.cryptopro.ru with Microsoft SMTPSVC(6.0.3790.3959); Sat, 7 Jun 2008 12:26:45 +0400 From: "Pavel V. Smirnov" To: "'Peter Rybar'" , "'Pope, Nick'" , , "'Denis Pinkas'" CC: References: <6FC9E49ED3472043A38619BFA97F37B5018746B1@webmail.thales-esecurity.com> <200806050903.m5593V5d006047@mail.nbusr.sk> In-Reply-To: <200806050903.m5593V5d006047@mail.nbusr.sk> Subject: RE: Extending CAdES to support usual signature upgrading to CAdES-T and further Date: Sat, 7 Jun 2008 12:26:42 +0400 Message-ID: <000001c8c878$38a5f490$a9f1ddb0$@ru> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C8C899.BFB79490" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcjGIpMmSh21HPObR1m3lQZM/IvlEAAtqK0QAD90wvA= Content-Language: ru X-OriginalArrivalTime: 07 Jun 2008 08:26:45.0218 (UTC) FILETIME=[38A75420:01C8C878] Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ------=_NextPart_000_0001_01C8C899.BFB79490 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Peter, Nick, Denis, First of all, thanks for your attention. =20 Peter, Denis, I agree that suggested CAdES-T-with-certref-in-timestamp does not = provide exactly the same protection as usual CAdES-T. But there is a = strong need to extend a lifetime of already-done usual signatures going = to some kind of archive. Why doesn=E2=80=99t one use CAdES attributes to = achieve this? OK. Let=E2=80=99s not call such signatures CAdES-T, CAdES-C etc. But = let=E2=80=99s define a new branch of CAdES without signing certificate = reference in a signed attribute. There is an obvious benefit to = standardize these formats rather than anyone will do on its own. My = suggestion is mainly related to standardizing using timestamp extension = for this purpose. =20 >CadES requires the signing certificate reference. This is not going to = change. >You would like to time-stamp non-CAdES signatures. You can certainly = do this, but do not call this CAdES-T. >Placing the reference in the time-stamp token would not provide the = same protection. =20 Peter, I agree that it is a matter of good style to include validation data for = a timestamp in itself. I just wanted to point to a drawback implied by = this requirement. We may accept it and we may try to settle it. Another way to settle it is to hash the CAdES-T timestamp in a = CAdES-C-timestamp selectively, notably without attributes containing = certificate and revocation values. =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 Peter Rybar Sent: Thursday, June 05, 2008 1:03 PM To: 'Pope, Nick'; 'Pavel V. Smirnov'; ESI@LIST.ETSI.ORG; = ietf-smime@imc.org Cc: peterryb@gmail.com Subject: RE: Extending CAdES to support usual signature upgrading to = CAdES-T and further =20 Pavel, In my opinion, like in previous mail, the AdES signatures could in 3 = important sates from the time perspective. And for these 3 states there is important that the signature in the 1st = state contains the information about the signer certificate protected by = signature. The 2nd state of the signature is mainly important for validation of = expired certificates and in this case signature must contain evidence = that the signature was created before expiration of signer certificate = e. g. through signature timestamp and any revocation list or OCSP which = could contain information about potential revocation must be available = for verifier.=20 The 3rd state of the signature is important for the long term = validation. Signature in this state must contain not only all = certificates and revocation lists or OCSPs which could contain = information about potential revocation but also the integrity of all = this information must be protected because some algorithms can become = not secure. In this case the signature and all information must be = protected with additional more secure HASH (for integrity) in time when = lastly used integrity hash was considered as secure it is usually = achived by archive timestamp. =20 AdES offers for implementers many attributes which could be used to = satisfy these requirements of these 3 states and you NEED NOT to use all = of them. In my opinion it could be very helpful if some security annex of AdES = standard will contain any recommendation which attribute is useful to = protect which security attack or in which system its usage is important. =20 In this case, in my opinion, the following attributes are important for = the common usage.=20 =20 1st state id-contentType=20 id-messageDigest=20 id-aa-ets-signingCertificateV2 or id-aa-signingCertificate =20 2nd state id-contentType=20 id-messageDigest=20 id-aa-ets-signingCertificateV2 or id-aa-signingCertificate id-aa-signatureTimeStampToken Signature must contain certificates for validation of the signature and = the whole certification path with CRL or OCSP and if there are used = indirect CRL or OCSP then also certificates for its validation. =20 3rd state id-contentType=20 id-messageDigest=20 id-aa-ets-signingCertificateV2 or id-aa-signingCertificate id-aa-signatureTimeStampToken Signature must contain certificates for validation of the signature and = the whole certification path with CRL or OCSP and if there are used = indirect CRL or OCSP then also certificates for its validation. Each signature of the timestamp must contain certificates for validation = of the timestamp signature and the whole certification path with CRL or = OCSP and if there are used indirect CRL or OCSP then also certificates = for its validation. Any subsequent id-aa-ets-archiveTimestamp can be applied only if = previous one contains all verification information. =20 Timestamp itself is electronic signature and in this case the = verification information must only be added to the timestamp and not to = de signature which was time stamped. !!! =20 Peter =20 > Notably, one must store certificate and revocation values for = signature-timestamp validation in the timestamp itself, hence, after = receiving CAdES-C-timestamp one cannot add or remove these values from = signature-timestamp. =20 >An obvious solution is to allow to include timestamp validation data in = certificate-values and revocation-values attributes of the signature = itself. What do you think? =20 ---------- Forwarded message ---------- From: Peter Rybar g Date: Wed, 4 Jun 2008 17:41:55 +0200 Subject: Re: Extending CAdES to support usual signature upgrading to CAdES-T and further To: spv@cryptopro.ru Cc: ietf-smime@imc.org, ESI@list.etsi.org, = Nick.Pope@thales-esecurity.com =20 Pavel, A signer protects his certificate with his signature.=20 It must be only under his control that the verifier will use only his = certificate.=20 The signer certificate is usually protected by hash value of signer = certificate inside in the signed attributes signed by SIGNER or it could = by done when the certificate is present in the signed document like in = the PDF signature. The "security expiration" of the HASH algorithm used in the signed = attributes like reference to the signer certificate in the long term = validation is another important issue!!! !!!=20 It requires archive timestamp or secure HASH in archiving system used in = time when the hash algorithm in the signature was secure and must = include also the certificate value. Your suggest to use the timestamp for it but it is not correct because = the timestamp could be removed with another timestamp and in this case = there is no protection from the substitution attack of the signer = certificate. =20 It is the same as the usage of the MIME-TYPE of the signed document to = prevent signatures from the attack of changing the type of the = visualization of the signed document. Example is on the page: http://elpi2.szm.com/priklad.htm And one possible solution how to prevent the signature from this attack = is in the document http://www.nbusr.sk/en/electronic-signature/approved-formats/index.html http://www.nbusr.sk/ipublisher/files/nbusr.sk/elektronicky-podpis/legisla= tiva/9/specifyingcontentformalspecofdocqes_en_071.pdf =20 This attack is similar as the substitution attack of the signer = certificate.=20 Only the signer is able with his signature to protect important = information which must be used by the verifier in the visualization of = the signed document.=20 =20 It is the attack on the signed document which contains quite correct = information but not only for one type of the document but also for two = or more types of the document. Then if we try to view it as the first = type of the document then the viewer will read information which is = relevant for the first type and another one will be ignored. The same = situation happens if we view it as the second type of the document where = the viewer will only recognize the information relevant to the second = type of the document and so on.=20 The problem occurs if we sign the document without information about the = type of the document which was shown to the signer. Then the verifier could see the different information. =20 For solving this attack the application must be able to do: * In the XAdES signature =E2=80=93 the type of the signed document must = be present in the MIME-TYPE element of DataObjectFormat signed = attribute. * In the CAdES signature =E2=80=93 the type of the signed document must = be present in the MIME-TYPE which must be in the MIME header which = envelopes the signed document.=20 * Or the type of the signed document is implicitly defined by the signed = document content containing the signature and rules of manipulation of = the signed data and document like in PDF signature. =20 In this case the signatures of some data without protected information = about the type of the data like the MIME-TYPE protected by the signature = could be hazardous similarly as signatures without the protection of the = signer certificate. =20 Peter =20 _____ =20 From: owner-ietf-smime@mail.imc.org = [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Pope, Nick Sent: Wednesday, June 04, 2008 10:37 AM To: 'Pavel V. Smirnov'; ESI@LIST.ETSI.ORG; ietf-smime@imc.org Subject: RE: Extending CAdES to support usual signature upgrading to = CAdES-T and further =20 Pavel, =20 I personally have some sympathy for your view. I will add this issue to = those for discussion at the next ETSI meeting later in June. =20 Nick =20 =20 -----Original Message----- From: Pavel V. Smirnov [mailto:spv@cryptopro.ru]=20 Sent: 26 May 2008 11:50 To: 'Pope, Nick'; ESI@LIST.ETSI.ORG; ietf-smime@imc.org Subject: Extending CAdES to support usual signature upgrading to CAdES-T = and further =20 Hello all and personally Nick, =20 In current CAdES wording a regular signature without at least one signed = attribute (Signing certificate reference) cannot be added with = timestamps and validation data to achieve CAdES-T or more advanced CAdES = signature. This need arises, e.g., in a system with existing regular = signatures. There is no chance to add the required attribute to the = already computed signature, but there is a strong need to add CAdES = properties to such signatures. =20 There is rather simple approach to achieve the same properties without = including signing certificate reference as a signed attribute. Let us = include this reference as an extension in the CAdES-T timestamp = (signature timestamp). To get such timestamp one would need to include = this extension in a timestamp request and a TSA would have to shift this = extension to a timestamp token. =20 Let us define the proposed extension to a timestamp protocol and call = the signature we get a valid CAdES-T signature. More advanced CAdES = signature types turn out from this new CAdES-T perfectly without any = modification. What do you think? =20 Pavel Smirnov Crypto-Pro Tel./Fax: +7 495 780-4820 WWW: http://www.CryptoPro.ru e-mail: spv@CryptoPro.ru =20 Consider the environment before printing this mail. "Thales e-Security Limited is incorporated in England and Wales with = company registration number 2518805. Its registered office is located at = 2 Dashwood Lang Road, The Bourne Business Park, Addlestone, Nr. = Weybridge, Surrey KT15 2NX. The information contained in this e-mail is confidential. It may also be = privileged. It is only intended for the stated addressee(s) and access = to it by any other person is unauthorised. If you are not an addressee = or the intended addressee, you must not disclose, copy, circulate or in = any other way use or rely on the information contained in this e-mail. = Such unauthorised use may be unlawful. If you have received this e-mail = in error please delete it (and all copies) from your system, please also = inform us immediately on +44 (0)1844 201800 or email = postmaster@thales-esecurity.com. Commercial matters detailed or referred = to in this e-mail are subject to a written contract signed for and on = behalf of Thales e-Security Limited".=20 ------=_NextPart_000_0001_01C8C899.BFB79490 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Peter, = Nick, Denis,

First of = all, thanks for your attention.

 

Peter, = Denis,

I agree = that suggested CAdES-T-with-certref-in-timestamp does not provide exactly the = same protection as usual CAdES-T. But there is a strong need to extend a = lifetime of already-done usual signatures going to some kind of archive. Why = doesn=E2=80=99t one use CAdES attributes to achieve this?

OK. = Let=E2=80=99s not call such signatures CAdES-T, CAdES-C etc. But let=E2=80=99s define a new = branch of CAdES without signing certificate reference in a signed attribute. There is an obvious benefit to standardize these formats rather than anyone will do = on its own. My suggestion is mainly related to standardizing using timestamp = extension for this purpose.

 

>CadES requires the signing certificate reference. This is not going to = change.

 >You= would like to time-stamp non-CAdES signatures. You can certainly do = this, but do not call this CAdES-T.

>Placing the reference in the time-stamp token would not provide the same = protection.

 

Peter,

I agree = that it is a matter of good style to include validation data for a timestamp in = itself. I just wanted to point to a drawback implied by this requirement. We may = accept it and we may try to settle it.

Another = way to settle it is to hash the CAdES-T timestamp in a CAdES-C-timestamp selectively, = notably without attributes containing certificate and revocation = values.

 

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 Peter = Rybar
Sent: Thursday, June 05, 2008 1:03 PM
To: 'Pope, Nick'; 'Pavel V. Smirnov'; ESI@LIST.ETSI.ORG; ietf-smime@imc.org
Cc: peterryb@gmail.com
Subject: RE: Extending CAdES to support usual signature upgrading = to CAdES-T and further

 

 Pa= vel,

In my opinion, like in previous = mail, the AdES signatures could in 3 important sates from the time = perspective.

And for these 3 states there is = important that the signature in the 1st state contains the information about the = signer certificate protected by signature.

The 2nd state of the signature = is mainly important for validation of expired certificates and in this case = signature must contain evidence that the signature was created before expiration = of signer certificate e. g. through signature timestamp and any revocation = list or OCSP which could contain information about potential revocation must be available for verifier.

The 3rd state of the signature = is important for the long term validation. Signature in this state must contain not = only all certificates and revocation lists or OCSPs which could contain = information about potential revocation but also the integrity of all this = information must be protected because some algorithms can become not secure. In this case = the signature and all information must be protected with additional more = secure HASH (for integrity) in time when lastly used integrity hash was = considered as secure it is usually achived by archive timestamp.

 

AdES offers for implementers = many attributes which could be used to satisfy these requirements of these 3 = states and you NEED NOT to use all of them.

In my opinion it could be very = helpful if some security annex of AdES standard will contain any recommendation = which attribute is useful to protect which security attack or in which system = its usage is important.

 

In this case, in my opinion, the = following attributes are important for the common usage.

 

1st state

id-contentType =

id-messageDigest =

id-aa-ets-signingCertificateV2 or id-aa-signingCertificate

 

2nd state

id-contentType =

id-messageDigest =

id-aa-ets-signingCertificateV2 or id-aa-signingCertificate

id-aa-signatureTimeStampToken=

Signature must contain certificates for validation of the signature and the whole certification path with CRL or OCSP and if there are used indirect CRL = or OCSP then also certificates for its validation.

 

 3rd = state

id-contentType =

id-messageDigest =

id-aa-ets-signingCertificateV2 or id-aa-signingCertificate

id-aa-signatureTimeStampToken=

Signature must contain certificates for validation of the signature and the whole certification path with CRL or OCSP and if there are used indirect CRL = or OCSP then also certificates for its validation.

Each signature of the timestamp must contain certificates for validation of = the timestamp signature and the whole certification path with CRL or OCSP = and if there are used indirect CRL or OCSP then also certificates for its = validation.

Any subsequent id-aa-ets-archiveTimestamp can be = applied only if previous one contains all verification = information.

 

Timestamp itself is electronic = signature and in this case the verification information must only be added to the timestamp and not to de signature which was time stamped. = !!!

 

Peter

 

>  Notably, one must = store certificate and revocation values for signature-timestamp validation in = the timestamp itself, hence, after receiving CAdES-C-timestamp one cannot = add or remove these values from signature-timestamp.

 

>An obvious solution is to = allow to include timestamp validation data in certificate-values and = revocation-values attributes of the signature itself. What do you = think?

 

---------- Forwarded message = ----------

From: Peter Rybar g <peterryb@gmail.com>

Date: Wed, 4 Jun 2008 = 17:41:55 +0200

Subject: Re: Extending CAdES = to support usual signature upgrading to

CAdES-T and = further

To: = spv@cryptopro.ru

Cc: ietf-smime@imc.org, ESI@list.etsi.org, Nick.Pope@thales-esecurity.com

 

Pavel,

A signer protects his certificate with his signature. =

It must be only under his control that the verifier will use = only his certificate.

The signer certificate is usually protected by hash value of = signer certificate inside in the signed attributes signed by SIGNER or it could = by done when the certificate is present in the signed document like in the = PDF signature.

The "security expiration" of the HASH algorithm = used in the signed attributes like reference to the signer certificate in the = long term validation is another important issue!!! !!!

It requires archive timestamp or secure HASH in archiving = system used in time when the hash algorithm in the signature was secure and = must include also the certificate value.

Your suggest to use the timestamp for it but it is not = correct because the timestamp could be removed with another timestamp and in = this case there is no protection from the substitution attack of the signer = certificate.

 

It is the same as the usage of the MIME-TYPE of the signed = document to prevent signatures from the attack of changing the type of the = visualization of the signed document. Example is on the page:

http://elpi2.szm.com/priklad.ht= m

And one possible solution how to prevent the signature from = this attack is in the document

http://www.nbusr.sk/en/electronic-signature/approved-formats/inde= x.html

http://www= .nbusr.sk/ipublisher/files/nbusr.sk/elektronicky-podpis/legislativa/9/spe= cifyingcontentformalspecofdocqes_en_071.pdf

 

This attack is similar as the substitution attack of the = signer certificate.

Only the signer is able with his signature to protect = important information which must be used by the verifier in the visualization of = the signed document.

 

It is the attack on the signed document which contains quite correct information but not only for one type of the document but also = for two or more types of the document. Then if we try to view it as the first = type of the document then the viewer will read information which is relevant for = the first type and another one will be ignored. The same situation happens = if we view it as the second type of the document where the viewer will only = recognize the information relevant to the second type of the document and so on. =

The problem occurs if we sign the document without = information about the type of the document which was shown to the = signer.

Then the verifier could see the different = information.

 

For solving this attack the application must be able to = do:

* In the XAdES signature =E2=80=93 the type of the signed = document must be present in the MIME-TYPE element of DataObjectFormat signed = attribute.

* In the CAdES signature =E2=80=93 the type of the signed = document must be present in the MIME-TYPE which must be in the MIME header which = envelopes the signed document.

* Or the type of the signed document is implicitly defined = by the signed document content containing the signature and rules of = manipulation of the signed data and document like in PDF = signature.

 

In this case the signatures of some data without protected information about the type of the data like the MIME-TYPE protected by = the signature could be hazardous similarly as signatures without the = protection of the signer certificate.

 

Peter

 

From: owner-ietf-smime@mail.imc.org = [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Pope, Nick
Sent: Wednesday, June 04, 2008 10:37 AM
To: 'Pavel V. Smirnov'; ESI@LIST.ETSI.ORG; ietf-smime@imc.org
Subject: RE: Extending CAdES to support usual signature upgrading = to CAdES-T and further

 

Pavel,

 

I personally have some sympathy for your view.  I will = add this issue to those for discussion at the next ETSI meeting later in = June.

 

Nick

 

 

-----Origina= l Message-----
From: Pavel V. Smirnov [mailto:spv@cryptopro.ru]
Sent: 26 May 2008 11:50
To: 'Pope, Nick'; ESI@LIST.ETSI.ORG; ietf-smime@imc.org
Subject: Extending CAdES to support usual signature upgrading to = CAdES-T and further

 

Hello all and personally = Nick,

 

In current CAdES wording a = regular signature without at least one signed attribute (Signing certificate = reference) cannot be added with timestamps and validation data to achieve CAdES-T = or more advanced CAdES signature. This need arises, e.g., in a system with = existing regular signatures. There is no chance to add the required attribute to = the already computed signature, but there is a strong need to add CAdES = properties to such signatures.

 

There is rather simple approach = to achieve the same properties without including signing certificate reference as a = signed attribute. Let us include this reference as an extension in the CAdES-T timestamp (signature timestamp). To get such timestamp one would need to include this extension in a timestamp request and a TSA would have to = shift this extension to a timestamp token.

 

Let us define the proposed = extension to a timestamp protocol and call the signature we get a valid CAdES-T = signature. More advanced CAdES signature types turn out from this new CAdES-T = perfectly without any modification. What do you think?

 

Pavel Smirnov

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

 

Consider the = environment before printing this mail.

"Thales = e-Security Limited is incorporated in England and Wales with company registration = number 2518805. Its registered office is located at 2 Dashwood Lang Road, The = Bourne Business Park, Addlestone, Nr. Weybridge, Surrey KT15 = 2NX.

The information = contained in this e-mail is confidential. It may also be privileged. It is only = intended for the stated addressee(s) and access to it by any other person is = unauthorised. If you are not an addressee or the intended addressee, you must not = disclose, copy, circulate or in any other way use or rely on the information = contained in this e-mail. Such unauthorised use may be unlawful. If you have received = this e-mail in error please delete it (and all copies) from your system, = please also inform us immediately on +44 (0)1844 201800 or email postmaster@thales-esecurity.com. Commercial matters detailed or referred = to in this e-mail are subject to a written contract signed for and on behalf = of Thales e-Security Limited". =

------=_NextPart_000_0001_01C8C899.BFB79490-- From c.iachini@pesokey.it Sun Jun 8 10:34: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 1851C3A68F8; Sun, 8 Jun 2008 10:34:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -57.028 X-Spam-Level: X-Spam-Status: No, score=-57.028 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, FS_REPLICAWATCH=10.357, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HOST_EQ_BR=1.295, RCVD_IN_BL_SPAMCOP_NET=1.96, 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, TVD_RCVD_IP=1.931, 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 mcg-bLbWhqVX; Sun, 8 Jun 2008 10:34:45 -0700 (PDT) Received: from 189-11-108-108.ctaje701.dsl.brasiltelecom.net.br (189-11-108-108.ctaje701.dsl.brasiltelecom.net.br [189.11.108.108]) by core3.amsl.com (Postfix) with SMTP id 06FFB3A6912; Sun, 8 Jun 2008 10:34:30 -0700 (PDT) X-Originating-IP: 176.118.130.160 by smtp.189.11.108.108; Sun, 08 Jun 2008 13:34:45 -0500 Message-ID: From: "Lionel Sears" Reply-To: "Lionel Sears" To: sipping-bounces@ietf.org Subject: Replica watches make great gifts Date: Sun, 08 Jun 2008 13:34:45 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit X-Antivirus: avast! (VPS 080608-0, 08/06/2008), Outbound message X-Antivirus-Status: Clean A Breitling watch is a statement not just of wealth, but of sophistication... it's a way to show the world that you are a man in charge of your life and that you know exactly what you want. Surely, among those things you do want is a bigger budget. So, why not kill two birds with one stone? Getting a replica Breitling wristwatch and keeping your budget practically untouched! http://kucucomafuc62.blogspot.com/ Thanks to Prestige Replicas it is now possible! With an astonishing collection of replica Breitling timepieces at rock bottom prices, Selissia will make the delights of quality watches lovers. It offers excellent quality timepieces at unsurpassed prices; a privacy-assured guarantee, incomparable customer service, and what's better: 15% off when you buy two watches! http://kucucomafuc62.blogspot.com/ From cables@tones-n-things.com Sun Jun 8 15:17:19 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 203183A6A92; Sun, 8 Jun 2008 15:17:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -57.012 X-Spam-Level: X-Spam-Status: No, score=-57.012 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FB_QUALITY_REPLICA=10.357, 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, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DSL=1.129, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_BAYES_5x7=0.6, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_HIQLT=1.666, SARE_SPEC_ROLEX_NOV5A=1.062, TVD_RCVD_IP=1.931, 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 LA20h954PKKB; Sun, 8 Jun 2008 15:17:18 -0700 (PDT) Received: from 131-130-22-190.adsl.terra.cl (131-130-22-190.adsl.terra.cl [190.22.130.131]) by core3.amsl.com (Postfix) with SMTP id 5AD453A6844; Sun, 8 Jun 2008 15:17:14 -0700 (PDT) X-Originating-IP: 76.68.235.44 by smtp.190.22.130.131; Sun, 08 Jun 2008 18:17:39 -0500 Message-ID: From: "Hilary Duran" Reply-To: "Hilary Duran" To: smime-archive@megatron.ietf.org Subject: The discreet replica store Date: Sun, 08 Jun 2008 18:17:39 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Prestige Replicas is a one of a kind store: the online place where you can find the highest quality replica watches at the best prices in the world! Forget about flying to China to get a mockup Cartier watch... You can now get European quality Cartier replicas at deeply discounted prices at Prestige Replicas! The best part is that our watches are so finely crafted that even the most experienced connoisseur would have a hard time telling our watches from the real deal. http://cygirapirer35.blogspot.com/ Visit Prestige Replicas today and discover a wide range of top quality Cartier replica watches offered at unbelievable prices, with a 15% discount when you buy two! http://cygirapirer35.blogspot.com/ From c_fujii@hokusys.co.jp Sun Jun 8 17:26:34 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 1C3843A6973; Sun, 8 Jun 2008 17:26:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -50.257 X-Spam-Level: X-Spam-Status: No, score=-50.257 tagged_above=-999 required=5 tests=[BAYES_80=2, FB_REPLICA_ROLEX=3.157, FH_HELO_EQ_D_D_D_D=1.597, FH_RELAY_NODNS=1.451, FS_REPLICA=0.994, FS_REPLICAWATCH=10.357, GB_ROLEX=5, HELO_DYNAMIC_IPADDR2=4.395, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, REPLICA_WATCH=3.396, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX=1.666, SARE_SPEC_ROLEX_GENREP=1.666, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_REP=1.666, TVD_RCVD_IP=1.931, 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 f5RtZACO0upc; Sun, 8 Jun 2008 17:26:33 -0700 (PDT) Received: from 46-136-245-190.fibertel.com.ar (unknown [190.245.136.46]) by core3.amsl.com (Postfix) with SMTP id C8A9F3A69A5; Sun, 8 Jun 2008 17:26:13 -0700 (PDT) X-Originating-IP: 188.112.115.84 by smtp.190.245.136.46; Sun, 08 Jun 2008 20:26:29 -0500 Message-ID: From: "Ethan Ali" Reply-To: "Ethan Ali" To: sipping-bounces@ietf.org Subject: Take a look at the latest replica watches Date: Sun, 08 Jun 2008 20:26:29 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit When it comes down to getting a replica Rolex watch, there is just one place that offers its visitors and customers the highest quality available: Prestige Replicas. This unparalleled online store specializes in top of the line replica watches with unsurpassed performance, and bearing every marking that the genuine timepieces have. Every replica watch that Prestige Replicas carries, is made of solid stainless steel and features a sapphire crystal glass. What's more, every Rolex in store displays the green Rolex sticker with model number and logo on it. Just because you're buying a replica, don't settle for a low quality product. There are only a handful of online stores that offer the highest quality Rolex replica watches and Prestige Replicas is among them, and with the lowest available prices! http://detyzaniner01.blogspot.com/ From c.herbert@atelier-dusty.de Mon Jun 9 00:51:29 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 2B7CC3A688E; Mon, 9 Jun 2008 00:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -47.382 X-Spam-Level: X-Spam-Status: No, score=-47.382 tagged_above=-999 required=5 tests=[BAYES_80=2, FB_QUALITY_REPLICA=10.357, FH_HELO_EQ_D_D_D_D=1.597, FH_RELAY_NODNS=1.451, FS_REPLICA=0.994, FS_REPLICAWATCH=10.357, GB_ROLEX=5, HELO_DYNAMIC_IPADDR2=4.395, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX=1.666, SARE_SPEC_ROLEX_HIQLT=1.666, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_NOV5F=0.666, SARE_SPEC_ROLEX_REP=1.666, TVD_RCVD_IP=1.931, 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 z7bu4NgdaLvC; Mon, 9 Jun 2008 00:51:28 -0700 (PDT) Received: from 19-115-188-190.cab.prima.net.ar (unknown [190.188.115.19]) by core3.amsl.com (Postfix) with SMTP id C4A033A689E; Mon, 9 Jun 2008 00:51:18 -0700 (PDT) X-Originating-IP: 129.61.219.184 by smtp.190.188.115.19; Mon, 09 Jun 2008 03:51:44 -0500 Message-ID: From: "Robbie Rivers" Reply-To: "Robbie Rivers" To: smime-archive@megatron.ietf.org Subject: Replica watches made easy Date: Mon, 09 Jun 2008 03:51:44 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Have you always wanted a Rolex, but don't want to pay high prices for a brand name watch? Then you need to visit Prestige Replicas, a website dedicated exclusively to high quality replicas, with the most extensive inventory on the web and a proven track record of satisfied customers. http://voceceliguv46.blogspot.com/ Prestige Replicas offers hundreds of Rolex replica watches starting just above $100, and during this spring season, their already low prices have been slashed by 15 percent if you buy two or more watches! No matter which model Rolex you choose, their 15% discount applies to them all! But don't let this limited time offer go by... spring is ending and it's time to impress your friends with a realistic, high quality Rolex replica watch, that will look and perform just like the real deal! http://voceceliguv46.blogspot.com/ From c92o@nvastudio.com Mon Jun 9 04:35:58 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 3A4273A685D; Mon, 9 Jun 2008 04:35:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -63.73 X-Spam-Level: X-Spam-Status: No, score=-63.73 tagged_above=-999 required=5 tests=[BAYES_95=3, FB_REPLICA_ROLEX=3.157, GB_ROLEX=5, HELO_EQ_JP=1.244, HELO_EQ_NE_JP=1.244, HOST_EQ_JP=1.265, HOST_EQ_NE_JP=2.599, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, REPLICA_WATCH=3.396, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX=1.666, SARE_SPEC_ROLEX_GENREP=1.666, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_REP=1.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 2ZEd4GPQ6Nea; Mon, 9 Jun 2008 04:35:57 -0700 (PDT) Received: from p5137-ipbfp904tokaisakaetozai.aichi.ocn.ne.jp (p5137-ipbfp904tokaisakaetozai.aichi.ocn.ne.jp [125.200.174.137]) by core3.amsl.com (Postfix) with SMTP id 62B6628C0F9; Mon, 9 Jun 2008 04:35:45 -0700 (PDT) X-Originating-IP: 149.60.163.78 by smtp.125.200.174.137; Mon, 09 Jun 2008 07:36:04 -0500 Message-ID: From: "Lacey Bledsoe" Reply-To: "Lacey Bledsoe" To: sip-request@ietf.org Subject: Spring quality watches offer Date: Mon, 09 Jun 2008 07:36:04 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit When it comes down to getting a replica Rolex watch, there is just one place that offers its visitors and customers the highest quality available: Prestige Replicas. This unparalleled online store specializes in top of the line replica watches with unsurpassed performance, and bearing every marking that the genuine timepieces have. Every replica watch that Prestige Replicas carries, is made of solid stainless steel and features a sapphire crystal glass. What's more, every Rolex in store displays the green Rolex sticker with model number and logo on it. Just because you're buying a replica, don't settle for a low quality product. There are only a handful of online stores that offer the highest quality Rolex replica watches and Prestige Replicas is among them, and with the lowest available prices! http://dadivisakix77.blogspot.com/ From cabins@laurel-mountain-cabins.com Mon Jun 9 08:11: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 8C3FE3A69AA; Mon, 9 Jun 2008 08:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -63.752 X-Spam-Level: X-Spam-Status: No, score=-63.752 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FB_QUALITY_REPLICA=10.357, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DIALUP=0.862, HELO_EQ_DSL=1.129, HOST_EQ_DIALUP=0.862, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, 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_HIQLT=1.666, SARE_SPEC_ROLEX_NOV5A=1.062, 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 HFOM2m9Fgx5L; Mon, 9 Jun 2008 08:11:00 -0700 (PDT) Received: from r190-134-130-109.dialup.adsl.anteldata.net.uy (r190-134-130-109.dialup.adsl.anteldata.net.uy [190.134.130.109]) by core3.amsl.com (Postfix) with SMTP id 921EC28C15F; Mon, 9 Jun 2008 08:10:53 -0700 (PDT) X-Originating-IP: 144.52.181.48 by smtp.190.134.130.109; Mon, 09 Jun 2008 11:11:19 -0500 Message-ID: From: "Allyson Hanna" Reply-To: "Allyson Hanna" To: smime-archive@megatron.ietf.org Subject: Trim line or sport watch? You choose Date: Mon, 09 Jun 2008 11:11:19 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Prestige Replicas is now bigger and better than ever before! I'm sure you're familiar with this popular replica store, so I'm glad to announce that Prestige Replicas has been completely redesigned and now offers not only the highest quality replica watches but also handbags and jewelry! In addition, they're running a 15% special these days when you buy two watches! There's never been a better time to buy a replica watch, especially a Tag Heuer! With prices as low as $200, and the store unmatched privacy assurance guarantee, I'm sure you won't want to wait to get your superior quality Tag Heuer replica! http://wafehyrybob84.blogspot.com/ From c.sthilaire@maindanslamain.org Mon Jun 9 16:13:08 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 173BD3A68C1; Mon, 9 Jun 2008 16:13:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -80.264 X-Spam-Level: X-Spam-Status: No, score=-80.264 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, FM_DDDD_TIMES_2=1.999, FS_REPLICA=0.994, HELO_DYNAMIC_IPADDR=2.426, 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 rlfT4hPxjS9B; Mon, 9 Jun 2008 16:13:07 -0700 (PDT) Received: from pc-188-127-86-200.cm.vtr.net (pc-188-127-86-200.cm.vtr.net [200.86.127.188]) by core3.amsl.com (Postfix) with SMTP id AD0AA3A67D4; Mon, 9 Jun 2008 16:12:49 -0700 (PDT) X-Originating-IP: 139.20.91.24 by smtp.200.86.127.188; Mon, 09 Jun 2008 19:13:15 -0500 Message-ID: From: "Micheal Blue" Reply-To: "Micheal Blue" To: smime-archive@megatron.ietf.org Subject: The discreet replica store Date: Mon, 09 Jun 2008 19:13:15 -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://gyzywarezax23.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://gyzywarezax23.blogspot.com/ From c.noriega@ideasenmetal.com Tue Jun 10 02: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 4568C3A69E0; Tue, 10 Jun 2008 02:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -65.701 X-Spam-Level: X-Spam-Status: No, score=-65.701 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, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, FS_REPLICA=0.994, FS_REPLICAWATCH=10.357, HELO_DYNAMIC_IPADDR2=4.395, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, 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, TVD_RCVD_IP=1.931, 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 17yip0nQnfhx; Tue, 10 Jun 2008 02:02:54 -0700 (PDT) Received: from 230-127-17-190.fibertel.com.ar (230-127-17-190.fibertel.com.ar [190.17.127.230]) by core3.amsl.com (Postfix) with SMTP id 4C8BD3A69BB; Tue, 10 Jun 2008 02:02:32 -0700 (PDT) X-Originating-IP: 127.0.216.240 by smtp.190.17.127.230; Tue, 10 Jun 2008 05:02:51 -0500 Message-ID: From: "Hubert Huff" Reply-To: "Hubert Huff" To: sipping-bounces@ietf.org Subject: Replica watches make great gifts Date: Tue, 10 Jun 2008 05:02:51 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Everybody knows that a Cartier watch is a silent statement of wealth and luxury. But we all know as well that the price of putting one of them on your wrist is for the most unaffordable by the average Joe. That's why replica Cartier watches are becoming more and more popular by the day. They're actually the affordable solution to this dilemma. And thanks to the internet, there is now a place where the highest quality Cartier replicas are available: Prestige Replicas. So, why not take a look at the extensive inventory that this site has to offer? After all, browsing through their hundreds of Cartier watches is absolutely free, and buying the one of your dreams is simply inexpensive. http://gyzywarezax23.blogspot.com/ From c.lehmann@nbk.de Tue Jun 10 04:35: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 28A0428C188; Tue, 10 Jun 2008 04:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -56.316 X-Spam-Level: X-Spam-Status: No, score=-56.316 tagged_above=-999 required=5 tests=[BAYES_95=3, FB_REPLICA_ROLEX=3.157, FH_HOST_EQ_D_D_D_D=0.765, FS_REPLICA=0.994, FS_REPLICAWATCH=10.357, GB_ROLEX=5, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, REPLICA_WATCH=3.396, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX=1.666, SARE_SPEC_ROLEX_GENREP=1.666, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_REP=1.666, SARE_SUB_PERFECT=0.725, 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 1XuU8UswrBJC; Tue, 10 Jun 2008 04:35:42 -0700 (PDT) Received: from ppp-42-170.32-151.iol.it (ppp-42-170.32-151.iol.it [151.32.170.42]) by core3.amsl.com (Postfix) with SMTP id D89D83A6807; Tue, 10 Jun 2008 04:35:23 -0700 (PDT) X-Originating-IP: 32.226.248.232 by smtp.151.32.170.42; Tue, 10 Jun 2008 07:35:47 -0500 Message-ID: From: "Chad Cooley" Reply-To: "Chad Cooley" To: qy@megatron.ietf.org Subject: Replica watch is a perfect gift Date: Tue, 10 Jun 2008 07:35:47 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit When it comes down to getting a replica Rolex watch, there is just one place that offers its visitors and customers the highest quality available: Prestige Replicas. This unparalleled online store specializes in top of the line replica watches with unsurpassed performance, and bearing every marking that the genuine timepieces have. Every replica watch that Prestige Replicas carries, is made of solid stainless steel and features a sapphire crystal glass. What's more, every Rolex in store displays the green Rolex sticker with model number and logo on it. Just because you're buying a replica, don't settle for a low quality product. There are only a handful of online stores that offer the highest quality Rolex replica watches and Prestige Replicas is among them, and with the lowest available prices! http://nyvimiryguc11.blogspot.com/ From ca@nashoba.org Tue Jun 10 11:20:03 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 8C80F3A696B; Tue, 10 Jun 2008 11:20:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -73.212 X-Spam-Level: X-Spam-Status: No, score=-73.212 tagged_above=-999 required=5 tests=[BAYES_80=2, 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, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DSL=1.129, 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, TVD_RCVD_IP=1.931, 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 jGsJUDHChLp2; Tue, 10 Jun 2008 11:19:57 -0700 (PDT) Received: from 69-137-246-201.adsl.terra.cl (69-137-246-201.adsl.terra.cl [201.246.137.69]) by core3.amsl.com (Postfix) with SMTP id 67B2D3A6873; Tue, 10 Jun 2008 11:19:47 -0700 (PDT) X-Originating-IP: 164.56.82.96 by smtp.201.246.137.69; Tue, 10 Jun 2008 14:20:08 -0500 Message-ID: From: "Penny Maldonado" Reply-To: "Penny Maldonado" To: sipping-bounces@ietf.org Subject: Watches for him, her and you Date: Tue, 10 Jun 2008 14:20:08 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Since 1884 Bvlgari watches have drawn inspiration from the timeless beauty of Greek and Roman art. The time pieces that they produce are as much works of art, as a way to tell time, and now you can possess one of these splendid time pieces for a very affordable price, at Prestige Replicas. http://gabutafuhet31.blogspot.com/ This store has the finest collection of Bvlgari replica watches, and you will be astounded at the difference in price as well as amazed at the quality of their timepieces. Prestige Replicas works hard to make sure that your purchase is shipped as fast as your order is processed, and also that your private information is protected. And with the new redesign of the Prestige Replicas website, we are offering 15% off on your purchase of watches! http://gabutafuhet31.blogspot.com/ From owner-ietf-smime@mail.imc.org Wed Jun 11 17:00: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 8E0673A681B for ; Wed, 11 Jun 2008 17:00:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.896 X-Spam-Level: X-Spam-Status: No, score=-16.896 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, USER_IN_DEF_WHITELIST=-15] 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 Dvi8UjNLE9cA for ; Wed, 11 Jun 2008 17:00:19 -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 1E1673A67DA for ; Wed, 11 Jun 2008 17:00:18 -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 m5BNhXx0086181 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Jun 2008 16:43:33 -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 m5BNhXH3086180; Wed, 11 Jun 2008 16:43:33 -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 bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5BNhWqY086174 for ; Wed, 11 Jun 2008 16:43:32 -0700 (MST) (envelope-from rfc-editor@rfc-editor.org) Received: by bosco.isi.edu (Postfix, from userid 70) id 8DEB5136509; Wed, 11 Jun 2008 16:43:32 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 5275 on CMS Symmetric Key Management and Distribution From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, ietf-smime@imc.org Message-Id: <20080611234332.8DEB5136509@bosco.isi.edu> Date: Wed, 11 Jun 2008 16:43:32 -0700 (PDT) Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: A new Request for Comments is now available in online RFC libraries. RFC 5275 Title: CMS Symmetric Key Management and Distribution Author: S. Turner Status: Standards Track Date: June 2008 Mailbox: turners@ieca.com Pages: 89 Characters: 207920 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-smime-symkeydist-10.txt URL: http://www.rfc-editor.org/rfc/rfc5275.txt This document describes a mechanism to manage (i.e., set up, distribute, and rekey) keys used with symmetric cryptographic algorithms. Also defined herein is a mechanism to organize users into groups to support distribution of encrypted content using symmetric cryptographic algorithms. The mechanism uses the Cryptographic Message Syntax (CMS) protocol and Certificate Management over CMS (CMC) protocol to manage the symmetric keys. Any member of the group can then later use this distributed shared key to decrypt other CMS encrypted objects with the symmetric key. This mechanism has been developed to support Secure/Multipurpose Internet Mail Extensions (S/MIME) Mail List Agents (MLAs). [STANDARDS TRACK] This document is a product of the S/MIME Mail Security Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute From c.vrancken@bayard-presse.be Thu Jun 12 04:13: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 2286A3A67B7; Thu, 12 Jun 2008 04:13:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -49.175 X-Spam-Level: X-Spam-Status: No, score=-49.175 tagged_above=-999 required=5 tests=[BAYES_60=1, FB_QUALITY_REPLICA=10.357, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FS_REPLICA=0.994, FS_REPLICAWATCH=10.357, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_IP_ADDR=1.119, HOST_EQ_USERONOCOM=1.444, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RCVD_NUMERIC_HELO=2.067, RDNS_DYNAMIC=0.1, SARE_BAYES_5x7=0.6, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_HIQLT=1.666, SARE_SPEC_ROLEX_NOV5A=1.062, TVD_RCVD_IP=1.931, 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 Nliq-JYJMVZV; Thu, 12 Jun 2008 04:13:49 -0700 (PDT) Received: from 62.42.146.247.dyn.user.ono.com (62.42.146.247.dyn.user.ono.com [62.42.146.247]) by core3.amsl.com (Postfix) with SMTP id 5014928C0E4; Thu, 12 Jun 2008 04:13:34 -0700 (PDT) X-Originating-IP: 58.254.18.64 by smtp.62.42.146.247; Thu, 12 Jun 2008 07:14:01 -0500 Message-ID: From: "Lina Blanchard" Reply-To: "Lina Blanchard" To: sip-request@ietf.org Subject: Why replica watches are better Date: Thu, 12 Jun 2008 07:14:01 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Prestige Replicas is a one of a kind store: the online place where you can find the highest quality replica watches at the best prices in the world! Forget about flying to China to get a mockup Cartier watch... You can now get European quality Cartier replicas at deeply discounted prices at Prestige Replicas! The best part is that our watches are so finely crafted that even the most experienced connoisseur would have a hard time telling our watches from the real deal. http://cuguvinycod68.blogspot.com/ Visit Prestige Replicas today and discover a wide range of top quality Cartier replica watches offered at unbelievable prices, with a 15% discount when you buy two! http://cuguvinycod68.blogspot.com/ From c.tippmann@seasell.com Thu Jun 12 14:51: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 6CCF13A6930; Thu, 12 Jun 2008 14:51:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -64.85 X-Spam-Level: X-Spam-Status: No, score=-64.85 tagged_above=-999 required=5 tests=[BAYES_80=2, FB_QUALITY_REPLICA=10.357, FH_HOST_EQ_D_D_D_D=0.765, FS_REPLICA=0.994, GB_ROLEX=5, HELO_DYNAMIC_IPADDR=2.426, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_NJABL_PROXY=1.643, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_HIQLT=1.666, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_NOV5F=0.666, SARE_SPEC_ROLEX_REP=1.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 KCOqlYcHC5EK; Thu, 12 Jun 2008 14:51:24 -0700 (PDT) Received: from host109.200-43-104.telecom.net.ar (host109.200-43-104.telecom.net.ar [200.43.104.109]) by core3.amsl.com (Postfix) with SMTP id BF5CD3A6843; Thu, 12 Jun 2008 14:51:02 -0700 (PDT) X-Originating-IP: 39.152.122.52 by smtp.200.43.104.109; Thu, 12 Jun 2008 17:51:32 -0500 Message-ID: From: "Kris Ouellette" Reply-To: "Kris Ouellette" To: qy@megatron.ietf.org Subject: Get one of these awesome replicas Date: Thu, 12 Jun 2008 17:51:32 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Have you always wanted a Rolex, but don't want to pay high prices for a brand name watch? Then you need to visit Prestige Replicas, a website dedicated exclusively to high quality replicas, with the most extensive inventory on the web and a proven track record of satisfied customers. http://vyzubecikof37.blogspot.com/ Prestige Replicas offers hundreds of Rolex replica watches starting just above $100, and during this spring season, their already low prices have been slashed by 15 percent if you buy two or more watches! No matter which model Rolex you choose, their 15% discount applies to them all! But don't let this limited time offer go by... spring is ending and it's time to impress your friends with a realistic, high quality Rolex replica watch, that will look and perform just like the real deal! http://vyzubecikof37.blogspot.com/ From owner-ietf-smime@mail.imc.org Mon Jun 16 09:49: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 50FE83A6920 for ; Mon, 16 Jun 2008 09:49:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.359 X-Spam-Level: X-Spam-Status: No, score=-1.359 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_LWSHORTT=1.24] 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 i9kAI0S-eZ86 for ; Mon, 16 Jun 2008 09:49: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 10FF43A65A5 for ; Mon, 16 Jun 2008 09:49: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 m5GGTmtr060816 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Jun 2008 09:29: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 m5GGTmGt060815; Mon, 16 Jun 2008 09:29: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 smtp103.biz.mail.re2.yahoo.com (smtp103.biz.mail.re2.yahoo.com [68.142.229.217]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m5GGTksK060790 for ; Mon, 16 Jun 2008 09:29:47 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 64732 invoked from network); 16 Jun 2008 16:29:41 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@71.191.2.12 with login) by smtp103.biz.mail.re2.yahoo.com with SMTP; 16 Jun 2008 16:29:41 -0000 X-YMail-OSG: C7h9V_oVM1lZGoSqCssE8pmbci6NJwHYiXYmQuafJBu_uynWvW5iKbv5dyBPoErxyi_7RoblqiPzimgD.CvQOx8ANHeLoKW_kV8Wnb2X.1ovPg7K2YdYGpwtbML5mMB_W2E- X-Yahoo-Newman-Property: ymail-3 From: "Turner, Sean P." To: Subject: 3851bis Sec 2.2 Date: Mon, 16 Jun 2008 12:29:40 -0400 Organization: IECA, Inc. Message-ID: <8BBFA71B925B4214983807B7AB0D6BB7@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: AcjPzixyO35yHXJPR9qVEoboPrzqyg== Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: All, I have received three comments on section 2.2. I'm interested to see if anybody has the same or alternate views on the following q/a: 1. Is there an inconsistency between section 2.2 and 2.1; in section 2.1 SHA-1 is SHOULD- while in section 2.2 RSA with SHA-1 is MUST-? Relooking at this I think there is and RSA with SHA-1 ought to be SHOULD-. 2. Should we add DSA with SHA-256? I don't think so. The reason we ended up with the text was that RSA became unencumbered between v3 and v3.1. Now that RSA is unencumbered and governments seem to be fine with RSA (at least NIST is in the short term), I'm not sure it's a requirement for S/MIME. Is there anybody out there that thinks DSA with SHA-256 ought to be a requirement? 3. The "RSA or DSA" words for sending agents have been removed. Should we add that type of wording back in? I think we should because as it reads now sending agents SHOULD- support both RSA and DSA with SHA-1 when it really ought to be or. As a result, I think we should split the receiving and sending agents requirements in to separate bullets. spt From owner-ietf-smime@mail.imc.org Mon Jun 16 13:06:31 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 702833A6A57 for ; Mon, 16 Jun 2008 13:06:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[AWL=0.619, BAYES_00=-2.599, 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 4vr09AgiXSlr for ; Mon, 16 Jun 2008 13:06:28 -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 1EC1A3A6873 for ; Mon, 16 Jun 2008 13:06:27 -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 m5GJliMb027740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Jun 2008 12:47:44 -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 m5GJliwq027739; Mon, 16 Jun 2008 12:47:44 -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 smtp106.biz.mail.re2.yahoo.com (smtp106.biz.mail.re2.yahoo.com [206.190.52.175]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m5GJlg7s027731 for ; Mon, 16 Jun 2008 12:47:43 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 83633 invoked from network); 16 Jun 2008 19:47:42 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@71.191.2.12 with login) by smtp106.biz.mail.re2.yahoo.com with SMTP; 16 Jun 2008 19:47:41 -0000 X-YMail-OSG: WcE1NaAVM1mUV3RwiWYB.jnNA.X4lmliObqxCBR4wRhPY5v_NvxG5dTqsPbiWkj0Cjb5yNWHOuruThYqO6zuQfPMiWpsgQCKEjDdA.ZGYWkAeKNDhm_qagfuCTVoxiEGKFg- X-Yahoo-Newman-Property: ymail-3 From: "Turner, Sean P." To: Subject: Registering smime-types Date: Mon, 16 Jun 2008 15:47:40 -0400 Organization: IECA, Inc. Message-ID: <86122207A729424EB57C7A85BDDDF79F@Wylie> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0109_01C8CFC8.4F232010" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 Thread-Index: AcjP6dW7Y/XzH/dLTrO7QcxDkOuDxA== 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_0109_01C8CFC8.4F232010 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Alfred's comment about updating the IANA registry for pkcs7-smime and pkcs7-signature got me to thinking about the smime-types that are currently used. signed-data, enveloped-data, certs-only, and compressed-data are addressed in RFC 3851 but the other content types we've defined (authenticated-data, encrypted-data, and authEnveloped-data) and others (content-with-attributes, content-collection, and others) don't have smime-types defined. Are these others used/defined someplace I don't know about? spt ------=_NextPart_000_0109_01C8CFC8.4F232010 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Registering smime-types

Alfred's comment about updating the = IANA registry for pkcs7-smime and pkcs7-signature got me to thinking = about the smime-types that are currently used.  signed-data, = enveloped-data, certs-only, and compressed-data are addressed in RFC = 3851 but the other content types we've defined (authenticated-data, = encrypted-data, and authEnveloped-data) and others = (content-with-attributes, content-collection, and others) don't have = smime-types defined.  Are these others used/defined someplace I = don’t know about?

spt

------=_NextPart_000_0109_01C8CFC8.4F232010-- From owner-ietf-smime@mail.imc.org Mon Jun 16 14:32: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 8C7A73A67B7 for ; Mon, 16 Jun 2008 14:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.467 X-Spam-Level: X-Spam-Status: No, score=-101.467 tagged_above=-999 required=5 tests=[AWL=-1.129, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, MSGID_FROM_MTA_HEADER=0.803, 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 MveOFQrIr97k for ; Mon, 16 Jun 2008 14:32: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 7A6EC3A67B1 for ; Mon, 16 Jun 2008 14:32: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 m5GLLkio060244 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Jun 2008 14:21: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 m5GLLkqS060243; Mon, 16 Jun 2008 14:21: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 woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m5GLLi1A060217 for ; Mon, 16 Jun 2008 14:21:45 -0700 (MST) (envelope-from housley@vigilsec.com) Message-Id: <200806162121.m5GLLi1A060217@balder-227.proper.com> Received: (qmail 32343 invoked by uid 0); 16 Jun 2008 21:21:36 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (72.66.14.12) by woodstock.binhost.com with SMTP; 16 Jun 2008 21:21:36 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 16 Jun 2008 17:21:29 -0400 To: "Turner, Sean P." From: Russ Housley Subject: Re: Registering smime-types Cc: ietf-smime@imc.org In-Reply-To: <86122207A729424EB57C7A85BDDDF79F@Wylie> References: <86122207A729424EB57C7A85BDDDF79F@Wylie> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The MIME types used by S/MIME are defined.  Not every CMS content type has a MIME type.  They could be defined, but up to now, we have been waiting for the need to surface first.

Russ

At 03:47 PM 6/16/2008, Turner, Sean P. wrote:

Alfred's comment about updating the IANA registry for pkcs7-smime and pkcs7-signature got me to thinking about the smime-types that are currently used.  signed-data, enveloped-data, certs-only, and compressed-data are addressed in RFC 3851 but the other content types we've defined (authenticated-data, encrypted-data, and authEnveloped-data) and others (content-with-attributes, content-collection, and others) don't have smime-types defined.  Are these others used/defined someplace I don’t know about?

spt
From smime-editor@rsa.com Wed Jun 18 05:50:10 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 0A47528C197 for ; Wed, 18 Jun 2008 05:50:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -39.325 X-Spam-Level: X-Spam-Status: No, score=-39.325 tagged_above=-999 required=5 tests=[BAYES_80=2, FH_HOST_EQ_D_D_D_D=0.765, GB_I_LETTER=-2, HELO_DYNAMIC_DHCP=1.398, HELO_EQ_DSL=1.129, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_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 M8AunOyMiqHN for ; Wed, 18 Jun 2008 05:50:00 -0700 (PDT) Received: from adsl-dyn143.91-127-1.t-com.sk (adsl-dyn143.91-127-1.t-com.sk [91.127.1.143]) by core3.amsl.com (Postfix) with SMTP id 232D228C0F9 for ; Wed, 18 Jun 2008 05:49:58 -0700 (PDT) Content-Return: allowed X-Mailer: CME-V6.5.4.3; MSN Message-Id: <20080618035101.5506.qmail@adsl-dyn143.91-127-1.t-com.sk> To: Subject: Dear smime-archive@ietf.org Savings ...3 Days Only From: Jeanie Nunez MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Date: Wed, 18 Jun 2008 05:49:58 -0700 (PDT)
Click Here!
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

©2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 98052
From smime.p7i@irib.ir Wed Jun 18 05:50: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 80BD63A6852 for ; Wed, 18 Jun 2008 05:50:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -35.325 X-Spam-Level: X-Spam-Status: No, score=-35.325 tagged_above=-999 required=5 tests=[BAYES_80=2, FH_HOST_EQ_D_D_D_D=0.765, GB_I_LETTER=-2, HELO_DYNAMIC_DHCP=1.398, HELO_EQ_DSL=1.129, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, 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_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_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 IuaVXBCnCOOv for ; Wed, 18 Jun 2008 05:50:05 -0700 (PDT) Received: from adsl-dyn143.91-127-1.t-com.sk (adsl-dyn143.91-127-1.t-com.sk [91.127.1.143]) by core3.amsl.com (Postfix) with SMTP id 86DC63A684F for ; Wed, 18 Jun 2008 05:50:01 -0700 (PDT) Content-Return: allowed X-Mailer: CME-V6.5.4.3; MSN Message-Id: <20080618035105.5510.qmail@adsl-dyn143.91-127-1.t-com.sk> To: Subject: Dear smime-archive@lists.ietf.org Savings ...3 Days Only From: Jeanie Nunez MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Date: Wed, 18 Jun 2008 05:50:01 -0700 (PDT)
Click Here!
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

©2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 98052
From owner-ietf-smime@mail.imc.org Wed Jun 18 08:17:56 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 123343A67E2 for ; Wed, 18 Jun 2008 08:17:56 -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 UPOGq+0p4VKA for ; Wed, 18 Jun 2008 08:17:55 -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 6D3993A68B1 for ; Wed, 18 Jun 2008 08:17:54 -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 m5IEoeXA043466 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Jun 2008 07:50: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 m5IEoeCA043465; Wed, 18 Jun 2008 07:50: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 smtp103.biz.mail.re2.yahoo.com (smtp103.biz.mail.re2.yahoo.com [68.142.229.217]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m5IEocvf043448 for ; Wed, 18 Jun 2008 07:50:39 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 82598 invoked from network); 18 Jun 2008 14:50:36 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@96.241.93.89 with login) by smtp103.biz.mail.re2.yahoo.com with SMTP; 18 Jun 2008 14:50:35 -0000 X-YMail-OSG: .r2ejeoVM1mUpCzwK8BqCEz_UTJ6P1cu_6YVnepch8ySCtkmd5o8Ly.GM_gZ7BH7elHQd7PVtXdU.Uym1.vo3uWetyHxeApDyi0LD3SvKg-- X-Yahoo-Newman-Property: ymail-3 From: "Turner, Sean P." To: References: <200805201421.QAA14861@TR-Sys.de> <2F75B5E58B954B87B7814C09AE730F1A@Wylie> Subject: RE: draft-ietf-smime-3851bis-02 (notes, part 2) Date: Wed, 18 Jun 2008 10:50:25 -0400 Organization: IECA, Inc. Message-ID: <7031C0AB1F15445581AA1278B0130944@Wylie> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <2F75B5E58B954B87B7814C09AE730F1A@Wylie> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 Thread-Index: Aci6hPPfZipj3DO/Rqei+xwSrAK2ugKasBDAAxdfIbA= Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: For (0), it seems like it might be easiest to add an appendix that says v3.2 is backwards compatible (with the exception of some algorithms) to 2311/2312 and ask that 2311/2312 be moved to Historic. I'll move the references to numbered sections and put the "move to historic" text in App B in 3851bis and App A in 3850bis. For (29), I'll modify Section 5 to register application/pkcs7-mime and application/pkcs7-signature with some boiler plate that says we're just updating the pointers in the IANA registry. I'll post a new version of both IDs before the end of the week. spt >-----Original Message----- >From: owner-ietf-smime@mail.imc.org >[mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Turner, Sean P. >Sent: Tuesday, June 03, 2008 3:42 PM >To: ietf-smime@imc.org >Subject: RE: draft-ietf-smime-3851bis-02 (notes, part 2) > > >Alfred, > >Thanks again for the review. Responses inline. In the version >I'm about to post I haven't addressed comment (0) or (29). > >All, > >Curious what others feel about (0) and (29). > >spt > >>-----Original Message----- >>(0) Front Matter / Standards Actions >> >>The draft already indicates in its front matter: >> Obsoletes: 3851 >> >>During supporting investigations, it became clear that, due >to specific >>circumstances, this will let us end up with two "valid" >>sets of S/MIME specifications -- those for S/MIME v3.2 and those for >>S/MIME v2 ! >> >>The historic reason for this scenario seems to be buried in >the S/MIME >>v2 specifications being published as Informational RFCs and not >>expressly being Obsoleted by the S/MIME v3 RFCs. >> >>In Section 1.3, this draft lists RFCs 2311 through 2315 as the >>documents originally specifying S/MIME v2. In the RFC index, the >>entries for all these RFCs list INFORMATIONAL status, >> - RFC 2313 is tagged (Obsoleted by RFC2437), >> - RFC 2314 is tagged (Obsoleted by RFC2986), but >> - RFCs 2311, 2312, and 2315 look like being current. >> >>Arguably, it would be a matter of CMS to take action for RFC >2315, but >>at least RFC 2311 and RFC 2312 are clearly within scope of the S/MIME >>v3.2 drafts. >> >>I suggest to take the opportunity to clean up the RFC metadata and >>either: >> >> - also formally Obsolete the S/MIME v2 RFCs with the publication >> of the corresponding intended S/MIME v3.2 RFCs, >> (i.e. add RFC 2311 to the Obsoletes list of this draft, >> add RFC 2312 to the Obsoletes list of [CERT32], and >> defer action for RFC 2315 to CMS), or >> >> - to explicitely declare the S/MIME v2 RFCs as Historic in >one place. > >We should address this one coment (0) and (25) togther seperately. > > >>(29) Section 5 >> >>Independent on the decision to be made regarding (0) above, >>this section needs to be amended. >> >>(29a) Scenario 1: RFC 2311 *not* Obsoleted / made HISTORIC >> >>In this case, IANA should at least be directed to update the >>media type registrations for >> >> "application/pkcs7-mime" >>and >> "application/pkcs7-signature" >> >>by adding an additional reference to [RFCTHIS], in order to >>point the reader to the most current update of the media type >>information. >> >>On the other hand, updating an old media type's information >>arguably could require updating the registration entirely, >>using the new registration template from BCP 13, RFC 4288. >> >>I leave it to the high priests of exegesis (or lawyers) to >>figure out whether RFC 4288 in fact even normatively requests >to do so. >> >>(29b) Scenario 2: RFC 2311 beinf Obsoleted or made HISTORIC >> >>In this case, the draft should substantially be amended with >>the two new media type registration templates, filled for both >>media types, "application/pkcs7-mime" and >>"application/pkcs7-signature", and IANA should be directed to >>update the registrations to incorporate this new information. > >Address this with (0). > From owner-ietf-smime@mail.imc.org Wed Jun 18 09:59:56 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 EAB573A6AE9 for ; Wed, 18 Jun 2008 09:59:56 -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 9oSrT9xO9m9W for ; Wed, 18 Jun 2008 09:59:56 -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 820543A6ADE for ; Wed, 18 Jun 2008 09:59:55 -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 m5IGkeKi084189 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Jun 2008 09:46: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 m5IGkeLR084187; Wed, 18 Jun 2008 09:46: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 [10.20.30.162] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5IGkWVb084156 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Jun 2008 09:46:36 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <7031C0AB1F15445581AA1278B0130944@Wylie> References: <200805201421.QAA14861@TR-Sys.de> <2F75B5E58B954B87B7814C09AE730F1A@Wylie> <7031C0AB1F15445581AA1278B0130944@Wylie> Date: Wed, 18 Jun 2008 09:46:24 -0700 To: "Turner, Sean P." , From: Paul Hoffman Subject: RE: draft-ietf-smime-3851bis-02 (notes, part 2) Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 10:50 AM -0400 6/18/08, Turner, Sean P. wrote: >For (0), it seems like it might be easiest to add an appendix that says v3.2 >is backwards compatible (with the exception of some algorithms) to 2311/2312 >and ask that 2311/2312 be moved to Historic. I'll move the references to >numbered sections and put the "move to historic" text in App B in 3851bis >and App A in 3850bis. That works for me. But I would want to hear from others in the S/MIME greybeard crowd about moving v2 to historic. Are there implementations of v2 that are that way for a good reason? From owner-ietf-smime@mail.imc.org Fri Jun 20 07:25:26 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 D524B3A68AD for ; Fri, 20 Jun 2008 07:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 CWJnN-Sk5IaG for ; Fri, 20 Jun 2008 07:25:26 -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 909DD3A67B3 for ; Fri, 20 Jun 2008 07:25:25 -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 m5KEAc7B049387 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Jun 2008 07:10:38 -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 m5KEActF049386; Fri, 20 Jun 2008 07:10:38 -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 m5KEAZ4n049363 for ; Fri, 20 Jun 2008 07:10:35 -0700 (MST) (envelope-from wwwrun@core3.amsl.com) Received: by core3.amsl.com (Postfix, from userid 30) id A679B3A6A84; Fri, 20 Jun 2008 07:10:32 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Subject: Last Call: draft-ietf-smime-cms-rsa-kem (Use of the RSA-KEM Key Transport Algorithm in CMS) to Proposed Standard Reply-to: ietf@ietf.org CC: Message-Id: <20080620141032.A679B3A6A84@core3.amsl.com> Date: Fri, 20 Jun 2008 07:10:32 -0700 (PDT) Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG has received a request from the S/MIME Mail Security WG (smime) to consider the following document: - 'Use of the RSA-KEM Key Transport Algorithm in CMS ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2008-07-04. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-smime-cms-rsa-kem-05.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=10322&rfc_flag=0 From c.hirsch@inter-tube.de Fri Jun 20 21:09: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 97D613A68B8; Fri, 20 Jun 2008 21:09:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -88.703 X-Spam-Level: X-Spam-Status: No, score=-88.703 tagged_above=-999 required=5 tests=[BAYES_60=1, FS_REPLICA=0.994, HELO_DYNAMIC_HCC=4.295, HELO_EQ_DSL=1.129, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, 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 7zWmK1W7U7Zl; Fri, 20 Jun 2008 21:09:00 -0700 (PDT) Received: from 139-59-112.adsl.terra.cl (139-59-112.adsl.terra.cl [200.112.59.139]) by core3.amsl.com (Postfix) with SMTP id 94BFB3A683C; Fri, 20 Jun 2008 21:08:51 -0700 (PDT) X-Originating-IP: 168.102.224.28 by smtp.200.112.59.139; Sat, 21 Jun 2008 00:08:55 -0500 Message-ID: From: "Brittany Sheldon" Reply-To: "Brittany Sheldon" To: sipping-bounces@ietf.org Subject: Tag Heuer replicas better than originals Date: Sat, 21 Jun 2008 00:08:55 -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! Diamond 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://mewukesobox82.blogspot.com/ As you are probably aware of, Diamond 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 Diamond Replicas today! http://mewukesobox82.blogspot.com/ From c_jedra@nadarzyn.net.pl Sat Jun 21 16:56:45 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 6BA043A695B; Sat, 21 Jun 2008 16:56:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -62.894 X-Spam-Level: X-Spam-Status: No, score=-62.894 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, FS_REPLICAWATCH=10.357, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DSL=1.129, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, TVD_RCVD_IP=1.931, 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 kjTHYn4a5UW4; Sat, 21 Jun 2008 16:56:44 -0700 (PDT) Received: from 201-236-157-90.adsl.tie.cl (201-236-157-90.adsl.tie.cl [201.236.157.90]) by core3.amsl.com (Postfix) with SMTP id 656333A6958; Sat, 21 Jun 2008 16:56:39 -0700 (PDT) X-Originating-IP: 106.192.240.250 by smtp.201.236.157.90; Sat, 21 Jun 2008 19:56:41 -0500 Message-ID: From: "Sadie Shelton" Reply-To: "Sadie Shelton" To: smime-archive@megatron.ietf.org Subject: Replica watches make great gifts Date: Sat, 21 Jun 2008 19:56:41 -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! Diamond 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://xuvodymexal70.blogspot.com/ As you are probably aware of, Diamond 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 Diamond Replicas today! http://xuvodymexal70.blogspot.com/ From c.knop@abi-1992.com Sat Jun 21 23:03:14 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 60DC43A67F9; Sat, 21 Jun 2008 23:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -68.162 X-Spam-Level: X-Spam-Status: No, score=-68.162 tagged_above=-999 required=5 tests=[BAYES_80=2, 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, FS_REPLICAWATCH=10.357, HELO_DYNAMIC_IPADDR2=4.395, 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, TVD_RCVD_IP=1.931, 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 CEX8nMQMG33w; Sat, 21 Jun 2008 23:03:13 -0700 (PDT) Received: from 201-212-49-149.cab.prima.net.ar (201-212-49-149.cab.prima.net.ar [201.212.49.149]) by core3.amsl.com (Postfix) with SMTP id C23843A693D; Sat, 21 Jun 2008 23:03:03 -0700 (PDT) X-Originating-IP: 104.142.193.128 by smtp.201.212.49.149; Sun, 22 Jun 2008 02:03:09 -0500 Message-ID: From: "Isaac Mcdonald" Reply-To: "Isaac Mcdonald" To: sipping-bounces@ietf.org Subject: Take a look at the latest replica watches Date: Sun, 22 Jun 2008 02:03:09 -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! Diamond 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://bohupykemod31.blogspot.com/ As you are probably aware of, Diamond 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 Diamond Replicas today! http://bohupykemod31.blogspot.com/ From ca1aaa1azzzz1zaaaaa@yamaza.com Mon Jun 23 06:55: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 739E33A69BF; Mon, 23 Jun 2008 06:55:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -68.447 X-Spam-Level: X-Spam-Status: No, score=-68.447 tagged_above=-999 required=5 tests=[BAYES_95=3, 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, FS_REPLICAWATCH=10.357, 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 1UEkiiwQjKKU; Mon, 23 Jun 2008 06:55:26 -0700 (PDT) Received: from pc-145-189-104-200.cm.vtr.net (pc-145-189-104-200.cm.vtr.net [200.104.189.145]) by core3.amsl.com (Postfix) with SMTP id 77AAC3A67A6; Mon, 23 Jun 2008 06:55:19 -0700 (PDT) X-Originating-IP: 0.52.123.242 by smtp.200.104.189.145; Mon, 23 Jun 2008 09:55:20 -0500 Message-ID: From: "Timothy Bradford" Reply-To: "Timothy Bradford" To: sipping-bounces@ietf.org Subject: Affordable replica watches Date: Mon, 23 Jun 2008 09:55:20 -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 Diamond Replicas, the web's most comprehensive collection of brand name replica watches. In Diamond Replicas, any Tag Heuer is available for just over $200. http://rucitibilak34.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 Diamond 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 Diamond Replicas. http://rucitibilak34.blogspot.com/ From cabrahams@kenenthcole.com Mon Jun 23 07:26: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 88F273A6943; Mon, 23 Jun 2008 07:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -56.001 X-Spam-Level: X-Spam-Status: No, score=-56.001 tagged_above=-999 required=5 tests=[BAYES_60=1, FB_QUALITY_REPLICA=10.357, 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, GB_ROLEX=5, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DYNAMIC=1.144, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, 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=1.666, SARE_SPEC_ROLEX_HIQLT=1.666, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_NOV5F=0.666, SARE_SPEC_ROLEX_REP=1.666, TVD_RCVD_IP=1.931, 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 Hi3Kj0dZw66c; Mon, 23 Jun 2008 07:26:42 -0700 (PDT) Received: from 79-126-20-229.dynamic.mts-nn.ru (79-126-20-229.dynamic.mts-nn.ru [79.126.20.229]) by core3.amsl.com (Postfix) with SMTP id A6C093A69D8; Mon, 23 Jun 2008 07:26:28 -0700 (PDT) X-Originating-IP: 40.48.226.16 by smtp.79.126.20.229; Mon, 23 Jun 2008 10:26:29 -0500 Message-ID: From: "Merrill Cartwright" Reply-To: "Merrill Cartwright" To: sipping-bounces@ietf.org Subject: Get your watch now Date: Mon, 23 Jun 2008 10:26:29 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Have you always wanted a Rolex, but don't want to pay high prices for a brand name watch? Then you need to visit Diamond Replicas, a website dedicated exclusively to high quality replicas, with the most extensive inventory on the web and a proven track record of satisfied customers. http://diganorodus33.blogspot.com/ Diamond Replicas offers hundreds of Rolex replica watches starting just above $100, and during this spring season, their already low prices have been slashed by 15 percent if you buy two or more watches! No matter which model Rolex you choose, their 15% discount applies to them all! But don't let this limited time offer go by... spring is ending and it's time to impress your friends with a realistic, high quality Rolex replica watch, that will look and perform just like the real deal! http://diganorodus33.blogspot.com/ From owner-ietf-smime@mail.imc.org Mon Jun 23 14:05: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 872583A6807 for ; Mon, 23 Jun 2008 14:05:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 eqjfeEB-dQI9 for ; Mon, 23 Jun 2008 14:05:04 -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 2AFD83A67B2 for ; Mon, 23 Jun 2008 14:05:03 -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 m5NKj4MY017246 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Jun 2008 13:45: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 m5NKj4BS017245; Mon, 23 Jun 2008 13:45: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 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 m5NKj3iN017239 for ; Mon, 23 Jun 2008 13:45:04 -0700 (MST) (envelope-from root@core3.amsl.com) Received: by core3.amsl.com (Postfix, from userid 0) id 16F3C3A6A15; Mon, 23 Jun 2008 13:45: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-bfibecms-09.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080623204502.16F3C3A6A15@core3.amsl.com> Date: Mon, 23 Jun 2008 13:45:02 -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 : Using the Boneh-Franklin and Boneh-Boyen identity-based Encryption Algorithms with the Cryptographic Message Syntax (CMS) Author(s) : L. Martin, M. Schertler Filename : draft-ietf-smime-bfibecms-09.txt Pages : 16 Date : 2008-6-23 This document describes the conventions for using the Boneh- Franklin (BF) and Boneh-Boyen (BB1) identity-based encryption algorithms in the Cryptographic Message Syntax (CMS) to encrypt content-encryption keys. Object identifiers and the convention for encoding a recipient's identity are also defined. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-bfibecms-09.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-bfibecms-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-6-23134051.I-D@ietf.org> --NextPart-- From cabinet@vl.politiaromana.ro Mon Jun 23 19:18:02 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 151283A676A; Mon, 23 Jun 2008 19:18:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -42.373 X-Spam-Level: X-Spam-Status: No, score=-42.373 tagged_above=-999 required=5 tests=[BAYES_60=1, FB_QUALITY_REPLICA=10.357, 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, FS_REPLICAWATCH=10.357, GB_ROLEX=5, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DSL=1.129, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX=1.666, SARE_SPEC_ROLEX_HIQLT=1.666, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_NOV5F=0.666, SARE_SPEC_ROLEX_REP=1.666, TVD_RCVD_IP=1.931, 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 XwdLtFKiFVz5; Mon, 23 Jun 2008 19:18:01 -0700 (PDT) Received: from 190-82-183-173.adsl.tie.cl (190-82-183-173.adsl.tie.cl [190.82.183.173]) by core3.amsl.com (Postfix) with SMTP id AA6A63A683E; Mon, 23 Jun 2008 19:17:51 -0700 (PDT) X-Originating-IP: 236.100.10.160 by smtp.190.82.183.173; Mon, 23 Jun 2008 22:17:53 -0500 Message-ID: From: "Delmer Mendez" Reply-To: "Delmer Mendez" To: sipping-bounces@ietf.org Subject: Replica watches make great gifts Date: Mon, 23 Jun 2008 22:17:53 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Have you always wanted a Rolex, but don't want to pay high prices for a brand name watch? Then you need to visit Diamond Replicas, a website dedicated exclusively to high quality replicas, with the most extensive inventory on the web and a proven track record of satisfied customers. http://zofebomosyv33.blogspot.com/ Diamond Replicas offers hundreds of Rolex replica watches starting just above $100, and during this spring season, their already low prices have been slashed by 15 percent if you buy two or more watches! No matter which model Rolex you choose, their 15% discount applies to them all! But don't let this limited time offer go by... spring is ending and it's time to impress your friends with a realistic, high quality Rolex replica watch, that will look and perform just like the real deal! http://zofebomosyv33.blogspot.com/ From cabidela@www.leggypauline.com Mon Jun 23 19:28: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 382023A6859; Mon, 23 Jun 2008 19:28:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -81.675 X-Spam-Level: X-Spam-Status: No, score=-81.675 tagged_above=-999 required=5 tests=[BAYES_80=2, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RCVD_IN_BL_SPAMCOP_NET=1.96, 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 yL7uwJ8r9pYb; Mon, 23 Jun 2008 19:28:39 -0700 (PDT) Received: from pc-55-116-44-190.cm.vtr.net (pc-55-116-44-190.cm.vtr.net [190.44.116.55]) by core3.amsl.com (Postfix) with SMTP id 3BB813A6929; Mon, 23 Jun 2008 19:28:15 -0700 (PDT) X-Originating-IP: 168.229.44.212 by smtp.190.44.116.55; Mon, 23 Jun 2008 22:28:17 -0500 Message-ID: From: "Joy Osborn" Reply-To: "Joy Osborn" To: sipping-bounces@ietf.org Subject: Impressive Glashutte timepieces Date: Mon, 23 Jun 2008 22:28:17 -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 Diamond Replicas, the web's most comprehensive collection of brand name replica watches. In Diamond Replicas, any Tag Heuer is available for just over $200. http://muwazywygad66.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 Diamond 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 Diamond Replicas. http://muwazywygad66.blogspot.com/ From owner-ietf-smime@mail.imc.org Tue Jun 24 01:30:45 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 67A653A68DF for ; Tue, 24 Jun 2008 01:30:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.476 X-Spam-Level: X-Spam-Status: No, score=-100.476 tagged_above=-999 required=5 tests=[AWL=-2.123, BAYES_00=-2.599, FH_HAS_XAIMC=2.696, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1, 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 OORga1m2f89R for ; Tue, 24 Jun 2008 01:30:42 -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 EF5D13A684C for ; Tue, 24 Jun 2008 01:30:41 -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 m5O8CZTg059605 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Jun 2008 01:12:36 -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 m5O8CZOB059604; Tue, 24 Jun 2008 01:12: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 people.com.cn ([202.99.23.227]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m5O8CXJM059595 for ; Tue, 24 Jun 2008 01:12:34 -0700 (MST) (envelope-from iesg-secretary@ietf.org) Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm44860fe9d; Tue, 24 Jun 2008 16:27:32 +0800 Received: from mail.ietf.org([64.170.98.32]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jma2485be6b3; Fri, 20 Jun 2008 22:26:49 +0800 Received: from mail.ietf.org([64.170.98.32]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Fri, 20 Jun 2008 22:26:49 +0800 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 510E728C134; Fri, 20 Jun 2008 07:10:34 -0700 (PDT) X-Original-To: ietf-announce@ietf.org Delivered-To: ietf-announce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id A679B3A6A84; Fri, 20 Jun 2008 07:10:32 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Subject: Last Call: draft-ietf-smime-cms-rsa-kem (Use of the RSA-KEM Key Transport Algorithm in CMS) to Proposed Standard Message-Id: <20080620141032.A679B3A6A84@core3.amsl.com> Date: Fri, 20 Jun 2008 07:10:32 -0700 (PDT) Cc: ietf-smime@imc.org X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.9 Reply-To: ietf@ietf.org List-Id: IETF Announcements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-AIMC-AUTH: (null) X-AIMC-MAILFROM: ietf-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: iesg-secretary@ietf.org X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG has received a request from the S/MIME Mail Security WG (smime) to consider the following document: - 'Use of the RSA-KEM Key Transport Algorithm in CMS ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2008-07-04. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-smime-cms-rsa-kem-05.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=10322&rfc_flag=0 _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce From cabeseg@celebhotel.com Tue Jun 24 02:18:35 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 AF65B3A68F7; Tue, 24 Jun 2008 02:18:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -72.469 X-Spam-Level: X-Spam-Status: No, score=-72.469 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FS_REPLICA=0.994, FS_REPLICAWATCH=10.357, HELO_DYNAMIC_HCC=4.295, HELO_EQ_DSL=1.129, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, 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 dSKQLMA1947v; Tue, 24 Jun 2008 02:18:32 -0700 (PDT) Received: from bl10-189-218.dsl.telepac.pt (bl10-189-218.dsl.telepac.pt [85.243.189.218]) by core3.amsl.com (Postfix) with SMTP id 07CA63A67EB; Tue, 24 Jun 2008 02:18:15 -0700 (PDT) X-Originating-IP: 245.96.198.176 by smtp.85.243.189.218; Tue, 24 Jun 2008 05:18:09 -0500 Message-ID: From: "Hung Shepherd" Reply-To: "Hung Shepherd" To: smime-archive@megatron.ietf.org Subject: Looking for a replica watch? Date: Tue, 24 Jun 2008 05:18:09 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Did you watch the last 007 flick, Casino Royale? If you did, you probably noticed that all throughout the movie, James Bond wears an spectacularly beautiful Omega watch... and he even brags about it! How would you like to be wearing that same exact model watch? The good news is that YOU can! Because now, you don't have to spend thousands of dollars to sport an Omega watch! When you visit Diamond Replicas, you will be able to browse through dozens of Omega replica watches, and pick the one of your dreams for just a couple of hundred dollars. Our watches are of such undeniably high quality, and offer such superior performance, that you'll fall in love with them, and what's best: stay in love with them for years to come! Come inside Diamond Replicas and pick your new Omega today! http://golacyteven31.blogspot.com/ From ahmed_tafa@rediffmail.com Tue Jun 24 06:17: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 028553A6861 for ; Tue, 24 Jun 2008 06:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.402 X-Spam-Level: *** X-Spam-Status: No, score=3.402 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MSGID_FROM_MTA_HEADER=0.803, SARE_SXLIFE=1.07] 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 MRxnCOTAL-JZ for ; Tue, 24 Jun 2008 06:17:47 -0700 (PDT) Received: from rediffmail.com (f5mail-237-202.rediffmail.com [202.137.237.202]) by core3.amsl.com (Postfix) with SMTP id 439293A6813 for ; Tue, 24 Jun 2008 06:17:45 -0700 (PDT) Received: (qmail 1430 invoked by uid 510); 24 Jun 2008 12:12:42 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=redf; d=rediffmail.com; b=huAcb1G9ps5hUFzCZIFxlxeIu3lpjOR0A7Rt5DEO0gnL15VwL0ZDmcN3YLWSDNuCi1oJkG0do+eD3vxEGMITIYzVu0MLu3tOvfm/b1S7xnJRgRebS4qMkt0PH8kzfOdesvfrFGcqawSpdIvlngXGC71PiGH0rEVIEk5VF8afJYc= ; XX-CMAE-analysis: v=1.0 c=1 a=reRN_k78R_QA:10 a=Pd8tDzOlj8GQ4qcDVpadjw==:17 a=GdOpVVzcBBCk2PG-IsIA:9 a=MFGGKZIGiTuDzlrYXoiDzp3FAw4A:4 a=z40VNzwK3KoA:10 a=fnWZxA5CVigA:10 a=8y7tGHue6YMA:10 a=6SwCy3u5AAAA:8 a=waj3YdZyoA-yb44SwwwA:7 a=MRcuu4QPSFIA:10 Date: 24 Jun 2008 12:12:42 -0000 Message-ID: <20080624121242.1427.qmail@f5mail-237-202.rediffmail.com> Received: from unknown (81.199.51.31) by rediffmail.com via HTTP; 24 jun 2008 12:12:42 -0000 MIME-Version: 1.0 From: "tafa ahmed" Reply-To: "tafa ahmed" To: ahmed_tafa@rediffmail.com Subject: A call for investment Content-type: multipart/alternative; boundary="Next_1214309562---0-202.137.237.202-1406" This is a multipart mime message --Next_1214309562---0-202.137.237.202-1406 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline =0A =0A =0A Sir,=0A=0AI represent a top company executive in Russia= ,=0A=0Ahis business interests includes crude oil exploration, mining, const= ruction etc. I have a very sensitive and private brief from this top execut= ive to ask for your partnership to re-profile funds over 37,000,000.00 euro= s.=0A=0AI will give the details, but in summary, the fund is coming via cle= ar stream.=0A=0AThis is a legitimate transaction. You will be paid 7% of th= is fund for your "management fees", if I am able to reach terms with you. I= f you are interested, please write back by email;ahmed_tafa@rediffmail.com = and provide me with your confidential telephone number, and email address a= nd I will provide further details. Please keep this confidential; we can no= t afford any political problems with Moscow and its allies.=0A=0ARegards,= =0A=0AYours truly,=0AMrs. Tafa Ahmed.=0A=0A=0A=0A=0A=0A --Next_1214309562---0-202.137.237.202-1406 Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

=0A 
=0A 
=0A 
=0A    Sir,
=0A<= BR>=0AI represent a top company executive in Russia,
=0A
=0Ahis busin= ess interests includes crude oil exploration, mining, construction etc. I h= ave a very sensitive and private brief from this top executive to ask for y= our partnership to re-profile funds over 37,000,000.00 euros.
=0A
=0A= I will give the details, but in summary, the fund is coming via clear strea= m.
=0A
=0AThis is a legitimate transaction. You will be paid 7% of th= is fund for your "management fees", if I am able to reach terms w= ith you. If you are interested, please write back by email;ahmed_tafa@redif= fmail.com and provide me with your confidential telephone number, and email= address and I will provide further details. Please keep this confidential;= we can not afford any political problems with Moscow and its allies.
= =0A
=0ARegards,
=0A
=0AYours truly,
=0AMrs. Tafa Ahmed.
=0A<= BR>=0A
=0A
=0A
=0A
=0A=0A

=0A

=0A
3D'HSBC'
--Next_1214309562---0-202.137.237.202-1406-- From ahmed_tafa@rediffmail.com Tue Jun 24 07:16: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 AC08B3A6866 for ; Tue, 24 Jun 2008 07:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.402 X-Spam-Level: *** X-Spam-Status: No, score=3.402 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MSGID_FROM_MTA_HEADER=0.803, SARE_SXLIFE=1.07] 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 tmY3eyCswIA7 for ; Tue, 24 Jun 2008 07:16:07 -0700 (PDT) Received: from rediffmail.com (f5mail-237-204.rediffmail.com [202.137.237.204]) by core3.amsl.com (Postfix) with SMTP id ED89A3A684C for ; Tue, 24 Jun 2008 07:16:05 -0700 (PDT) Received: (qmail 19456 invoked by uid 510); 24 Jun 2008 12:24:02 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=redf; d=rediffmail.com; b=HrlKQaS3E7LOLUNGo1xexrwDrzF+qSKPp1bOANnJObyGTlIOwlIofrLIaWDWkQD8FPFIGz3XF00SQ/46t1Fjv/EvNaJgPXqhe2BcWezy5aPCAcQ7oh2S/DGlO+gIXyhK/lYg/9yhZgaK2soPGo/7SLXlUQ/H0C1hEL/F2zLWaMM= ; XX-CMAE-analysis: v=1.0 c=1 a=reRN_k78R_QA:10 a=Pd8tDzOlj8GQ4qcDVpadjw==:17 a=GdOpVVzcBBCk2PG-IsIA:9 a=MFGGKZIGiTuDzlrYXoiDzp3FAw4A:4 a=z40VNzwK3KoA:10 a=fnWZxA5CVigA:10 a=8y7tGHue6YMA:10 a=6SwCy3u5AAAA:8 a=waj3YdZyoA-yb44SwwwA:7 a=MRcuu4QPSFIA:10 Date: 24 Jun 2008 12:24:02 -0000 Message-ID: <20080624122402.19453.qmail@f5mail-237-204.rediffmail.com> Received: from unknown (81.199.51.31) by rediffmail.com via HTTP; 24 jun 2008 12:24:02 -0000 MIME-Version: 1.0 From: "tafa ahmed" Reply-To: "tafa ahmed" To: ahmed_tafa@rediffmail.com Subject: A call for investment Content-type: multipart/alternative; boundary="Next_1214310242---0-202.137.237.204-19437" This is a multipart mime message --Next_1214310242---0-202.137.237.204-19437 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline =0A =0A =0A Sir,=0A=0AI represent a top company executive in Russia= ,=0A=0Ahis business interests includes crude oil exploration, mining, const= ruction etc. I have a very sensitive and private brief from this top execut= ive to ask for your partnership to re-profile funds over 37,000,000.00 euro= s.=0A=0AI will give the details, but in summary, the fund is coming via cle= ar stream.=0A=0AThis is a legitimate transaction. You will be paid 7% of th= is fund for your "management fees", if I am able to reach terms with you. I= f you are interested, please write back by email;ahmed_tafa@rediffmail.com = and provide me with your confidential telephone number, and email address a= nd I will provide further details. Please keep this confidential; we can no= t afford any political problems with Moscow and its allies.=0A=0ARegards,= =0A=0AYours truly,=0AMrs. Tafa Ahmed.=0A=0A=0A=0A=0A=0A --Next_1214310242---0-202.137.237.204-19437 Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

=0A 
=0A 
=0A 
=0A    Sir,
=0A<= BR>=0AI represent a top company executive in Russia,
=0A
=0Ahis busin= ess interests includes crude oil exploration, mining, construction etc. I h= ave a very sensitive and private brief from this top executive to ask for y= our partnership to re-profile funds over 37,000,000.00 euros.
=0A
=0A= I will give the details, but in summary, the fund is coming via clear strea= m.
=0A
=0AThis is a legitimate transaction. You will be paid 7% of th= is fund for your "management fees", if I am able to reach terms w= ith you. If you are interested, please write back by email;ahmed_tafa@redif= fmail.com and provide me with your confidential telephone number, and email= address and I will provide further details. Please keep this confidential;= we can not afford any political problems with Moscow and its allies.
= =0A
=0ARegards,
=0A
=0AYours truly,
=0AMrs. Tafa Ahmed.
=0A<= BR>=0A
=0A
=0A
=0A
=0A=0A

=0A

=0A
3D'HSBC'
--Next_1214310242---0-202.137.237.204-19437-- From c_schroeder@schroeder-buende.de Tue Jun 24 21:28:47 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 4891B3A69CF; Tue, 24 Jun 2008 21:28:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -75.462 X-Spam-Level: X-Spam-Status: No, score=-75.462 tagged_above=-999 required=5 tests=[BAYES_80=2, 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, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DSL=1.129, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_NOV5F=0.666, TVD_RCVD_IP=1.931, 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 xXxqgtYwBgi1; Tue, 24 Jun 2008 21:28:46 -0700 (PDT) Received: from 65-128-20-190.adsl.terra.cl (65-128-20-190.adsl.terra.cl [190.20.128.65]) by core3.amsl.com (Postfix) with SMTP id 113553A68D6; Tue, 24 Jun 2008 21:28:25 -0700 (PDT) X-Originating-IP: 4.138.82.232 by smtp.190.20.128.65; Wed, 25 Jun 2008 00:28:21 -0500 Message-ID: From: "Jolene Pham" Reply-To: "Jolene Pham" To: qy@megatron.ietf.org Subject: Get one of these awesome replicas Date: Wed, 25 Jun 2008 00:28:21 -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 Diamond Replicas, the web's most comprehensive collection of brand name replica watches. In Diamond Replicas, any Tag Heuer is available for just over $200. http://www.geocities.com/bassxexydos 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 Diamond 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 Diamond Replicas. http://www.geocities.com/bassxexydos No virus found in this outgoing message Checked by PC Tools AntiVirus (4.0.0.26 - 10.063.005). http://www.pctools.com/free-antivirus/ From c1@sacchaplains.com Wed Jun 25 00:01:48 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 51E3C3A682B; Wed, 25 Jun 2008 00:01:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -51.688 X-Spam-Level: X-Spam-Status: No, score=-51.688 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FB_QUALITY_REPLICA=10.357, FS_REPLICA=0.994, FS_REPLICAWATCH=10.357, GB_ROLEX=5, HELO_DYNAMIC_HCC=4.295, HELO_EQ_DSL=1.129, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_NJABL_PROXY=1.643, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX=1.666, SARE_SPEC_ROLEX_HIQLT=1.666, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_NOV5F=0.666, SARE_SPEC_ROLEX_REP=1.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 bVdPoLJPu6+D; Wed, 25 Jun 2008 00:01:47 -0700 (PDT) Received: from 246-49-89.adsl.terra.cl (246-49-89.adsl.terra.cl [200.89.49.246]) by core3.amsl.com (Postfix) with SMTP id F2DD73A69DA; Wed, 25 Jun 2008 00:00:58 -0700 (PDT) X-Originating-IP: 147.89.128.106 by smtp.200.89.49.246; Wed, 25 Jun 2008 03:01:01 -0500 Message-ID: From: "Hal Mcconnell" Reply-To: "Hal Mcconnell" To: sipping-bounces@ietf.org Subject: Hot replica watches from 2008 Date: Wed, 25 Jun 2008 03:01:01 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Have you always wanted a Rolex, but don't want to pay high prices for a brand name watch? Then you need to visit Diamond Replicas, a website dedicated exclusively to high quality replicas, with the most extensive inventory on the web and a proven track record of satisfied customers. http://www.geocities.com/honeycutttagicu Diamond Replicas offers hundreds of Rolex replica watches starting just above $100, and during this spring season, their already low prices have been slashed by 15 percent if you buy two or more watches! No matter which model Rolex you choose, their 15% discount applies to them all! But don't let this limited time offer go by... spring is ending and it's time to impress your friends with a realistic, high quality Rolex replica watch, that will look and perform just like the real deal! http://www.geocities.com/honeycutttagicu From owner-ietf-smime@mail.imc.org Wed Jun 25 03:14:32 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 DBDC33A69C2 for ; Wed, 25 Jun 2008 03:14:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.189 X-Spam-Level: X-Spam-Status: No, score=0.189 tagged_above=-999 required=5 tests=[AWL=-0.495, BAYES_20=-0.74, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_SORBS_WEB=0.619] 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 lPcfEU6NT-MX for ; Wed, 25 Jun 2008 03:14:31 -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 8AEAD3A67E3 for ; Wed, 25 Jun 2008 03:14:30 -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 m5P9gx2Q081473 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Jun 2008 02:42:59 -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 m5P9gxNB081472; Wed, 25 Jun 2008 02:42:59 -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 DS5852.ds5852.dedicated.turbodns.co.uk (server5852.dedicated.webfusion.co.uk [81.21.74.134]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5P9gqbG081423 for ; Wed, 25 Jun 2008 02:42:53 -0700 (MST) (envelope-from yasir.khan@ascertia.com) Message-Id: <200806250942.m5P9gqbG081423@balder-227.proper.com> Received: from ascertiajtl1 ([116.71.171.117]) by ds5852.dedicated.turbodns.co.uk with MailEnable ESMTP; Wed, 25 Jun 2008 09:44:42 +0100 From: "Yasir Khan" To: Subject: Using Signature Policy in RFC-5126 Date: Wed, 25 Jun 2008 15:43:14 +0500 Organization: Ascertia Limited MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Content-Type: multipart/signed; boundary="----=_NextPart_000_0081_01C8D6DA.2E4138A0"; micalg=SHA1; protocol="application/x-pkcs7-signature" Thread-Index: AcjWsEVkUJ9OGEWeQRKpgqvSmd/z7A== 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_0081_01C8D6DA.2E4138A0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0082_01C8D6DA.2E4138A0" ------=_NextPart_001_0082_01C8D6DA.2E4138A0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit 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 ----------------------------------------------------------------- ------=_NextPart_001_0082_01C8D6DA.2E4138A0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

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_0082_01C8D6DA.2E4138A0-- ------=_NextPart_000_0081_01C8D6DA.2E4138A0 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 MBwGCSqGSIb3DQEJBTEPFw0wODA2MjUxMDQzMTRaMCMGCSqGSIb3DQEJBDEWBBSaLpcp6BykZVWZ QyQCnSsjwr4jczBUBgkrBgEEAYI3EAQxRzBFMD8xCzAJBgNVBAYTAkdCMREwDwYDVQQKEwhBc2Nl cnRpYTEdMBsGA1UEAxMUQXNjZXJ0aWEgSW50ZXJuYWwgQ0ECAgCyMFYGCyqGSIb3DQEJEAILMUeg RTA/MQswCQYDVQQGEwJHQjERMA8GA1UEChMIQXNjZXJ0aWExHTAbBgNVBAMTFEFzY2VydGlhIElu dGVybmFsIENBAgIAsjBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG 9w0CBTANBgkqhkiG9w0BAQEFAASBgLTqPVX33jmXeaFoo1h1k4OsmlstRYm1UcNK+2qZJJ1vfvOm vfYhR2uza5R6qGpkjgHoA8Q0FnNyfbof6+PJVxX9ZvylOV5nn/jcpWP/vPBml7OUwzoAy+zNAATc kBSjzok7barRQ2sCQjQzZdg04XNSpFwlImR+nhopiR6Z7vP7AAAAAAAA ------=_NextPart_000_0081_01C8D6DA.2E4138A0-- From owner-ietf-smime@mail.imc.org Wed Jun 25 04:27:15 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 21AFB3A69A3 for ; Wed, 25 Jun 2008 04:27:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.128 X-Spam-Level: X-Spam-Status: No, score=-1.128 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, 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 G1ivbqg59kO3 for ; Wed, 25 Jun 2008 04:27:13 -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 315373A67B1 for ; Wed, 25 Jun 2008 04:27: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 m5PB3KIj000470 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Jun 2008 04:03:21 -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 m5PB3Kd4000468; Wed, 25 Jun 2008 04:03: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 mx4.cryptopro.ru (mx4.cryptopro.ru [89.221.56.34]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5PB3HLP000447 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 25 Jun 2008 04:03:19 -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; Wed, 25 Jun 2008 15:06:58 +0400 Received: from smirnovxp64 ([192.168.68.187] RDNS failed) by mx4.cryptopro.ru with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Jun 2008 15:06:58 +0400 From: "Pavel V. Smirnov" To: "'Yasir Khan'" , References: <200806250942.m5P9gqbG081423@balder-227.proper.com> In-Reply-To: <200806250942.m5P9gqbG081423@balder-227.proper.com> Subject: RE: Using Signature Policy in RFC-5126 Date: Wed, 25 Jun 2008 15:06:55 +0400 Message-ID: <000a01c8d6b3$95f8cde0$c1ea69a0$@ru> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000B_01C8D6D5.1D0A6DE0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcjWsEVkUJ9OGEWeQRKpgqvSmd/z7AAAX7Ag Content-Language: ru X-OriginalArrivalTime: 25 Jun 2008 11:06:58.0250 (UTC) FILETIME=[95E71AA0:01C8D6B3] Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ------=_NextPart_000_000B_01C8D6D5.1D0A6DE0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit 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 ----------------------------------------------------------------- ------=_NextPart_000_000B_01C8D6D5.1D0A6DE0 Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable

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_000B_01C8D6D5.1D0A6DE0-- From c.girard@bm-stjeandevedas.fr Wed Jun 25 04:58:56 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 6A3763A6A7D; Wed, 25 Jun 2008 04:58:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -83.246 X-Spam-Level: X-Spam-Status: No, score=-83.246 tagged_above=-999 required=5 tests=[BAYES_80=2, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, 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 CTYfGx7-DZR0; Wed, 25 Jun 2008 04:58:55 -0700 (PDT) Received: from dynamic-66-243-245-4.ellensburg.fairpoint.net (dynamic-66-243-245-4.ellensburg.fairpoint.net [66.243.245.4]) by core3.amsl.com (Postfix) with SMTP id 474853A6A77; Wed, 25 Jun 2008 04:58:52 -0700 (PDT) X-Originating-IP: 47.199.172.145 by smtp.66.243.245.4; Wed, 25 Jun 2008 07:58:46 -0500 Message-ID: From: "Oscar Morris" Reply-To: "Oscar Morris" To: smime-archive@megatron.ietf.org Subject: Impressive Glashutte timepieces Date: Wed, 25 Jun 2008 07:58:46 -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! Diamond 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.geocities.com/richardsfinola As you are probably aware of, Diamond 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 Diamond Replicas today! http://www.geocities.com/richardsfinola From cabrero@alfa21.com Wed Jun 25 14:40: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 BA8633A69FC; Wed, 25 Jun 2008 14:40:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -54.371 X-Spam-Level: X-Spam-Status: No, score=-54.371 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, FS_REPLICAWATCH=10.357, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BLUEYON=1.4, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, 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, TVD_RCVD_IP=1.931, 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 av5uOxszyf-v; Wed, 25 Jun 2008 14:40:45 -0700 (PDT) Received: from 77-102-20-105.cable.ubr06.donc.blueyonder.co.uk (77-102-20-105.cable.ubr06.donc.blueyonder.co.uk [77.102.20.105]) by core3.amsl.com (Postfix) with SMTP id A7E273A69B6; Wed, 25 Jun 2008 14:40:35 -0700 (PDT) X-Originating-IP: 224.76.158.104 by smtp.77.102.20.105; Wed, 25 Jun 2008 17:40:39 -0500 Message-ID: From: "Mattie Pham" Reply-To: "Mattie Pham" To: sipping-bounces@ietf.org Subject: Affordable replica watches Date: Wed, 25 Jun 2008 17:40:39 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Did you watch the last 007 flick, Casino Royale? If you did, you probably noticed that all throughout the movie, James Bond wears an spectacularly beautiful Omega watch... and he even brags about it! How would you like to be wearing that same exact model watch? The good news is that YOU can! Because now, you don't have to spend thousands of dollars to sport an Omega watch! When you visit Diamond Replicas, you will be able to browse through dozens of Omega replica watches, and pick the one of your dreams for just a couple of hundred dollars. Our watches are of such undeniably high quality, and offer such superior performance, that you'll fall in love with them, and what's best: stay in love with them for years to come! Come inside Diamond Replicas and pick your new Omega today! http://hiryvyxubex87.blogspot.com/ From cabarca@iconstruccion.cl Wed Jun 25 16:49:19 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 847B428C0E4; Wed, 25 Jun 2008 16:49:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -48.071 X-Spam-Level: X-Spam-Status: No, score=-48.071 tagged_above=-999 required=5 tests=[BAYES_80=2, FB_QUALITY_REPLICA=10.357, 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, FS_REPLICAWATCH=10.357, GB_ROLEX=5, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX=1.666, SARE_SPEC_ROLEX_HIQLT=1.666, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_NOV5F=0.666, SARE_SPEC_ROLEX_REP=1.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 edaA6U3jI7zS; Wed, 25 Jun 2008 16:49:12 -0700 (PDT) Received: from cable201-233-63-49.epm.net.co (cable201-233-63-49.epm.net.co [201.233.63.49]) by core3.amsl.com (Postfix) with SMTP id 79AAB3A68CF; Wed, 25 Jun 2008 16:48:53 -0700 (PDT) X-Originating-IP: 180.52.94.102 by smtp.201.233.63.49; Wed, 25 Jun 2008 19:48:46 -0500 Message-ID: From: "Alissa Yeager" Reply-To: "Alissa Yeager" To: smime-archive@megatron.ietf.org Subject: Replica watches make great gifts Date: Wed, 25 Jun 2008 19:48:46 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Have you always wanted a Rolex, but don't want to pay high prices for a brand name watch? Then you need to visit Diamond Replicas, a website dedicated exclusively to high quality replicas, with the most extensive inventory on the web and a proven track record of satisfied customers. http://walipifavyb30.blogspot.com/ Diamond Replicas offers hundreds of Rolex replica watches starting just above $100, and during this spring season, their already low prices have been slashed by 15 percent if you buy two or more watches! No matter which model Rolex you choose, their 15% discount applies to them all! But don't let this limited time offer go by... spring is ending and it's time to impress your friends with a realistic, high quality Rolex replica watch, that will look and perform just like the real deal! http://walipifavyb30.blogspot.com/ From owner-ietf-smime@mail.imc.org Thu Jun 26 00:51: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 0227A3A67AE for ; Thu, 26 Jun 2008 00:51:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.494 X-Spam-Level: X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[AWL=0.682, BAYES_00=-2.599, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_SORBS_WEB=0.619] 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 rC69xO5mrODz for ; Thu, 26 Jun 2008 00:51:05 -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 1D8003A6840 for ; Thu, 26 Jun 2008 00:51:03 -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 m5Q7J2Tp040553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Jun 2008 00:19:03 -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 m5Q7IvXQ040519; Thu, 26 Jun 2008 00:18: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 DS5852.ds5852.dedicated.turbodns.co.uk (server5852.dedicated.webfusion.co.uk [81.21.74.134]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5Q7Ilo1040460 for ; Thu, 26 Jun 2008 00:18:49 -0700 (MST) (envelope-from yasir.khan@ascertia.com) Message-Id: <200806260718.m5Q7Ilo1040460@balder-227.proper.com> Received: from ascertiajtl1 ([116.71.171.117]) by ds5852.dedicated.turbodns.co.uk with MailEnable ESMTP; Thu, 26 Jun 2008 07:20:37 +0100 From: "Yasir Khan" To: "'Pavel V. Smirnov'" , Subject: RE: Using Signature Policy in RFC-5126 Date: Thu, 26 Jun 2008 13:19:09 +0500 Organization: Ascertia Limited MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcjWsEVkUJ9OGEWeQRKpgqvSmd/z7AAAX7AgACx4USA= In-Reply-To: <000a01c8d6b3$95f8cde0$c1ea69a0$@ru> Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_029B_01C8D78F.37473D90" 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_029B_01C8D78F.37473D90 Content-Type: multipart/alternative; boundary="----=_NextPart_001_029C_01C8D78F.37473D90" ------=_NextPart_001_029C_01C8D78F.37473D90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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 ----------------------------------------------------------------- ------=_NextPart_001_029C_01C8D78F.37473D90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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_029C_01C8D78F.37473D90-- ------=_NextPart_000_029B_01C8D78F.37473D90 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 MBwGCSqGSIb3DQEJBTEPFw0wODA2MjYwODE5MDhaMCMGCSqGSIb3DQEJBDEWBBRcJLGQui1YKdTX u6sUzFk4v2Ph7DBUBgkrBgEEAYI3EAQxRzBFMD8xCzAJBgNVBAYTAkdCMREwDwYDVQQKEwhBc2Nl cnRpYTEdMBsGA1UEAxMUQXNjZXJ0aWEgSW50ZXJuYWwgQ0ECAgCyMFYGCyqGSIb3DQEJEAILMUeg RTA/MQswCQYDVQQGEwJHQjERMA8GA1UEChMIQXNjZXJ0aWExHTAbBgNVBAMTFEFzY2VydGlhIElu dGVybmFsIENBAgIAsjBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG 9w0CBTANBgkqhkiG9w0BAQEFAASBgGpAkevhB3Lw15bmlGe9X4kNGaaFMVbjkzOK/lt8/U+LmdnR 2xDgnwcHSVQ1hXPCKOSWN8Puoj/gdzK/S2yc1hLq3Xb22IYR17h1fVufWMXgk0oC14LMsTOfGuce ngoyKLZpwNIT22mCNUBjzAJjdQvrUJuEVG4pBsftZETXYxXIAAAAAAAA ------=_NextPart_000_029B_01C8D78F.37473D90-- From owner-ietf-smime@mail.imc.org Thu Jun 26 01:30: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 4865F3A67C0 for ; Thu, 26 Jun 2008 01:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.304 X-Spam-Level: * X-Spam-Status: No, score=1.304 tagged_above=-999 required=5 tests=[AWL=-2.432, BAYES_40=-0.185, 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 N-dTzNIRbui4 for ; Thu, 26 Jun 2008 01:30:03 -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 48AF13A67B6 for ; Thu, 26 Jun 2008 01:30:01 -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 m5Q80Cbp051328 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Jun 2008 01:00:12 -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 m5Q80Cq7051327; Thu, 26 Jun 2008 01:00:12 -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 m5Q809CW051320 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 26 Jun 2008 01:00:11 -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; Thu, 26 Jun 2008 12:03:53 +0400 Received: from smirnovxp64 ([192.168.68.187] RDNS failed) by mx4.cryptopro.ru with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Jun 2008 12:03:52 +0400 From: "Pavel V. Smirnov" To: "'Yasir Khan'" , References: <000a01c8d6b3$95f8cde0$c1ea69a0$@ru> <200806260718.m5Q7Ilo1040460@balder-227.proper.com> In-Reply-To: <200806260718.m5Q7Ilo1040460@balder-227.proper.com> Subject: RE: Using Signature Policy in RFC-5126 Date: Thu, 26 Jun 2008 12:03:50 +0400 Message-ID: <002c01c8d763$2c6d3db0$8547b910$@ru> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002D_01C8D784.B37EDDB0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcjWsEVkUJ9OGEWeQRKpgqvSmd/z7AAAX7AgACx4USAAAKjZYA== Content-Language: ru X-OriginalArrivalTime: 26 Jun 2008 08:03:52.0421 (UTC) FILETIME=[2C406150:01C8D763] Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ------=_NextPart_000_002D_01C8D784.B37EDDB0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable 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_002D_01C8D784.B37EDDB0 Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable

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_002D_01C8D784.B37EDDB0-- From owner-ietf-smime@mail.imc.org Thu Jun 26 02:16: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 09DFA3A68BB for ; Thu, 26 Jun 2008 02:16:54 -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 uc12NJmmUaax for ; Thu, 26 Jun 2008 02:16:53 -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 2ED423A67AE for ; Thu, 26 Jun 2008 02:16:51 -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 m5Q8Wn6A058286 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Jun 2008 01:32: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 m5Q8WnCs058285; Thu, 26 Jun 2008 01:32:49 -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 maiev.nerim.net (maiev.ipv6.nerim.net [IPv6:2001:7a8:1:1::89]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5Q8WmYx058268 for ; Thu, 26 Jun 2008 01:32:48 -0700 (MST) (envelope-from julien.stern@cryptolog.com) Received: from uranus.cry.pto (cryptolog2.pck.nerim.net [213.41.184.9]) by maiev.nerim.net (Postfix) with ESMTP id F2C14B8208; Thu, 26 Jun 2008 10:32:46 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id B17224429B; Thu, 26 Jun 2008 10:32:46 +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 3rIIqhcPfaZJ; Thu, 26 Jun 2008 10:32:42 +0200 (CEST) Received: from [10.0.1.15] (isonoe.cry.pto [10.0.1.15]) by uranus.cry.pto (Postfix) with ESMTP id 8454C4428C; Thu, 26 Jun 2008 10:32:42 +0200 (CEST) Message-ID: <4863542A.8080902@cryptolog.com> Date: Thu, 26 Jun 2008 10:32:42 +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: <200806260718.m5Q7Ilo1040460@balder-227.proper.com> In-Reply-To: <200806260718.m5Q7Ilo1040460@balder-227.proper.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Yasir, first, you may want to have a look at ETSI TR 102 272, which defines a binary format to represent the technical information needed in a signature policy. Second, it is not because the document is not referenced that it cannot be hashed. You can view the SPUri as a "hint" to retrieve the policy, that could also be obtained by other means. Regards, -- Julien Yasir Khan wrote: > 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 c.pack@bench-mark.co.uk Thu Jun 26 05:37:14 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 4FF253A686D; Thu, 26 Jun 2008 05:37:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -77.281 X-Spam-Level: X-Spam-Status: No, score=-77.281 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_HCC=4.295, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DIALUP=0.862, HELO_EQ_DSL=1.129, HOST_EQ_DIALUP=0.862, 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, 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 VV0hIHnEdd5C; Thu, 26 Jun 2008 05:37:10 -0700 (PDT) Received: from r190-134-20-128.dialup.adsl.anteldata.net.uy (r190-134-20-128.dialup.adsl.anteldata.net.uy [190.134.20.128]) by core3.amsl.com (Postfix) with SMTP id 988553A6802; Thu, 26 Jun 2008 05:36:19 -0700 (PDT) X-Originating-IP: 224.184.70.159 by smtp.190.134.20.128; Thu, 26 Jun 2008 08:36:24 -0500 Message-ID: From: "Abigail Ledbetter" Reply-To: "Abigail Ledbetter" To: sipping-bounces@ietf.org Subject: Replica or Original? Date: Thu, 26 Jun 2008 08:36:24 -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! Diamond 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://zydonowawil38.blogspot.com/ As you are probably aware of, Diamond 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 Diamond Replicas today! http://zydonowawil38.blogspot.com/ From c92wo@hackberry.org Thu Jun 26 07:51:04 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 909B73A6904; Thu, 26 Jun 2008 07:51:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -69.795 X-Spam-Level: X-Spam-Status: No, score=-69.795 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, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HELO_EQ_TELESP=1.245, HOST_EQ_BR=1.295, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, SARE_RECV_SPAM_DOMN02=1.666, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_NOV5F=0.666, TVD_RCVD_IP=1.931, 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 256VEelibZRs; Thu, 26 Jun 2008 07:50:59 -0700 (PDT) Received: from 189-18-189-212.dsl.telesp.net.br (189-18-189-212.dsl.telesp.net.br [189.18.189.212]) by core3.amsl.com (Postfix) with SMTP id ED99B3A67DF; Thu, 26 Jun 2008 07:50:46 -0700 (PDT) X-Originating-IP: 142.206.176.224 by smtp.189.18.189.212; Thu, 26 Jun 2008 10:50:39 -0500 Message-ID: From: "Georgia Irving" Reply-To: "Georgia Irving" To: smime-archive@megatron.ietf.org Subject: You can save 80% Date: Thu, 26 Jun 2008 10:50:39 -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 Diamond Replicas, the web's most comprehensive collection of brand name replica watches. In Diamond Replicas, any Tag Heuer is available for just over $200. http://bukimotedug86.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 Diamond 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 Diamond Replicas. http://bukimotedug86.blogspot.com/ From c.snitkin@schmiedag.de Thu Jun 26 08:13: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 BCF093A67D0; Thu, 26 Jun 2008 08:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -54.992 X-Spam-Level: X-Spam-Status: No, score=-54.992 tagged_above=-999 required=5 tests=[BAYES_95=3, FB_QUALITY_REPLICA=10.357, 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, GB_ROLEX=5, HELO_DYNAMIC_IPADDR2=4.395, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX=1.666, SARE_SPEC_ROLEX_HIQLT=1.666, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_NOV5F=0.666, SARE_SPEC_ROLEX_REP=1.666, TVD_RCVD_IP=1.931, 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 m+ZS1wqMEHM8; Thu, 26 Jun 2008 08:13:51 -0700 (PDT) Received: from 201-212-52-188.cab.prima.net.ar (201-212-52-188.cab.prima.net.ar [201.212.52.188]) by core3.amsl.com (Postfix) with SMTP id 331063A6816; Thu, 26 Jun 2008 08:13:45 -0700 (PDT) X-Originating-IP: 171.95.184.104 by smtp.201.212.52.188; Thu, 26 Jun 2008 11:13:38 -0500 Message-ID: From: "Marguerite Sizemore" Reply-To: "Marguerite Sizemore" To: smime-archive@megatron.ietf.org Subject: You and a Rolex watch Date: Thu, 26 Jun 2008 11:13:38 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit X-Antivirus: avast! (VPS 080626-1, 26/06/2008), Outbound message X-Antivirus-Status: Clean Have you always wanted a Rolex, but don't want to pay high prices for a brand name watch? Then you need to visit Diamond Replicas, a website dedicated exclusively to high quality replicas, with the most extensive inventory on the web and a proven track record of satisfied customers. http://morufegyzag38.blogspot.com/ Diamond Replicas offers hundreds of Rolex replica watches starting just above $100, and during this spring season, their already low prices have been slashed by 15 percent if you buy two or more watches! No matter which model Rolex you choose, their 15% discount applies to them all! But don't let this limited time offer go by... spring is ending and it's time to impress your friends with a realistic, high quality Rolex replica watch, that will look and perform just like the real deal! http://morufegyzag38.blogspot.com/ From office@blcnet.com Fri Jun 27 13:23:13 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 737B63A6B6E for ; Fri, 27 Jun 2008 13:23:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.936 X-Spam-Level: **** X-Spam-Status: No, score=4.936 tagged_above=-999 required=5 tests=[BAYES_60=1, FORGED_MUA_OUTLOOK=3.116, MSOE_MID_WRONG_CASE=0.82] 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 KSozPlccEKbS for ; Fri, 27 Jun 2008 13:23:13 -0700 (PDT) Received: from hoster906.com (hoster906.com [64.14.72.78]) by core3.amsl.com (Postfix) with ESMTP id 3AA943A6821 for ; Fri, 27 Jun 2008 13:23:10 -0700 (PDT) Received: (qmail 29963 invoked by uid 503); 27 Jun 2008 20:23:13 -0000 Received: from unknown (HELO User) (alex@193.93.172.37) by 64.14.72.143 with ESMTPA; 27 Jun 2008 20:23:13 -0000 From: "Bank of Lancaster County" Subject: Account Suspended Date: Fri, 27 Jun 2008 22:23:09 +0200 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: <20080627202313.3AA943A6821@core3.amsl.com> To: undisclosed-recipients:; Message from Bank of Lancaster County Customer Service Account Suspended Date: 06/27/2008 All Bank of Lancaster County accounts were recently update with a new security enhancement. For your security, we have temporary suspended your account. To activate your account please call urgent at : 308-210-9908. Please note + 1 308-210-9908. ©2008 Bank of Lancaster County. All rights reserved. From office@blcnet.com Fri Jun 27 13:29: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 1FA093A6842 for ; Fri, 27 Jun 2008 13:29:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.936 X-Spam-Level: **** X-Spam-Status: No, score=4.936 tagged_above=-999 required=5 tests=[BAYES_60=1, FORGED_MUA_OUTLOOK=3.116, MSOE_MID_WRONG_CASE=0.82] 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 caVu6rExCPOy for ; Fri, 27 Jun 2008 13:29:50 -0700 (PDT) Received: from hoster906.com (hoster906.com [64.14.72.78]) by core3.amsl.com (Postfix) with ESMTP id DAAA63A6821 for ; Fri, 27 Jun 2008 13:29:49 -0700 (PDT) Received: (qmail 29963 invoked by uid 503); 27 Jun 2008 20:23:13 -0000 Received: from unknown (HELO User) (alex@193.93.172.37) by 64.14.72.143 with ESMTPA; 27 Jun 2008 20:23:13 -0000 From: "Bank of Lancaster County" Subject: Account Suspended Date: Fri, 27 Jun 2008 22:23:09 +0200 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: <20080627202949.DAAA63A6821@core3.amsl.com> To: undisclosed-recipients:; Message from Bank of Lancaster County Customer Service Account Suspended Date: 06/27/2008 All Bank of Lancaster County accounts were recently update with a new security enhancement. For your security, we have temporary suspended your account. To activate your account please call urgent at : 308-210-9908. Please note + 1 308-210-9908. ©2008 Bank of Lancaster County. All rights reserved. From ArleneapportionHurt@craigslist.org Mon Jun 30 13:18:15 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 0A1EF3A6A73; Mon, 30 Jun 2008 13:18:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.386 X-Spam-Level: * X-Spam-Status: No, score=1.386 tagged_above=-999 required=5 tests=[BAYES_99=3.5, BODY_ENHANCEMENT=0.309, DOS_OE_TO_MX=2.75, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FORGED_MUA_OUTLOOK=3.116, HELO_EQ_IT=0.635, HOST_MISMATCH_NET=0.311, HS_OUTLOOK_MID_NOBRK=1, INVALID_MSGID=1.9, 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_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_ADLTSUB2=1.23, SARE_ADULT2=1.42, SARE_ENLRGYOUR=1.02, SARE_SUB_PENIS=1.666, STOX_REPLY_TYPE=0.001, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_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 rG8z5awSO232; Mon, 30 Jun 2008 13:18:14 -0700 (PDT) Received: from home6ecbb4f764.fastwebnet.it (213-140-18-131.fastres.net [213.140.18.131]) by core3.amsl.com (Postfix) with SMTP id 158BF3A68DA; Mon, 30 Jun 2008 13:18:12 -0700 (PDT) Message-ID: 2cc6e01c8daee$77c7bef0$091dfb17@home6ecbb4f764 From: "Maureen Tuttle" To: Cc: , " 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 B1EE23A69B2 for ; Mon, 30 Jun 2008 17:51:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.344 X-Spam-Level: X-Spam-Status: No, score=-102.344 tagged_above=-999 required=5 tests=[AWL=0.255, 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 EUl4erTBWCBZ for ; Mon, 30 Jun 2008 17:51: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 62E463A6951 for ; Mon, 30 Jun 2008 17:51: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 m610UFoF083540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Jun 2008 17:30:15 -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 m610UFsG083539; Mon, 30 Jun 2008 17:30:15 -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 m610UE6Q083533 for ; Mon, 30 Jun 2008 17:30:14 -0700 (MST) (envelope-from root@core3.amsl.com) Received: by core3.amsl.com (Postfix, from userid 0) id D4EE13A6B29; Mon, 30 Jun 2008 17:30: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-3850bis-04.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080701003001.D4EE13A6B29@core3.amsl.com> Date: Mon, 30 Jun 2008 17:30: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 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. --NextPart Content-Type: Message/External-body; name="draft-ietf-smime-3850bis-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-6-30172417.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 m610UFoF083540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Jun 2008 17:30:15 -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 m610UFsG083539; Mon, 30 Jun 2008 17:30:15 -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 m610UE6Q083533 for ; Mon, 30 Jun 2008 17:30:14 -0700 (MST) (envelope-from root@core3.amsl.com) Received: by core3.amsl.com (Postfix, from userid 0) id D4EE13A6B29; Mon, 30 Jun 2008 17:30: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-3850bis-04.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080701003001.D4EE13A6B29@core3.amsl.com> Date: Mon, 30 Jun 2008 17:30: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 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. --NextPart Content-Type: Message/External-body; name="draft-ietf-smime-3850bis-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-6-30172417.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 m5Q8Wn6A058286 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Jun 2008 01:32: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 m5Q8WnCs058285; Thu, 26 Jun 2008 01:32:49 -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 maiev.nerim.net (maiev.ipv6.nerim.net [IPv6:2001:7a8:1:1::89]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5Q8WmYx058268 for ; Thu, 26 Jun 2008 01:32:48 -0700 (MST) (envelope-from julien.stern@cryptolog.com) Received: from uranus.cry.pto (cryptolog2.pck.nerim.net [213.41.184.9]) by maiev.nerim.net (Postfix) with ESMTP id F2C14B8208; Thu, 26 Jun 2008 10:32:46 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id B17224429B; Thu, 26 Jun 2008 10:32:46 +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 3rIIqhcPfaZJ; Thu, 26 Jun 2008 10:32:42 +0200 (CEST) Received: from [10.0.1.15] (isonoe.cry.pto [10.0.1.15]) by uranus.cry.pto (Postfix) with ESMTP id 8454C4428C; Thu, 26 Jun 2008 10:32:42 +0200 (CEST) Message-ID: <4863542A.8080902@cryptolog.com> Date: Thu, 26 Jun 2008 10:32:42 +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: <200806260718.m5Q7Ilo1040460@balder-227.proper.com> In-Reply-To: <200806260718.m5Q7Ilo1040460@balder-227.proper.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Yasir, first, you may want to have a look at ETSI TR 102 272, which defines a binary format to represent the technical information needed in a signature policy. Second, it is not because the document is not referenced that it cannot be hashed. You can view the SPUri as a "hint" to retrieve the policy, that could also be obtained by other means. Regards, -- Julien Yasir Khan wrote: > 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 m5Q80Cbp051328 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Jun 2008 01:00:12 -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 m5Q80Cq7051327; Thu, 26 Jun 2008 01:00:12 -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 m5Q809CW051320 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 26 Jun 2008 01:00:11 -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; Thu, 26 Jun 2008 12:03:53 +0400 Received: from smirnovxp64 ([192.168.68.187] RDNS failed) by mx4.cryptopro.ru with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Jun 2008 12:03:52 +0400 From: "Pavel V. Smirnov" To: "'Yasir Khan'" , References: <000a01c8d6b3$95f8cde0$c1ea69a0$@ru> <200806260718.m5Q7Ilo1040460@balder-227.proper.com> In-Reply-To: <200806260718.m5Q7Ilo1040460@balder-227.proper.com> Subject: RE: Using Signature Policy in RFC-5126 Date: Thu, 26 Jun 2008 12:03:50 +0400 Message-ID: <002c01c8d763$2c6d3db0$8547b910$@ru> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002D_01C8D784.B37EDDB0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcjWsEVkUJ9OGEWeQRKpgqvSmd/z7AAAX7AgACx4USAAAKjZYA== Content-Language: ru X-OriginalArrivalTime: 26 Jun 2008 08:03:52.0421 (UTC) FILETIME=[2C406150:01C8D763] Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ------=_NextPart_000_002D_01C8D784.B37EDDB0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable 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_002D_01C8D784.B37EDDB0 Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable

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_002D_01C8D784.B37EDDB0-- 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 m5Q7J2Tp040553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Jun 2008 00:19:03 -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 m5Q7IvXQ040519; Thu, 26 Jun 2008 00:18: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 DS5852.ds5852.dedicated.turbodns.co.uk (server5852.dedicated.webfusion.co.uk [81.21.74.134]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5Q7Ilo1040460 for ; Thu, 26 Jun 2008 00:18:49 -0700 (MST) (envelope-from yasir.khan@ascertia.com) Message-Id: <200806260718.m5Q7Ilo1040460@balder-227.proper.com> Received: from ascertiajtl1 ([116.71.171.117]) by ds5852.dedicated.turbodns.co.uk with MailEnable ESMTP; Thu, 26 Jun 2008 07:20:37 +0100 From: "Yasir Khan" To: "'Pavel V. Smirnov'" , Subject: RE: Using Signature Policy in RFC-5126 Date: Thu, 26 Jun 2008 13:19:09 +0500 Organization: Ascertia Limited MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcjWsEVkUJ9OGEWeQRKpgqvSmd/z7AAAX7AgACx4USA= In-Reply-To: <000a01c8d6b3$95f8cde0$c1ea69a0$@ru> Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_029B_01C8D78F.37473D90" 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_029B_01C8D78F.37473D90 Content-Type: multipart/alternative; boundary="----=_NextPart_001_029C_01C8D78F.37473D90" ------=_NextPart_001_029C_01C8D78F.37473D90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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 ----------------------------------------------------------------- ------=_NextPart_001_029C_01C8D78F.37473D90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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_029C_01C8D78F.37473D90-- ------=_NextPart_000_029B_01C8D78F.37473D90 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 MBwGCSqGSIb3DQEJBTEPFw0wODA2MjYwODE5MDhaMCMGCSqGSIb3DQEJBDEWBBRcJLGQui1YKdTX u6sUzFk4v2Ph7DBUBgkrBgEEAYI3EAQxRzBFMD8xCzAJBgNVBAYTAkdCMREwDwYDVQQKEwhBc2Nl cnRpYTEdMBsGA1UEAxMUQXNjZXJ0aWEgSW50ZXJuYWwgQ0ECAgCyMFYGCyqGSIb3DQEJEAILMUeg RTA/MQswCQYDVQQGEwJHQjERMA8GA1UEChMIQXNjZXJ0aWExHTAbBgNVBAMTFEFzY2VydGlhIElu dGVybmFsIENBAgIAsjBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG 9w0CBTANBgkqhkiG9w0BAQEFAASBgGpAkevhB3Lw15bmlGe9X4kNGaaFMVbjkzOK/lt8/U+LmdnR 2xDgnwcHSVQ1hXPCKOSWN8Puoj/gdzK/S2yc1hLq3Xb22IYR17h1fVufWMXgk0oC14LMsTOfGuce ngoyKLZpwNIT22mCNUBjzAJjdQvrUJuEVG4pBsftZETXYxXIAAAAAAAA ------=_NextPart_000_029B_01C8D78F.37473D90-- 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 m5PB3KIj000470 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Jun 2008 04:03:21 -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 m5PB3Kd4000468; Wed, 25 Jun 2008 04:03: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 mx4.cryptopro.ru (mx4.cryptopro.ru [89.221.56.34]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5PB3HLP000447 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 25 Jun 2008 04:03:19 -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; Wed, 25 Jun 2008 15:06:58 +0400 Received: from smirnovxp64 ([192.168.68.187] RDNS failed) by mx4.cryptopro.ru with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Jun 2008 15:06:58 +0400 From: "Pavel V. Smirnov" To: "'Yasir Khan'" , References: <200806250942.m5P9gqbG081423@balder-227.proper.com> In-Reply-To: <200806250942.m5P9gqbG081423@balder-227.proper.com> Subject: RE: Using Signature Policy in RFC-5126 Date: Wed, 25 Jun 2008 15:06:55 +0400 Message-ID: <000a01c8d6b3$95f8cde0$c1ea69a0$@ru> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000B_01C8D6D5.1D0A6DE0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcjWsEVkUJ9OGEWeQRKpgqvSmd/z7AAAX7Ag Content-Language: ru X-OriginalArrivalTime: 25 Jun 2008 11:06:58.0250 (UTC) FILETIME=[95E71AA0:01C8D6B3] Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ------=_NextPart_000_000B_01C8D6D5.1D0A6DE0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit 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 ----------------------------------------------------------------- ------=_NextPart_000_000B_01C8D6D5.1D0A6DE0 Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable

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_000B_01C8D6D5.1D0A6DE0-- 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 m5P9gx2Q081473 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Jun 2008 02:42:59 -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 m5P9gxNB081472; Wed, 25 Jun 2008 02:42:59 -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 DS5852.ds5852.dedicated.turbodns.co.uk (server5852.dedicated.webfusion.co.uk [81.21.74.134]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5P9gqbG081423 for ; Wed, 25 Jun 2008 02:42:53 -0700 (MST) (envelope-from yasir.khan@ascertia.com) Message-Id: <200806250942.m5P9gqbG081423@balder-227.proper.com> Received: from ascertiajtl1 ([116.71.171.117]) by ds5852.dedicated.turbodns.co.uk with MailEnable ESMTP; Wed, 25 Jun 2008 09:44:42 +0100 From: "Yasir Khan" To: Subject: Using Signature Policy in RFC-5126 Date: Wed, 25 Jun 2008 15:43:14 +0500 Organization: Ascertia Limited MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Content-Type: multipart/signed; boundary="----=_NextPart_000_0081_01C8D6DA.2E4138A0"; micalg=SHA1; protocol="application/x-pkcs7-signature" Thread-Index: AcjWsEVkUJ9OGEWeQRKpgqvSmd/z7A== 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_0081_01C8D6DA.2E4138A0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0082_01C8D6DA.2E4138A0" ------=_NextPart_001_0082_01C8D6DA.2E4138A0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit 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 ----------------------------------------------------------------- ------=_NextPart_001_0082_01C8D6DA.2E4138A0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

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_0082_01C8D6DA.2E4138A0-- ------=_NextPart_000_0081_01C8D6DA.2E4138A0 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 MBwGCSqGSIb3DQEJBTEPFw0wODA2MjUxMDQzMTRaMCMGCSqGSIb3DQEJBDEWBBSaLpcp6BykZVWZ QyQCnSsjwr4jczBUBgkrBgEEAYI3EAQxRzBFMD8xCzAJBgNVBAYTAkdCMREwDwYDVQQKEwhBc2Nl cnRpYTEdMBsGA1UEAxMUQXNjZXJ0aWEgSW50ZXJuYWwgQ0ECAgCyMFYGCyqGSIb3DQEJEAILMUeg RTA/MQswCQYDVQQGEwJHQjERMA8GA1UEChMIQXNjZXJ0aWExHTAbBgNVBAMTFEFzY2VydGlhIElu dGVybmFsIENBAgIAsjBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG 9w0CBTANBgkqhkiG9w0BAQEFAASBgLTqPVX33jmXeaFoo1h1k4OsmlstRYm1UcNK+2qZJJ1vfvOm vfYhR2uza5R6qGpkjgHoA8Q0FnNyfbof6+PJVxX9ZvylOV5nn/jcpWP/vPBml7OUwzoAy+zNAATc kBSjzok7barRQ2sCQjQzZdg04XNSpFwlImR+nhopiR6Z7vP7AAAAAAAA ------=_NextPart_000_0081_01C8D6DA.2E4138A0-- 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 m5O8CZTg059605 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Jun 2008 01:12:36 -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 m5O8CZOB059604; Tue, 24 Jun 2008 01:12: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 people.com.cn ([202.99.23.227]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m5O8CXJM059595 for ; Tue, 24 Jun 2008 01:12:34 -0700 (MST) (envelope-from iesg-secretary@ietf.org) Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm44860fe9d; Tue, 24 Jun 2008 16:27:32 +0800 Received: from mail.ietf.org([64.170.98.32]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jma2485be6b3; Fri, 20 Jun 2008 22:26:49 +0800 Received: from mail.ietf.org([64.170.98.32]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Fri, 20 Jun 2008 22:26:49 +0800 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 510E728C134; Fri, 20 Jun 2008 07:10:34 -0700 (PDT) X-Original-To: ietf-announce@ietf.org Delivered-To: ietf-announce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id A679B3A6A84; Fri, 20 Jun 2008 07:10:32 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Subject: Last Call: draft-ietf-smime-cms-rsa-kem (Use of the RSA-KEM Key Transport Algorithm in CMS) to Proposed Standard Message-Id: <20080620141032.A679B3A6A84@core3.amsl.com> Date: Fri, 20 Jun 2008 07:10:32 -0700 (PDT) Cc: ietf-smime@imc.org X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.9 Reply-To: ietf@ietf.org List-Id: IETF Announcements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-AIMC-AUTH: (null) X-AIMC-MAILFROM: ietf-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: iesg-secretary@ietf.org X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG has received a request from the S/MIME Mail Security WG (smime) to consider the following document: - 'Use of the RSA-KEM Key Transport Algorithm in CMS ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2008-07-04. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-smime-cms-rsa-kem-05.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=10322&rfc_flag=0 _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce 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 m5NKj4MY017246 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Jun 2008 13:45: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 m5NKj4BS017245; Mon, 23 Jun 2008 13:45: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 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 m5NKj3iN017239 for ; Mon, 23 Jun 2008 13:45:04 -0700 (MST) (envelope-from root@core3.amsl.com) Received: by core3.amsl.com (Postfix, from userid 0) id 16F3C3A6A15; Mon, 23 Jun 2008 13:45: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-bfibecms-09.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080623204502.16F3C3A6A15@core3.amsl.com> Date: Mon, 23 Jun 2008 13:45:02 -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 : Using the Boneh-Franklin and Boneh-Boyen identity-based Encryption Algorithms with the Cryptographic Message Syntax (CMS) Author(s) : L. Martin, M. Schertler Filename : draft-ietf-smime-bfibecms-09.txt Pages : 16 Date : 2008-6-23 This document describes the conventions for using the Boneh- Franklin (BF) and Boneh-Boyen (BB1) identity-based encryption algorithms in the Cryptographic Message Syntax (CMS) to encrypt content-encryption keys. Object identifiers and the convention for encoding a recipient's identity are also defined. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-bfibecms-09.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-bfibecms-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-6-23134051.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 m5KEAc7B049387 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Jun 2008 07:10:38 -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 m5KEActF049386; Fri, 20 Jun 2008 07:10:38 -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 m5KEAZ4n049363 for ; Fri, 20 Jun 2008 07:10:35 -0700 (MST) (envelope-from wwwrun@core3.amsl.com) Received: by core3.amsl.com (Postfix, from userid 30) id A679B3A6A84; Fri, 20 Jun 2008 07:10:32 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Subject: Last Call: draft-ietf-smime-cms-rsa-kem (Use of the RSA-KEM Key Transport Algorithm in CMS) to Proposed Standard Reply-to: ietf@ietf.org CC: Message-Id: <20080620141032.A679B3A6A84@core3.amsl.com> Date: Fri, 20 Jun 2008 07:10:32 -0700 (PDT) Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG has received a request from the S/MIME Mail Security WG (smime) to consider the following document: - 'Use of the RSA-KEM Key Transport Algorithm in CMS ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2008-07-04. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-smime-cms-rsa-kem-05.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=10322&rfc_flag=0 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 m5IGkeKi084189 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Jun 2008 09:46: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 m5IGkeLR084187; Wed, 18 Jun 2008 09:46: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 [10.20.30.162] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5IGkWVb084156 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Jun 2008 09:46:36 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <7031C0AB1F15445581AA1278B0130944@Wylie> References: <200805201421.QAA14861@TR-Sys.de> <2F75B5E58B954B87B7814C09AE730F1A@Wylie> <7031C0AB1F15445581AA1278B0130944@Wylie> Date: Wed, 18 Jun 2008 09:46:24 -0700 To: "Turner, Sean P." , From: Paul Hoffman Subject: RE: draft-ietf-smime-3851bis-02 (notes, part 2) Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 10:50 AM -0400 6/18/08, Turner, Sean P. wrote: >For (0), it seems like it might be easiest to add an appendix that says v3.2 >is backwards compatible (with the exception of some algorithms) to 2311/2312 >and ask that 2311/2312 be moved to Historic. I'll move the references to >numbered sections and put the "move to historic" text in App B in 3851bis >and App A in 3850bis. That works for me. But I would want to hear from others in the S/MIME greybeard crowd about moving v2 to historic. Are there implementations of v2 that are that way for a good reason? 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 m5IEoeXA043466 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Jun 2008 07:50: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 m5IEoeCA043465; Wed, 18 Jun 2008 07:50: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 smtp103.biz.mail.re2.yahoo.com (smtp103.biz.mail.re2.yahoo.com [68.142.229.217]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m5IEocvf043448 for ; Wed, 18 Jun 2008 07:50:39 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 82598 invoked from network); 18 Jun 2008 14:50:36 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@96.241.93.89 with login) by smtp103.biz.mail.re2.yahoo.com with SMTP; 18 Jun 2008 14:50:35 -0000 X-YMail-OSG: .r2ejeoVM1mUpCzwK8BqCEz_UTJ6P1cu_6YVnepch8ySCtkmd5o8Ly.GM_gZ7BH7elHQd7PVtXdU.Uym1.vo3uWetyHxeApDyi0LD3SvKg-- X-Yahoo-Newman-Property: ymail-3 From: "Turner, Sean P." To: References: <200805201421.QAA14861@TR-Sys.de> <2F75B5E58B954B87B7814C09AE730F1A@Wylie> Subject: RE: draft-ietf-smime-3851bis-02 (notes, part 2) Date: Wed, 18 Jun 2008 10:50:25 -0400 Organization: IECA, Inc. Message-ID: <7031C0AB1F15445581AA1278B0130944@Wylie> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <2F75B5E58B954B87B7814C09AE730F1A@Wylie> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 Thread-Index: Aci6hPPfZipj3DO/Rqei+xwSrAK2ugKasBDAAxdfIbA= Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: For (0), it seems like it might be easiest to add an appendix that says v3.2 is backwards compatible (with the exception of some algorithms) to 2311/2312 and ask that 2311/2312 be moved to Historic. I'll move the references to numbered sections and put the "move to historic" text in App B in 3851bis and App A in 3850bis. For (29), I'll modify Section 5 to register application/pkcs7-mime and application/pkcs7-signature with some boiler plate that says we're just updating the pointers in the IANA registry. I'll post a new version of both IDs before the end of the week. spt >-----Original Message----- >From: owner-ietf-smime@mail.imc.org >[mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Turner, Sean P. >Sent: Tuesday, June 03, 2008 3:42 PM >To: ietf-smime@imc.org >Subject: RE: draft-ietf-smime-3851bis-02 (notes, part 2) > > >Alfred, > >Thanks again for the review. Responses inline. In the version >I'm about to post I haven't addressed comment (0) or (29). > >All, > >Curious what others feel about (0) and (29). > >spt > >>-----Original Message----- >>(0) Front Matter / Standards Actions >> >>The draft already indicates in its front matter: >> Obsoletes: 3851 >> >>During supporting investigations, it became clear that, due >to specific >>circumstances, this will let us end up with two "valid" >>sets of S/MIME specifications -- those for S/MIME v3.2 and those for >>S/MIME v2 ! >> >>The historic reason for this scenario seems to be buried in >the S/MIME >>v2 specifications being published as Informational RFCs and not >>expressly being Obsoleted by the S/MIME v3 RFCs. >> >>In Section 1.3, this draft lists RFCs 2311 through 2315 as the >>documents originally specifying S/MIME v2. In the RFC index, the >>entries for all these RFCs list INFORMATIONAL status, >> - RFC 2313 is tagged (Obsoleted by RFC2437), >> - RFC 2314 is tagged (Obsoleted by RFC2986), but >> - RFCs 2311, 2312, and 2315 look like being current. >> >>Arguably, it would be a matter of CMS to take action for RFC >2315, but >>at least RFC 2311 and RFC 2312 are clearly within scope of the S/MIME >>v3.2 drafts. >> >>I suggest to take the opportunity to clean up the RFC metadata and >>either: >> >> - also formally Obsolete the S/MIME v2 RFCs with the publication >> of the corresponding intended S/MIME v3.2 RFCs, >> (i.e. add RFC 2311 to the Obsoletes list of this draft, >> add RFC 2312 to the Obsoletes list of [CERT32], and >> defer action for RFC 2315 to CMS), or >> >> - to explicitely declare the S/MIME v2 RFCs as Historic in >one place. > >We should address this one coment (0) and (25) togther seperately. > > >>(29) Section 5 >> >>Independent on the decision to be made regarding (0) above, >>this section needs to be amended. >> >>(29a) Scenario 1: RFC 2311 *not* Obsoleted / made HISTORIC >> >>In this case, IANA should at least be directed to update the >>media type registrations for >> >> "application/pkcs7-mime" >>and >> "application/pkcs7-signature" >> >>by adding an additional reference to [RFCTHIS], in order to >>point the reader to the most current update of the media type >>information. >> >>On the other hand, updating an old media type's information >>arguably could require updating the registration entirely, >>using the new registration template from BCP 13, RFC 4288. >> >>I leave it to the high priests of exegesis (or lawyers) to >>figure out whether RFC 4288 in fact even normatively requests >to do so. >> >>(29b) Scenario 2: RFC 2311 beinf Obsoleted or made HISTORIC >> >>In this case, the draft should substantially be amended with >>the two new media type registration templates, filled for both >>media types, "application/pkcs7-mime" and >>"application/pkcs7-signature", and IANA should be directed to >>update the registrations to incorporate this new information. > >Address this with (0). > 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 m5GLLkio060244 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Jun 2008 14:21: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 m5GLLkqS060243; Mon, 16 Jun 2008 14:21: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 woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m5GLLi1A060217 for ; Mon, 16 Jun 2008 14:21:45 -0700 (MST) (envelope-from housley@vigilsec.com) Message-Id: <200806162121.m5GLLi1A060217@balder-227.proper.com> Received: (qmail 32343 invoked by uid 0); 16 Jun 2008 21:21:36 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (72.66.14.12) by woodstock.binhost.com with SMTP; 16 Jun 2008 21:21:36 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 16 Jun 2008 17:21:29 -0400 To: "Turner, Sean P." From: Russ Housley Subject: Re: Registering smime-types Cc: ietf-smime@imc.org In-Reply-To: <86122207A729424EB57C7A85BDDDF79F@Wylie> References: <86122207A729424EB57C7A85BDDDF79F@Wylie> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The MIME types used by S/MIME are defined.  Not every CMS content type has a MIME type.  They could be defined, but up to now, we have been waiting for the need to surface first.

Russ

At 03:47 PM 6/16/2008, Turner, Sean P. wrote:

Alfred's comment about updating the IANA registry for pkcs7-smime and pkcs7-signature got me to thinking about the smime-types that are currently used.  signed-data, enveloped-data, certs-only, and compressed-data are addressed in RFC 3851 but the other content types we've defined (authenticated-data, encrypted-data, and authEnveloped-data) and others (content-with-attributes, content-collection, and others) don't have smime-types defined.  Are these others used/defined someplace I don’t know about?

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 m5GJliMb027740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Jun 2008 12:47:44 -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 m5GJliwq027739; Mon, 16 Jun 2008 12:47:44 -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 smtp106.biz.mail.re2.yahoo.com (smtp106.biz.mail.re2.yahoo.com [206.190.52.175]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m5GJlg7s027731 for ; Mon, 16 Jun 2008 12:47:43 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 83633 invoked from network); 16 Jun 2008 19:47:42 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@71.191.2.12 with login) by smtp106.biz.mail.re2.yahoo.com with SMTP; 16 Jun 2008 19:47:41 -0000 X-YMail-OSG: WcE1NaAVM1mUV3RwiWYB.jnNA.X4lmliObqxCBR4wRhPY5v_NvxG5dTqsPbiWkj0Cjb5yNWHOuruThYqO6zuQfPMiWpsgQCKEjDdA.ZGYWkAeKNDhm_qagfuCTVoxiEGKFg- X-Yahoo-Newman-Property: ymail-3 From: "Turner, Sean P." To: Subject: Registering smime-types Date: Mon, 16 Jun 2008 15:47:40 -0400 Organization: IECA, Inc. Message-ID: <86122207A729424EB57C7A85BDDDF79F@Wylie> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0109_01C8CFC8.4F232010" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 Thread-Index: AcjP6dW7Y/XzH/dLTrO7QcxDkOuDxA== 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_0109_01C8CFC8.4F232010 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Alfred's comment about updating the IANA registry for pkcs7-smime and pkcs7-signature got me to thinking about the smime-types that are currently used. signed-data, enveloped-data, certs-only, and compressed-data are addressed in RFC 3851 but the other content types we've defined (authenticated-data, encrypted-data, and authEnveloped-data) and others (content-with-attributes, content-collection, and others) don't have smime-types defined. Are these others used/defined someplace I don't know about? spt ------=_NextPart_000_0109_01C8CFC8.4F232010 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Registering smime-types

Alfred's comment about updating the = IANA registry for pkcs7-smime and pkcs7-signature got me to thinking = about the smime-types that are currently used.  signed-data, = enveloped-data, certs-only, and compressed-data are addressed in RFC = 3851 but the other content types we've defined (authenticated-data, = encrypted-data, and authEnveloped-data) and others = (content-with-attributes, content-collection, and others) don't have = smime-types defined.  Are these others used/defined someplace I = don’t know about?

spt

------=_NextPart_000_0109_01C8CFC8.4F232010-- 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 m5GGTmtr060816 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Jun 2008 09:29: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 m5GGTmGt060815; Mon, 16 Jun 2008 09:29: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 smtp103.biz.mail.re2.yahoo.com (smtp103.biz.mail.re2.yahoo.com [68.142.229.217]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m5GGTksK060790 for ; Mon, 16 Jun 2008 09:29:47 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 64732 invoked from network); 16 Jun 2008 16:29:41 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@71.191.2.12 with login) by smtp103.biz.mail.re2.yahoo.com with SMTP; 16 Jun 2008 16:29:41 -0000 X-YMail-OSG: C7h9V_oVM1lZGoSqCssE8pmbci6NJwHYiXYmQuafJBu_uynWvW5iKbv5dyBPoErxyi_7RoblqiPzimgD.CvQOx8ANHeLoKW_kV8Wnb2X.1ovPg7K2YdYGpwtbML5mMB_W2E- X-Yahoo-Newman-Property: ymail-3 From: "Turner, Sean P." To: Subject: 3851bis Sec 2.2 Date: Mon, 16 Jun 2008 12:29:40 -0400 Organization: IECA, Inc. Message-ID: <8BBFA71B925B4214983807B7AB0D6BB7@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: AcjPzixyO35yHXJPR9qVEoboPrzqyg== Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: All, I have received three comments on section 2.2. I'm interested to see if anybody has the same or alternate views on the following q/a: 1. Is there an inconsistency between section 2.2 and 2.1; in section 2.1 SHA-1 is SHOULD- while in section 2.2 RSA with SHA-1 is MUST-? Relooking at this I think there is and RSA with SHA-1 ought to be SHOULD-. 2. Should we add DSA with SHA-256? I don't think so. The reason we ended up with the text was that RSA became unencumbered between v3 and v3.1. Now that RSA is unencumbered and governments seem to be fine with RSA (at least NIST is in the short term), I'm not sure it's a requirement for S/MIME. Is there anybody out there that thinks DSA with SHA-256 ought to be a requirement? 3. The "RSA or DSA" words for sending agents have been removed. Should we add that type of wording back in? I think we should because as it reads now sending agents SHOULD- support both RSA and DSA with SHA-1 when it really ought to be or. As a result, I think we should split the receiving and sending agents requirements in to separate bullets. 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 m5BNhXx0086181 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Jun 2008 16:43:33 -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 m5BNhXH3086180; Wed, 11 Jun 2008 16:43:33 -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 bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5BNhWqY086174 for ; Wed, 11 Jun 2008 16:43:32 -0700 (MST) (envelope-from rfc-editor@rfc-editor.org) Received: by bosco.isi.edu (Postfix, from userid 70) id 8DEB5136509; Wed, 11 Jun 2008 16:43:32 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 5275 on CMS Symmetric Key Management and Distribution From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, ietf-smime@imc.org Message-Id: <20080611234332.8DEB5136509@bosco.isi.edu> Date: Wed, 11 Jun 2008 16:43:32 -0700 (PDT) Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: A new Request for Comments is now available in online RFC libraries. RFC 5275 Title: CMS Symmetric Key Management and Distribution Author: S. Turner Status: Standards Track Date: June 2008 Mailbox: turners@ieca.com Pages: 89 Characters: 207920 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-smime-symkeydist-10.txt URL: http://www.rfc-editor.org/rfc/rfc5275.txt This document describes a mechanism to manage (i.e., set up, distribute, and rekey) keys used with symmetric cryptographic algorithms. Also defined herein is a mechanism to organize users into groups to support distribution of encrypted content using symmetric cryptographic algorithms. The mechanism uses the Cryptographic Message Syntax (CMS) protocol and Certificate Management over CMS (CMC) protocol to manage the symmetric keys. Any member of the group can then later use this distributed shared key to decrypt other CMS encrypted objects with the symmetric key. This mechanism has been developed to support Secure/Multipurpose Internet Mail Extensions (S/MIME) Mail List Agents (MLAs). [STANDARDS TRACK] This document is a product of the S/MIME Mail Security Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute 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 m578NaZb059761 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 7 Jun 2008 01:23:36 -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 m578Na8h059760; Sat, 7 Jun 2008 01:23:36 -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 m578NTIg059718 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Sat, 7 Jun 2008 01:23:31 -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; Sat, 7 Jun 2008 12:26:45 +0400 Received: from smirnovxp64 ([192.168.68.187] RDNS failed) by mx4.cryptopro.ru with Microsoft SMTPSVC(6.0.3790.3959); Sat, 7 Jun 2008 12:26:45 +0400 From: "Pavel V. Smirnov" To: "'Peter Rybar'" , "'Pope, Nick'" , , "'Denis Pinkas'" CC: References: <6FC9E49ED3472043A38619BFA97F37B5018746B1@webmail.thales-esecurity.com> <200806050903.m5593V5d006047@mail.nbusr.sk> In-Reply-To: <200806050903.m5593V5d006047@mail.nbusr.sk> Subject: RE: Extending CAdES to support usual signature upgrading to CAdES-T and further Date: Sat, 7 Jun 2008 12:26:42 +0400 Message-ID: <000001c8c878$38a5f490$a9f1ddb0$@ru> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C8C899.BFB79490" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcjGIpMmSh21HPObR1m3lQZM/IvlEAAtqK0QAD90wvA= Content-Language: ru X-OriginalArrivalTime: 07 Jun 2008 08:26:45.0218 (UTC) FILETIME=[38A75420:01C8C878] Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ------=_NextPart_000_0001_01C8C899.BFB79490 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Peter, Nick, Denis, First of all, thanks for your attention. =20 Peter, Denis, I agree that suggested CAdES-T-with-certref-in-timestamp does not = provide exactly the same protection as usual CAdES-T. But there is a = strong need to extend a lifetime of already-done usual signatures going = to some kind of archive. Why doesn=E2=80=99t one use CAdES attributes to = achieve this? OK. Let=E2=80=99s not call such signatures CAdES-T, CAdES-C etc. But = let=E2=80=99s define a new branch of CAdES without signing certificate = reference in a signed attribute. There is an obvious benefit to = standardize these formats rather than anyone will do on its own. My = suggestion is mainly related to standardizing using timestamp extension = for this purpose. =20 >CadES requires the signing certificate reference. This is not going to = change. >You would like to time-stamp non-CAdES signatures. You can certainly = do this, but do not call this CAdES-T. >Placing the reference in the time-stamp token would not provide the = same protection. =20 Peter, I agree that it is a matter of good style to include validation data for = a timestamp in itself. I just wanted to point to a drawback implied by = this requirement. We may accept it and we may try to settle it. Another way to settle it is to hash the CAdES-T timestamp in a = CAdES-C-timestamp selectively, notably without attributes containing = certificate and revocation values. =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 Peter Rybar Sent: Thursday, June 05, 2008 1:03 PM To: 'Pope, Nick'; 'Pavel V. Smirnov'; ESI@LIST.ETSI.ORG; = ietf-smime@imc.org Cc: peterryb@gmail.com Subject: RE: Extending CAdES to support usual signature upgrading to = CAdES-T and further =20 Pavel, In my opinion, like in previous mail, the AdES signatures could in 3 = important sates from the time perspective. And for these 3 states there is important that the signature in the 1st = state contains the information about the signer certificate protected by = signature. The 2nd state of the signature is mainly important for validation of = expired certificates and in this case signature must contain evidence = that the signature was created before expiration of signer certificate = e. g. through signature timestamp and any revocation list or OCSP which = could contain information about potential revocation must be available = for verifier.=20 The 3rd state of the signature is important for the long term = validation. Signature in this state must contain not only all = certificates and revocation lists or OCSPs which could contain = information about potential revocation but also the integrity of all = this information must be protected because some algorithms can become = not secure. In this case the signature and all information must be = protected with additional more secure HASH (for integrity) in time when = lastly used integrity hash was considered as secure it is usually = achived by archive timestamp. =20 AdES offers for implementers many attributes which could be used to = satisfy these requirements of these 3 states and you NEED NOT to use all = of them. In my opinion it could be very helpful if some security annex of AdES = standard will contain any recommendation which attribute is useful to = protect which security attack or in which system its usage is important. =20 In this case, in my opinion, the following attributes are important for = the common usage.=20 =20 1st state id-contentType=20 id-messageDigest=20 id-aa-ets-signingCertificateV2 or id-aa-signingCertificate =20 2nd state id-contentType=20 id-messageDigest=20 id-aa-ets-signingCertificateV2 or id-aa-signingCertificate id-aa-signatureTimeStampToken Signature must contain certificates for validation of the signature and = the whole certification path with CRL or OCSP and if there are used = indirect CRL or OCSP then also certificates for its validation. =20 3rd state id-contentType=20 id-messageDigest=20 id-aa-ets-signingCertificateV2 or id-aa-signingCertificate id-aa-signatureTimeStampToken Signature must contain certificates for validation of the signature and = the whole certification path with CRL or OCSP and if there are used = indirect CRL or OCSP then also certificates for its validation. Each signature of the timestamp must contain certificates for validation = of the timestamp signature and the whole certification path with CRL or = OCSP and if there are used indirect CRL or OCSP then also certificates = for its validation. Any subsequent id-aa-ets-archiveTimestamp can be applied only if = previous one contains all verification information. =20 Timestamp itself is electronic signature and in this case the = verification information must only be added to the timestamp and not to = de signature which was time stamped. !!! =20 Peter =20 > Notably, one must store certificate and revocation values for = signature-timestamp validation in the timestamp itself, hence, after = receiving CAdES-C-timestamp one cannot add or remove these values from = signature-timestamp. =20 >An obvious solution is to allow to include timestamp validation data in = certificate-values and revocation-values attributes of the signature = itself. What do you think? =20 ---------- Forwarded message ---------- From: Peter Rybar g Date: Wed, 4 Jun 2008 17:41:55 +0200 Subject: Re: Extending CAdES to support usual signature upgrading to CAdES-T and further To: spv@cryptopro.ru Cc: ietf-smime@imc.org, ESI@list.etsi.org, = Nick.Pope@thales-esecurity.com =20 Pavel, A signer protects his certificate with his signature.=20 It must be only under his control that the verifier will use only his = certificate.=20 The signer certificate is usually protected by hash value of signer = certificate inside in the signed attributes signed by SIGNER or it could = by done when the certificate is present in the signed document like in = the PDF signature. The "security expiration" of the HASH algorithm used in the signed = attributes like reference to the signer certificate in the long term = validation is another important issue!!! !!!=20 It requires archive timestamp or secure HASH in archiving system used in = time when the hash algorithm in the signature was secure and must = include also the certificate value. Your suggest to use the timestamp for it but it is not correct because = the timestamp could be removed with another timestamp and in this case = there is no protection from the substitution attack of the signer = certificate. =20 It is the same as the usage of the MIME-TYPE of the signed document to = prevent signatures from the attack of changing the type of the = visualization of the signed document. Example is on the page: http://elpi2.szm.com/priklad.htm And one possible solution how to prevent the signature from this attack = is in the document http://www.nbusr.sk/en/electronic-signature/approved-formats/index.html http://www.nbusr.sk/ipublisher/files/nbusr.sk/elektronicky-podpis/legisla= tiva/9/specifyingcontentformalspecofdocqes_en_071.pdf =20 This attack is similar as the substitution attack of the signer = certificate.=20 Only the signer is able with his signature to protect important = information which must be used by the verifier in the visualization of = the signed document.=20 =20 It is the attack on the signed document which contains quite correct = information but not only for one type of the document but also for two = or more types of the document. Then if we try to view it as the first = type of the document then the viewer will read information which is = relevant for the first type and another one will be ignored. The same = situation happens if we view it as the second type of the document where = the viewer will only recognize the information relevant to the second = type of the document and so on.=20 The problem occurs if we sign the document without information about the = type of the document which was shown to the signer. Then the verifier could see the different information. =20 For solving this attack the application must be able to do: * In the XAdES signature =E2=80=93 the type of the signed document must = be present in the MIME-TYPE element of DataObjectFormat signed = attribute. * In the CAdES signature =E2=80=93 the type of the signed document must = be present in the MIME-TYPE which must be in the MIME header which = envelopes the signed document.=20 * Or the type of the signed document is implicitly defined by the signed = document content containing the signature and rules of manipulation of = the signed data and document like in PDF signature. =20 In this case the signatures of some data without protected information = about the type of the data like the MIME-TYPE protected by the signature = could be hazardous similarly as signatures without the protection of the = signer certificate. =20 Peter =20 _____ =20 From: owner-ietf-smime@mail.imc.org = [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Pope, Nick Sent: Wednesday, June 04, 2008 10:37 AM To: 'Pavel V. Smirnov'; ESI@LIST.ETSI.ORG; ietf-smime@imc.org Subject: RE: Extending CAdES to support usual signature upgrading to = CAdES-T and further =20 Pavel, =20 I personally have some sympathy for your view. I will add this issue to = those for discussion at the next ETSI meeting later in June. =20 Nick =20 =20 -----Original Message----- From: Pavel V. Smirnov [mailto:spv@cryptopro.ru]=20 Sent: 26 May 2008 11:50 To: 'Pope, Nick'; ESI@LIST.ETSI.ORG; ietf-smime@imc.org Subject: Extending CAdES to support usual signature upgrading to CAdES-T = and further =20 Hello all and personally Nick, =20 In current CAdES wording a regular signature without at least one signed = attribute (Signing certificate reference) cannot be added with = timestamps and validation data to achieve CAdES-T or more advanced CAdES = signature. This need arises, e.g., in a system with existing regular = signatures. There is no chance to add the required attribute to the = already computed signature, but there is a strong need to add CAdES = properties to such signatures. =20 There is rather simple approach to achieve the same properties without = including signing certificate reference as a signed attribute. Let us = include this reference as an extension in the CAdES-T timestamp = (signature timestamp). To get such timestamp one would need to include = this extension in a timestamp request and a TSA would have to shift this = extension to a timestamp token. =20 Let us define the proposed extension to a timestamp protocol and call = the signature we get a valid CAdES-T signature. More advanced CAdES = signature types turn out from this new CAdES-T perfectly without any = modification. What do you think? =20 Pavel Smirnov Crypto-Pro Tel./Fax: +7 495 780-4820 WWW: http://www.CryptoPro.ru e-mail: spv@CryptoPro.ru =20 Consider the environment before printing this mail. "Thales e-Security Limited is incorporated in England and Wales with = company registration number 2518805. Its registered office is located at = 2 Dashwood Lang Road, The Bourne Business Park, Addlestone, Nr. = Weybridge, Surrey KT15 2NX. The information contained in this e-mail is confidential. It may also be = privileged. It is only intended for the stated addressee(s) and access = to it by any other person is unauthorised. If you are not an addressee = or the intended addressee, you must not disclose, copy, circulate or in = any other way use or rely on the information contained in this e-mail. = Such unauthorised use may be unlawful. If you have received this e-mail = in error please delete it (and all copies) from your system, please also = inform us immediately on +44 (0)1844 201800 or email = postmaster@thales-esecurity.com. Commercial matters detailed or referred = to in this e-mail are subject to a written contract signed for and on = behalf of Thales e-Security Limited".=20 ------=_NextPart_000_0001_01C8C899.BFB79490 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Peter, = Nick, Denis,

First of = all, thanks for your attention.

 

Peter, = Denis,

I agree = that suggested CAdES-T-with-certref-in-timestamp does not provide exactly the = same protection as usual CAdES-T. But there is a strong need to extend a = lifetime of already-done usual signatures going to some kind of archive. Why = doesn=E2=80=99t one use CAdES attributes to achieve this?

OK. = Let=E2=80=99s not call such signatures CAdES-T, CAdES-C etc. But let=E2=80=99s define a new = branch of CAdES without signing certificate reference in a signed attribute. There is an obvious benefit to standardize these formats rather than anyone will do = on its own. My suggestion is mainly related to standardizing using timestamp = extension for this purpose.

 

>CadES requires the signing certificate reference. This is not going to = change.

 >You= would like to time-stamp non-CAdES signatures. You can certainly do = this, but do not call this CAdES-T.

>Placing the reference in the time-stamp token would not provide the same = protection.

 

Peter,

I agree = that it is a matter of good style to include validation data for a timestamp in = itself. I just wanted to point to a drawback implied by this requirement. We may = accept it and we may try to settle it.

Another = way to settle it is to hash the CAdES-T timestamp in a CAdES-C-timestamp selectively, = notably without attributes containing certificate and revocation = values.

 

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 Peter = Rybar
Sent: Thursday, June 05, 2008 1:03 PM
To: 'Pope, Nick'; 'Pavel V. Smirnov'; ESI@LIST.ETSI.ORG; ietf-smime@imc.org
Cc: peterryb@gmail.com
Subject: RE: Extending CAdES to support usual signature upgrading = to CAdES-T and further

 

 Pa= vel,

In my opinion, like in previous = mail, the AdES signatures could in 3 important sates from the time = perspective.

And for these 3 states there is = important that the signature in the 1st state contains the information about the = signer certificate protected by signature.

The 2nd state of the signature = is mainly important for validation of expired certificates and in this case = signature must contain evidence that the signature was created before expiration = of signer certificate e. g. through signature timestamp and any revocation = list or OCSP which could contain information about potential revocation must be available for verifier.

The 3rd state of the signature = is important for the long term validation. Signature in this state must contain not = only all certificates and revocation lists or OCSPs which could contain = information about potential revocation but also the integrity of all this = information must be protected because some algorithms can become not secure. In this case = the signature and all information must be protected with additional more = secure HASH (for integrity) in time when lastly used integrity hash was = considered as secure it is usually achived by archive timestamp.

 

AdES offers for implementers = many attributes which could be used to satisfy these requirements of these 3 = states and you NEED NOT to use all of them.

In my opinion it could be very = helpful if some security annex of AdES standard will contain any recommendation = which attribute is useful to protect which security attack or in which system = its usage is important.

 

In this case, in my opinion, the = following attributes are important for the common usage.

 

1st state

id-contentType =

id-messageDigest =

id-aa-ets-signingCertificateV2 or id-aa-signingCertificate

 

2nd state

id-contentType =

id-messageDigest =

id-aa-ets-signingCertificateV2 or id-aa-signingCertificate

id-aa-signatureTimeStampToken=

Signature must contain certificates for validation of the signature and the whole certification path with CRL or OCSP and if there are used indirect CRL = or OCSP then also certificates for its validation.

 

 3rd = state

id-contentType =

id-messageDigest =

id-aa-ets-signingCertificateV2 or id-aa-signingCertificate

id-aa-signatureTimeStampToken=

Signature must contain certificates for validation of the signature and the whole certification path with CRL or OCSP and if there are used indirect CRL = or OCSP then also certificates for its validation.

Each signature of the timestamp must contain certificates for validation of = the timestamp signature and the whole certification path with CRL or OCSP = and if there are used indirect CRL or OCSP then also certificates for its = validation.

Any subsequent id-aa-ets-archiveTimestamp can be = applied only if previous one contains all verification = information.

 

Timestamp itself is electronic = signature and in this case the verification information must only be added to the timestamp and not to de signature which was time stamped. = !!!

 

Peter

 

>  Notably, one must = store certificate and revocation values for signature-timestamp validation in = the timestamp itself, hence, after receiving CAdES-C-timestamp one cannot = add or remove these values from signature-timestamp.

 

>An obvious solution is to = allow to include timestamp validation data in certificate-values and = revocation-values attributes of the signature itself. What do you = think?

 

---------- Forwarded message = ----------

From: Peter Rybar g <peterryb@gmail.com>

Date: Wed, 4 Jun 2008 = 17:41:55 +0200

Subject: Re: Extending CAdES = to support usual signature upgrading to

CAdES-T and = further

To: = spv@cryptopro.ru

Cc: ietf-smime@imc.org, ESI@list.etsi.org, Nick.Pope@thales-esecurity.com

 

Pavel,

A signer protects his certificate with his signature. =

It must be only under his control that the verifier will use = only his certificate.

The signer certificate is usually protected by hash value of = signer certificate inside in the signed attributes signed by SIGNER or it could = by done when the certificate is present in the signed document like in the = PDF signature.

The "security expiration" of the HASH algorithm = used in the signed attributes like reference to the signer certificate in the = long term validation is another important issue!!! !!!

It requires archive timestamp or secure HASH in archiving = system used in time when the hash algorithm in the signature was secure and = must include also the certificate value.

Your suggest to use the timestamp for it but it is not = correct because the timestamp could be removed with another timestamp and in = this case there is no protection from the substitution attack of the signer = certificate.

 

It is the same as the usage of the MIME-TYPE of the signed = document to prevent signatures from the attack of changing the type of the = visualization of the signed document. Example is on the page:

http://elpi2.szm.com/priklad.ht= m

And one possible solution how to prevent the signature from = this attack is in the document

http://www.nbusr.sk/en/electronic-signature/approved-formats/inde= x.html

http://www= .nbusr.sk/ipublisher/files/nbusr.sk/elektronicky-podpis/legislativa/9/spe= cifyingcontentformalspecofdocqes_en_071.pdf

 

This attack is similar as the substitution attack of the = signer certificate.

Only the signer is able with his signature to protect = important information which must be used by the verifier in the visualization of = the signed document.

 

It is the attack on the signed document which contains quite correct information but not only for one type of the document but also = for two or more types of the document. Then if we try to view it as the first = type of the document then the viewer will read information which is relevant for = the first type and another one will be ignored. The same situation happens = if we view it as the second type of the document where the viewer will only = recognize the information relevant to the second type of the document and so on. =

The problem occurs if we sign the document without = information about the type of the document which was shown to the = signer.

Then the verifier could see the different = information.

 

For solving this attack the application must be able to = do:

* In the XAdES signature =E2=80=93 the type of the signed = document must be present in the MIME-TYPE element of DataObjectFormat signed = attribute.

* In the CAdES signature =E2=80=93 the type of the signed = document must be present in the MIME-TYPE which must be in the MIME header which = envelopes the signed document.

* Or the type of the signed document is implicitly defined = by the signed document content containing the signature and rules of = manipulation of the signed data and document like in PDF = signature.

 

In this case the signatures of some data without protected information about the type of the data like the MIME-TYPE protected by = the signature could be hazardous similarly as signatures without the = protection of the signer certificate.

 

Peter

 

From: owner-ietf-smime@mail.imc.org = [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Pope, Nick
Sent: Wednesday, June 04, 2008 10:37 AM
To: 'Pavel V. Smirnov'; ESI@LIST.ETSI.ORG; ietf-smime@imc.org
Subject: RE: Extending CAdES to support usual signature upgrading = to CAdES-T and further

 

Pavel,

 

I personally have some sympathy for your view.  I will = add this issue to those for discussion at the next ETSI meeting later in = June.

 

Nick

 

 

-----Origina= l Message-----
From: Pavel V. Smirnov [mailto:spv@cryptopro.ru]
Sent: 26 May 2008 11:50
To: 'Pope, Nick'; ESI@LIST.ETSI.ORG; ietf-smime@imc.org
Subject: Extending CAdES to support usual signature upgrading to = CAdES-T and further

 

Hello all and personally = Nick,

 

In current CAdES wording a = regular signature without at least one signed attribute (Signing certificate = reference) cannot be added with timestamps and validation data to achieve CAdES-T = or more advanced CAdES signature. This need arises, e.g., in a system with = existing regular signatures. There is no chance to add the required attribute to = the already computed signature, but there is a strong need to add CAdES = properties to such signatures.

 

There is rather simple approach = to achieve the same properties without including signing certificate reference as a = signed attribute. Let us include this reference as an extension in the CAdES-T timestamp (signature timestamp). To get such timestamp one would need to include this extension in a timestamp request and a TSA would have to = shift this extension to a timestamp token.

 

Let us define the proposed = extension to a timestamp protocol and call the signature we get a valid CAdES-T = signature. More advanced CAdES signature types turn out from this new CAdES-T = perfectly without any modification. What do you think?

 

Pavel Smirnov

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

 

Consider the = environment before printing this mail.

"Thales = e-Security Limited is incorporated in England and Wales with company registration = number 2518805. Its registered office is located at 2 Dashwood Lang Road, The = Bourne Business Park, Addlestone, Nr. Weybridge, Surrey KT15 = 2NX.

The information = contained in this e-mail is confidential. It may also be privileged. It is only = intended for the stated addressee(s) and access to it by any other person is = unauthorised. If you are not an addressee or the intended addressee, you must not = disclose, copy, circulate or in any other way use or rely on the information = contained in this e-mail. Such unauthorised use may be unlawful. If you have received = this e-mail in error please delete it (and all copies) from your system, = please also inform us immediately on +44 (0)1844 201800 or email postmaster@thales-esecurity.com. Commercial matters detailed or referred = to in this e-mail are subject to a written contract signed for and on behalf = of Thales e-Security Limited". =

------=_NextPart_000_0001_01C8C899.BFB79490-- 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 m55HEpVA008663 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Jun 2008 10:14: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 m55HEpbt008662; Thu, 5 Jun 2008 10:14: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 mail.multicert.com (mail.multicert.com [62.48.217.200]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m55HEmPi008641; Thu, 5 Jun 2008 10:14:49 -0700 (MST) (envelope-from ricardo.barroso@multicert.com) Received: from 10.0.0.194 (webmail.multicert.com [10.0.0.194]) by mail.multicert.prod (Postfix) with SMTP id D7DB072E46; Thu, 5 Jun 2008 18:14:47 +0100 (WEST) X-Spambayes-Classification: unsure; 0.26 Received: from teste.multicert.com (unknown [62.48.177.165]) by mail.multicert.com (Postfix) with ESMTP id E07E272F2E; Thu, 5 Jun 2008 18:14:45 +0100 (WEST) Received: from [192.168.10.88] (unknown [192.168.10.88]) by teste.multicert.com (Postfix) with ESMTP id 1025D5B764; Thu, 5 Jun 2008 18:14:44 +0100 (WEST) Message-ID: <48481F06.5010301@multicert.com> Date: Thu, 05 Jun 2008 18:14:46 +0100 From: Ricardo Barroso User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Aram Perez Cc: PKIX , ietf-smime@imc.org Subject: Re: Web-based ASN.1 decoding tool available References: <200806051325.m55DPCtJ009671@mail.nbusr.sk> <7CF18E27-23FD-464F-8BCE-1D53E8257DF7@mac.com> In-Reply-To: <7CF18E27-23FD-464F-8BCE-1D53E8257DF7@mac.com> Content-Type: multipart/alternative; boundary="------------020908070306050005030907" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------020908070306050005030907 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi all! I would like to mention ASN.1 Editor (for Windows) which is not a web-based tool and although it can't provide default values from DER, it lets you: - inspect ASN.1 structures and encapsulate parts of the structures in a more user-friendly way than simple dump tools; - edit ASN.1 structures; - save sub-parts/structures to a new file; - etc. It also includes a simple but nice data converter between PEM, HEX and BASE64 formats. Best regards, Ricardo Barroso Aram Perez wrote: > Hi Peter, >> >> Have you any free tools which are not the simple dump of asn1 DER/BER >> but which also can read a data according the 1988, 93 ASN.1 Syntax? >> Like default values from DER... > > I'm afraid I do not and I'm not aware of any such tool. To get the > default values, you would need the actual ASN.1 (which provides the > default values) and the BER/DER data. > > BERViewer, Peter Hesse's web tool, Peter Gutmann's dumpasn1 and others > similar tools just decode the BER/DER and present it in a "more" human > readable form. > > Regards, > Aram > >> >> >> Peter >> >> >> >> -----Original Message----- >> From: owner-ietf-smime@mail.imc.org >> [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Perez, Aram >> Sent: Wednesday, June 04, 2008 6:04 PM >> To: PKIX; ietf-smime@imc.org >> Subject: Re: Web-based ASN.1 decoding tool available >> >> On 6/4/08 6:53 AM, Peter Hesse wrote: >> >>> All, >>> >>> We have recently made available a web-based tool for doing an ASN.1 >>> dump. It >>> displays the ASCII HEX and the ASN structure, and when you hover >>> over the >>> structure, it highlights the relevant portion of the hex. (Clicking >>> makes the >>> highlight stick.) >>> >>> Due to PHP’s inefficiency and memory usage during parsing, we have >>> limited it >>> to files 64K and smaller. Still, it is useful for displaying >>> smaller objects >>> when you don’t have dumpasn1 installed or available. >>> >>> It can be found here: >>> http://geminisecurity.com/features-downloads/tools#fd_5 >>> Click on “Click to try the application” under PHPdumpASN. >> >> For Windows, you can also try BERViewer >> >> . I haven’t had >> time to remove the nag dialog box from the Mac version. >> >> Regards, >> Aram Perez >> >> >> > -- * Ricardo Barroso* *Telefone:* +351 217 123 010 *Telemóvel:* +351 968 332 327 *Fax:* +351 217 123 011 *Email:* ricardo.barroso@multicert.com *MULTICERT S.A.* Estrada do Casal do Canas, Lote 6, Alfragide 2720-092 Amadora - Portugal --------------020908070306050005030907 Content-Type: multipart/related; boundary="------------060705050402080307010006" --------------060705050402080307010006 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi all!

I would like to mention ASN.1 Editor (for Windows) which is not a web-based tool and although it can't provide default values from DER,
it lets you:
    - inspect ASN.1 structures and encapsulate parts of the structures in a more user-friendly way than simple dump tools;
    - edit ASN.1 structures;
    - save sub-parts/structures to a new file;
    - etc.

It also includes a simple but nice data converter between PEM, HEX and BASE64 formats.

Best regards,
Ricardo Barroso


Aram Perez wrote:
Hi Peter,

Have you any free tools which are not the simple dump of asn1 DER/BER but which also can read a data according the 1988, 93 ASN.1 Syntax?
Like default values from DER...

I'm afraid I do not and I'm not aware of any such tool. To get the default values, you would need the actual ASN.1 (which provides the default values) and the BER/DER data.

BERViewer, Peter Hesse's web tool, Peter Gutmann's dumpasn1 and others similar tools just decode the BER/DER and present it in a "more" human readable form.

Regards,
Aram



Peter



-----Original Message-----
From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Perez, Aram
Sent: Wednesday, June 04, 2008 6:04 PM
To: PKIX; ietf-smime@imc.org
Subject: Re: Web-based ASN.1 decoding tool available

On 6/4/08 6:53 AM, Peter Hesse  wrote:

All,

We have recently made available a web-based tool for doing an ASN.1 dump.  It
displays the ASCII HEX and the ASN structure, and when you hover over the
structure, it highlights the relevant portion of the hex. (Clicking makes the
highlight stick.)

Due to PHP’s inefficiency and memory usage during parsing, we have limited it
to files 64K and smaller.  Still, it is useful for displaying smaller objects
when you don’t have dumpasn1 installed or available.

It can be found here: http://geminisecurity.com/features-downloads/tools#fd_5
Click on “Click to try the application” under PHPdumpASN.

For Windows, you can also try BERViewer <http://homepage.mac.com/aramperez/berviewer.html> <http://homepage.mac.com/aramperez/berviewer.html> . I haven’t had time to remove the nag dialog box from the Mac version.

Regards,
Aram Perez






--
MySignatura2008
    Ricardo Barroso
Telefone: +351 217 123 010
Telemóvel: +351 968 332 327
Fax: +351 217 123 011		 Email:
ricardo.barroso@multicert.com		 MULTICERT S.A.
Estrada do Casal do Canas,
 Lote 6, Alfragide
2720-092 Amadora - Portugal

--------------060705050402080307010006 Content-Type: image/jpeg; name="MailLogoMULTICERT.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="MailLogoMULTICERT.jpg" /9j/4AAQSkZJRgABAQEAeAB4AAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRof Hh0aHBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwh MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAAR CAAtAaYDASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAA AgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWG h4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl 5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREA AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYk NOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk 5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDkKdHTadHX0h8eiylTpUCVOlSzRFmOp46g jqeOoZoixHVlOgqtHVlOgrNmiJ0qzHVZKsx1mzVFiPtU8dQR9qnjqGaIsrU6VAtTpUGqLMdW EqvHVhKzZoiwnarCVXTtVhKhmqLMfap4+tQR9qnj61DNEWI6njqCOp46zZqiynSn0xOlPqDQ KKKKACiiigAooooAKKKKACimu6xozuwVFGWYnAA9a4ab4v8Ag+KZ4/ts8gU43pbsVP0OKlyU d2a06FSr/Di36Hd0VzGo+P8AQdJsrO5vpZ4TdrvihaE+bt/vFeqj61BpfxK8MavqEVjb3kiT ynbGJYigY9hk8ZrZUako86i7HPKpCMuST1OuopryJEu6R1RfVjgUoIYAggg8gisyxaKYZog5 QyoGAyV3DIFEcscoJjkVwOpU5oHYfRUfnw7ynmx7h1XcMiljmjlBMciPjrtYHFAWY+ioTd2w JBuIgR1G8Uoubds7Z4zgZOHHAoCzJaKakkcq7o3Vx0ypzTGurdSQ08QI6guKAsyWiml0Cbyy 7MZ3Z4xTFurd2CrPEzHoA4JNAWZLRUP2u2/5+Iv++xUiSxyjMbq4HdTmgLMdRUP2u2/5+If+ +xTo54pSRHKjkddrA0BZklFFFAj5Rp0dNp0dfSHx6LKVOlQJU6VLNEWY6njqCOp46hmiLEdW U6Cq0dWU6Cs2aInSrMdVkqzHWbNUWI+1Tx1BH2qeOoZoiytTpUC1OlQaosx1YSq8dWErNmiL CdqsJVdO1WEqGaosx9qnj61BH2qePrUM0RYjqeOoI6njrNmqLKdKfTE6U+oNAooooAKKKKAC iiigAooooAyfFHHhLWcf8+M//otq8X8M33h/QPh3Dqt5pFre6vJdyLaGWME5Xack+i5Fe1eJ Y3l8LavHGpZ3splVQOSShwK8H8N674Qh8KWlrrqXst7Y3EtxBHACFYttIBPTkqKmLpRrRdX4 T0KUK9TBVI4f4rotWOmx3lvN4y8Y3BkglzJbQmUKb113Zj9VHygAelGsXWk6lJ4V1TSdIi0t J7t0eKPGSUkQAkgD1NVy998QtSuNY1ic6Z4dtSDNtcmNCBjbGD1dvYd/wq9r+r6FrOreFdP8 MwSrBZzCMRGIr1dD+J4JJr0sLXrYiv7S1oK/psebj8HhsFh1RbvWbTfkd38Zv+RAf/r6i/ma 4TwD8RR4d8MarYXshd4IzNp6vzljxs+mSD9N1ei/FbTb3VfBT22n2k11ObiNvLiXc2ATk4rk tO+FLa5oHhy4vN1hcQK0d9DJGQ8iCRiB7HBxn0I9K8aal7S8ex72Fnh/qfJX2cv+D/wDiPBt xPd6/q1xcyPLPLpV67u5yWJjPNei/An/AJF7VP8Ar7X/ANAFZeieEdSPxQ1rztMubbS7lLuB J/KIQI42rg9OnSqehQeP/h5Ne2FjoP2+CVw28RNIjEcblKkEZGODUQTi035nVipQxEJU4NJt Re5T/wCav+Iv+uV9/wCiWro/gN/yDta/66w/+gtVLwv4O8R3mqa34m1qze2nmtbgRwFcPLJI hHC9gAcc+1ZXg+Xx34MguorHwrcTC5ZWcz278FQRxgj1ojeMlJruFflq0ZUoSV0orfsHxM8B 2/hiFdWiv5Z3vbxw0boAE3bm4IrVsPA0GifDrUvEUd9LLJfaKQ0LIAqbwrcH2xitb4j2Wu+J PAmhSLpM76g0qy3FvDESYiYznjqOTXQXWm3r/Bv+zltZje/2UsX2fb8+/YBtx61XIuZ2XQ53 i6nsKalLXms9tkzyaz1y90f4RPFYzPC97qzxSSIcMEESkgHtnium0b4LW2p6JZX1xrVwktzC szKkQIXcM4yeT1qnYeANa1T4XTWbWUtvqNtqTXMUE42GVTGqkDP6fSr2m+KviTpOmW+nr4Ta ZbaMRLI9s+SFGBnBwePSpil9taWOirUm1L6tNKXM76r5bmJ8R7yWLxJYeFrjUZYNI0+3giZ1 UnPyjMhUfeOMYFXfAuh+ELjxjYNpWv39xeQMZkiltNittHOTVvxx4T8RXmr6b4sstLW7mlgh a6szHv8ALlVRlSh6qemOvFXvC+peJF8SWKy+ALDTYZJNkt1DYNG0aEcndnii3v6ol1P9lSpy 6O+qWvW63PMtFsND1DWL6PXdXfTIFLGORIi+9t3TAB7Vt+HriLQfiPp1t4Y1afULK4ljilYx lBIGOGBXvgc5x2rf+HngSS48Rap/wkugSm1KEwm6iIUtv7e+KuWfhK98P/GaCfSdKuI9Gz/r VQtGitH8w3Hp81TGDsn5m1bFU5SnT5r+7tpbb77nJfETwJb+CksZIL+W6N20mRIgXbtweMfW vVvh94Dt/CqvqEV/LcNe28e5HQAL/Fxj61i/GfRNU1mDSBpmn3N4YzNv8mMttyFxnH0NelaY jxaTZxupV1gRWU9QQo4raFNKo9DzcVi6k8HBOV273276Fqiiiug8c+UadHTadHX0h8eiylTp UCVOlSzRFmOp46gjqeOoZoixHVlOgqtHVlOgrNmiJ0qzHVZKsx1mzVFiPtU8dQR9qnjqGaIs rU6VAtTpUGqLMdWEqvHVhKzZoiwnarCVXTtVhKhmqLMfap4+tQR9qnj61DNEWI6njqCOp46z ZqiynSn0xOlPqDQKKKKACiiigAooooAKKKKACsWXwh4cnlaWXQtOaRzlmNsuSfXpW1RSaT3K jOUfhdjNfw9o0thFYvpdo1pCd0cBiGxT6hemaSy8O6Lp1wLiy0qyt5gMCSOFVYfQ4rToq1KS Vk9CGk3zPcKKKKkYUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAH/2Q== --------------060705050402080307010006-- --------------020908070306050005030907-- 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 m55EYqaw075369 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Jun 2008 07:34: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 m55EYqPD075368; Thu, 5 Jun 2008 07:34:52 -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.nbusr.sk (mail.nbusr.sk [84.245.65.227]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m55EYn7c075337; Thu, 5 Jun 2008 07:34:50 -0700 (MST) (envelope-from rybar@nbusr.sk) Message-Id: <200806051436.m55EaAf9010452@mail.nbusr.sk> From: "Peter Rybar" To: "'Aram Perez'" , "'PKIX'" , ietf-smime@imc.org Subject: RE: Web-based ASN.1 decoding tool available Date: Thu, 5 Jun 2008 16:35:43 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcjHGW+R09LPo1xoT+u+1UI0FfXXTQAALrmQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <7CF18E27-23FD-464F-8BCE-1D53E8257DF7@mac.com> X-NAI-Spam-Level: * X-NAI-Spam-Score: 1 X-NAI-Spam-Report: 3 Rules triggered * 1 -- INFO_TLD -- URI: Contains a URL in the INFO top-level domain * 0 -- MISSING_MSGID -- Missing Message-ID header * 0 -- RV3031 -- BODY: Version number Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi all, This one is also nice...=20 And somebody could try to use it in online PHP :-) with at least ASN.1 = modules which are described in PKIX, SMIME RFCs. http://lionet.info/asn1c/ Peter -----Original Message----- From: owner-ietf-smime@mail.imc.org = [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Aram Perez Sent: Thursday, June 05, 2008 4:03 PM To: PKIX; ietf-smime@imc.org Subject: Re: Web-based ASN.1 decoding tool available Hi Peter, =09 Have you any free tools which are not the simple dump of asn1 DER/BER = but which also can read a data according the 1988, 93 ASN.1 Syntax?=20 Like default values from DER... I'm afraid I do not and I'm not aware of any such tool. To get the = default values, you would need the actual ASN.1 (which provides the = default values) and the BER/DER data. BERViewer, Peter Hesse's web tool, Peter Gutmann's dumpasn1 and others = similar tools just decode the BER/DER and present it in a "more" human = readable form. Regards, Aram Peter =09 =09 =09 -----Original Message----- From: owner-ietf-smime@mail.imc.org = [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Perez, Aram Sent: Wednesday, June 04, 2008 6:04 PM To: PKIX; ietf-smime@imc.org Subject: Re: Web-based ASN.1 decoding tool available =09 On 6/4/08 6:53 AM, Peter Hesse wrote: =09 =09 All, =09 We have recently made available a web-based tool for doing an ASN.1 = dump. It=20 =09 displays the ASCII HEX and the ASN structure, and when you hover over = the=20 =09 structure, it highlights the relevant portion of the hex. (Clicking = makes the=20 =09 highlight stick.) =09 Due to PHP=E2=80=99s inefficiency and memory usage during parsing, we = have limited it=20 =09 to files 64K and smaller. Still, it is useful for displaying smaller = objects=20 =09 when you don=E2=80=99t have dumpasn1 installed or available. =09 It can be found here: = http://geminisecurity.com/features-downloads/tools#fd_5 =09 Click on =E2=80=9CClick to try the application=E2=80=9D under = PHPdumpASN. =09 For Windows, you can also try BERViewer = = . I haven=E2=80=99t = had time to remove the nag dialog box from the Mac version. =09 Regards, Aram Perez =09 =09 =09 =09 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 m55E3I0I068342 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Jun 2008 07:03: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 m55E3ITD068341; Thu, 5 Jun 2008 07:03: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 smtpoutm.mac.com (smtpoutm.mac.com [17.148.16.68]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m55E3GL1068331; Thu, 5 Jun 2008 07:03:17 -0700 (MST) (envelope-from aramperez@mac.com) Received: from asmtp016-bge351000 (asmtp016-bge351000 [10.150.69.79]) by smtpoutm.mac.com (Xserve/smtpout005/MantshX 4.0) with ESMTP id m55E3G21024009; Thu, 5 Jun 2008 07:03:16 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_FkuvH/Tz1lYEXqbTGUCRSQ)" Received: from [192.168.1.3] ([76.88.67.30]) by asmtp016.mac.com (Sun Java(tm) System Messaging Server 6.3-6.03 (built Mar 14 2008; 32bit)) with ESMTPSA id <0K1Z00M9UTPD0P20@asmtp016.mac.com>; Thu, 05 Jun 2008 07:03:16 -0700 (PDT) Message-id: <7CF18E27-23FD-464F-8BCE-1D53E8257DF7@mac.com> From: Aram Perez To: PKIX , ietf-smime@imc.org In-reply-to: <200806051325.m55DPCtJ009671@mail.nbusr.sk> Subject: Re: Web-based ASN.1 decoding tool available Date: Thu, 05 Jun 2008 07:03:12 -0700 References: <200806051325.m55DPCtJ009671@mail.nbusr.sk> X-Mailer: Apple Mail (2.924) Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --Boundary_(ID_FkuvH/Tz1lYEXqbTGUCRSQ) Content-type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-transfer-encoding: quoted-printable Hi Peter, > > Have you any free tools which are not the simple dump of asn1 DER/=20 > BER but which also can read a data according the 1988, 93 ASN.1 =20 > Syntax? > Like default values from DER... I'm afraid I do not and I'm not aware of any such tool. To get the =20 default values, you would need the actual ASN.1 (which provides the =20 default values) and the BER/DER data. BERViewer, Peter Hesse's web tool, Peter Gutmann's dumpasn1 and others =20= similar tools just decode the BER/DER and present it in a "more" human =20= readable form. Regards, Aram > > > Peter > > > > -----Original Message----- > From: owner-ietf-smime@mail.imc.org = [mailto:owner-ietf-smime@mail.imc.org=20 > ] On Behalf Of Perez, Aram > Sent: Wednesday, June 04, 2008 6:04 PM > To: PKIX; ietf-smime@imc.org > Subject: Re: Web-based ASN.1 decoding tool available > > On 6/4/08 6:53 AM, Peter Hesse wrote: > >> All, >> >> We have recently made available a web-based tool for doing an ASN.1 =20= >> dump. It >> displays the ASCII HEX and the ASN structure, and when you hover =20 >> over the >> structure, it highlights the relevant portion of the hex. (Clicking =20= >> makes the >> highlight stick.) >> >> Due to PHP=92s inefficiency and memory usage during parsing, we have =20= >> limited it >> to files 64K and smaller. Still, it is useful for displaying =20 >> smaller objects >> when you don=92t have dumpasn1 installed or available. >> >> It can be found here: = http://geminisecurity.com/features-downloads/tools#fd_5 >> Click on =93Click to try the application=94 under PHPdumpASN. > > For Windows, you can also try BERViewer = > . I haven=92t had = =20 > time to remove the nag dialog box from the Mac version. > > Regards, > Aram Perez > > > --Boundary_(ID_FkuvH/Tz1lYEXqbTGUCRSQ) Content-type: text/html; charset=WINDOWS-1252 Content-transfer-encoding: quoted-printable Hi Peter,

Have you any free tools which are not the = simple dump of asn1 DER/BER but which also can read a data according the = 1988, 93 ASN.1 Syntax?
Like default values from = DER...

I'm afraid I do not and I'm = not aware of any such tool. To get the default values, you would need = the actual ASN.1 (which provides the default values) and the BER/DER = data.

BERViewer, Peter Hesse's web tool, Peter = Gutmann's dumpasn1 and others similar tools just decode the BER/DER and = present it in a "more" human readable = form.

Regards,
Aram



Peter



-----Original= Message-----
From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail= .imc.org] On Behalf Of Perez, Aram
Sent: Wednesday, June 04, 2008 = 6:04 PM
To: PKIX; ietf-smime@imc.org
Subject: = Re: Web-based ASN.1 decoding tool available

On 6/4/08 6:53 AM, = Peter Hesse  wrote:

All,

We have = recently made available a web-based tool for doing an ASN.1 dump. =  It
displays the ASCII = HEX and the ASN structure, and when you hover over the =
structure, it highlights the = relevant portion of the hex. (Clicking makes the =
highlight = stick.)

Due to PHP=92s = inefficiency and memory usage during parsing, we have limited it =
to files 64K and smaller. =  Still, it is useful for displaying smaller objects =
when you don=92t have = dumpasn1 installed or available.

It can be found = here: http://ge= minisecurity.com/features-downloads/tools#fd_5
Click on =93Click to try the application=94 under = PHPdumpASN.

For Windows, you can also try BERViewer = <http://homepage.= mac.com/aramperez/berviewer.html> <http://homepage.= mac.com/aramperez/berviewer.html> . I haven=92t had time to remove = the nag dialog box from the Mac version.

Regards,
Aram = Perez




= --Boundary_(ID_FkuvH/Tz1lYEXqbTGUCRSQ)-- 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 m55DNtLN059439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Jun 2008 06:23:55 -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 m55DNtGR059438; Thu, 5 Jun 2008 06:23:55 -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.nbusr.sk (mail.nbusr.sk [84.245.65.227]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m55DNqHj059413; Thu, 5 Jun 2008 06:23:53 -0700 (MST) (envelope-from rybar@nbusr.sk) Message-Id: <200806051325.m55DPCtJ009671@mail.nbusr.sk> From: "Peter Rybar" To: "'Perez, Aram'" , "'PKIX'" , ietf-smime@imc.org Subject: RE: Web-based ASN.1 decoding tool available Date: Thu, 5 Jun 2008 15:24:46 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcjGSlK0B56RJ/K4QmuS9tqZTIyH0AAEj9f7ACxVXxA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: X-NAI-Spam-Score: 0 X-NAI-Spam-Report: 2 Rules triggered * 0 -- MISSING_MSGID -- Missing Message-ID header * 0 -- RV3031 -- BODY: Version number Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, Have you any free tools which are not the simple dump of asn1 DER/BER = but which also can read a data according the 1988, 93 ASN.1 Syntax?=20 Like default values from DER... Peter -----Original Message----- From: owner-ietf-smime@mail.imc.org = [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Perez, Aram Sent: Wednesday, June 04, 2008 6:04 PM To: PKIX; ietf-smime@imc.org Subject: Re: Web-based ASN.1 decoding tool available On 6/4/08 6:53 AM, Peter Hesse wrote: > All, > =20 > We have recently made available a web-based tool for doing an ASN.1 = dump. It=20 > displays the ASCII HEX and the ASN structure, and when you hover over = the=20 > structure, it highlights the relevant portion of the hex. (Clicking = makes the=20 > highlight stick.) > =20 > Due to PHP=E2=80=99s inefficiency and memory usage during parsing, we = have limited it=20 > to files 64K and smaller. Still, it is useful for displaying smaller = objects=20 > when you don=E2=80=99t have dumpasn1 installed or available. > =20 > It can be found here: = http://geminisecurity.com/features-downloads/tools#fd_5 > Click on =E2=80=9CClick to try the application=E2=80=9D under = PHPdumpASN. For Windows, you can also try BERViewer = = . I haven=E2=80=99t = had time to remove the nag dialog box from the Mac version. Regards, Aram Perez 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 m5592LQc094279 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Jun 2008 02:02:21 -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 m5592LEj094278; Thu, 5 Jun 2008 02:02:21 -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.nbusr.sk (mail.nbusr.sk [84.245.65.227]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5592DKD094244 for ; Thu, 5 Jun 2008 02:02:16 -0700 (MST) (envelope-from rybar@nbusr.sk) From: "Peter Rybar" To: "'Pope, Nick'" , "'Pavel V. Smirnov'" , ESI@LIST.ETSI.ORG, ietf-smime@imc.org Cc: peterryb@gmail.com Subject: RE: Extending CAdES to support usual signature upgrading to CAdES-T and further Date: Thu, 5 Jun 2008 11:02:56 +0200 Message-ID: <200806050903.m5593V5d006047@mail.nbusr.sk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001B_01C8C6FB.B5C72F80" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcjGIpMmSh21HPObR1m3lQZM/IvlEAAtqK0Q X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <6FC9E49ED3472043A38619BFA97F37B5018746B1@webmail.thales-esecurity.com> X-NAI-Spam-Score: 0 X-NAI-Spam-Report: 1 Rules triggered * 0 -- RV3031 -- BODY: Version number 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_001B_01C8C6FB.B5C72F80 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Pavel, In my opinion, like in previous mail, the AdES signatures could in 3 = important sates from the time perspective. And for these 3 states there is important that the signature in the 1st = state contains the information about the signer certificate protected by = signature. The 2nd state of the signature is mainly important for validation of = expired certificates and in this case signature must contain evidence = that the signature was created before expiration of signer certificate = e. g. through signature timestamp and any revocation list or OCSP which = could contain information about potential revocation must be available = for verifier.=20 The 3rd state of the signature is important for the long term = validation. Signature in this state must contain not only all = certificates and revocation lists or OCSPs which could contain = information about potential revocation but also the integrity of all = this information must be protected because some algorithms can become = not secure. In this case the signature and all information must be = protected with additional more secure HASH (for integrity) in time when = lastly used integrity hash was considered as secure it is usually = achived by archive timestamp. =20 AdES offers for implementers many attributes which could be used to = satisfy these requirements of these 3 states and you NEED NOT to use all = of them. In my opinion it could be very helpful if some security annex of AdES = standard will contain any recommendation which attribute is useful to = protect which security attack or in which system its usage is important. =20 In this case, in my opinion, the following attributes are important for = the common usage.=20 =20 1st state id-contentType=20 id-messageDigest=20 id-aa-ets-signingCertificateV2 or id-aa-signingCertificate =20 2nd state id-contentType=20 id-messageDigest=20 id-aa-ets-signingCertificateV2 or id-aa-signingCertificate id-aa-signatureTimeStampToken Signature must contain certificates for validation of the signature and = the whole certification path with CRL or OCSP and if there are used = indirect CRL or OCSP then also certificates for its validation. =20 3rd state id-contentType=20 id-messageDigest=20 id-aa-ets-signingCertificateV2 or id-aa-signingCertificate id-aa-signatureTimeStampToken Signature must contain certificates for validation of the signature and = the whole certification path with CRL or OCSP and if there are used = indirect CRL or OCSP then also certificates for its validation. Each signature of the timestamp must contain certificates for validation = of the timestamp signature and the whole certification path with CRL or = OCSP and if there are used indirect CRL or OCSP then also certificates = for its validation. Any subsequent id-aa-ets-archiveTimestamp can be applied only if = previous one contains all verification information. =20 Timestamp itself is electronic signature and in this case the = verification information must only be added to the timestamp and not to = de signature which was time stamped. !!! =20 Peter =20 > Notably, one must store certificate and revocation values for = signature-timestamp validation in the timestamp itself, hence, after = receiving CAdES-C-timestamp one cannot add or remove these values from = signature-timestamp. =20 >An obvious solution is to allow to include timestamp validation data in = certificate-values and revocation-values attributes of the signature = itself. What do you think? =20 ---------- Forwarded message ---------- From: Peter Rybar g Date: Wed, 4 Jun 2008 17:41:55 +0200 Subject: Re: Extending CAdES to support usual signature upgrading to CAdES-T and further To: spv@cryptopro.ru Cc: ietf-smime@imc.org, ESI@list.etsi.org, = Nick.Pope@thales-esecurity.com =20 Pavel, A signer protects his certificate with his signature.=20 It must be only under his control that the verifier will use only his = certificate.=20 The signer certificate is usually protected by hash value of signer = certificate inside in the signed attributes signed by SIGNER or it could = by done when the certificate is present in the signed document like in = the PDF signature. The "security expiration" of the HASH algorithm used in the signed = attributes like reference to the signer certificate in the long term = validation is another important issue!!! !!!=20 It requires archive timestamp or secure HASH in archiving system used in = time when the hash algorithm in the signature was secure and must = include also the certificate value. Your suggest to use the timestamp for it but it is not correct because = the timestamp could be removed with another timestamp and in this case = there is no protection from the substitution attack of the signer = certificate. =20 It is the same as the usage of the MIME-TYPE of the signed document to = prevent signatures from the attack of changing the type of the = visualization of the signed document. Example is on the page: http://elpi2.szm.com/priklad.htm And one possible solution how to prevent the signature from this attack = is in the document http://www.nbusr.sk/en/electronic-signature/approved-formats/index.html http://www.nbusr.sk/ipublisher/files/nbusr.sk/elektronicky-podpis/legisla= tiva/9/specifyingcontentformalspecofdocqes_en_071.pdf =20 This attack is similar as the substitution attack of the signer = certificate.=20 Only the signer is able with his signature to protect important = information which must be used by the verifier in the visualization of = the signed document.=20 =20 It is the attack on the signed document which contains quite correct = information but not only for one type of the document but also for two = or more types of the document. Then if we try to view it as the first = type of the document then the viewer will read information which is = relevant for the first type and another one will be ignored. The same = situation happens if we view it as the second type of the document where = the viewer will only recognize the information relevant to the second = type of the document and so on.=20 The problem occurs if we sign the document without information about the = type of the document which was shown to the signer. Then the verifier could see the different information. =20 For solving this attack the application must be able to do: * In the XAdES signature =E2=80=93 the type of the signed document must = be present in the MIME-TYPE element of DataObjectFormat signed = attribute. * In the CAdES signature =E2=80=93 the type of the signed document must = be present in the MIME-TYPE which must be in the MIME header which = envelopes the signed document.=20 * Or the type of the signed document is implicitly defined by the signed = document content containing the signature and rules of manipulation of = the signed data and document like in PDF signature. =20 In this case the signatures of some data without protected information = about the type of the data like the MIME-TYPE protected by the signature = could be hazardous similarly as signatures without the protection of the = signer certificate. =20 Peter =20 _____ =20 From: owner-ietf-smime@mail.imc.org = [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Pope, Nick Sent: Wednesday, June 04, 2008 10:37 AM To: 'Pavel V. Smirnov'; ESI@LIST.ETSI.ORG; ietf-smime@imc.org Subject: RE: Extending CAdES to support usual signature upgrading to = CAdES-T and further =20 Pavel, =20 I personally have some sympathy for your view. I will add this issue to = those for discussion at the next ETSI meeting later in June. =20 Nick =20 =20 -----Original Message----- From: Pavel V. Smirnov [mailto:spv@cryptopro.ru]=20 Sent: 26 May 2008 11:50 To: 'Pope, Nick'; ESI@LIST.ETSI.ORG; ietf-smime@imc.org Subject: Extending CAdES to support usual signature upgrading to CAdES-T = and further =20 Hello all and personally Nick, =20 In current CAdES wording a regular signature without at least one signed = attribute (Signing certificate reference) cannot be added with = timestamps and validation data to achieve CAdES-T or more advanced CAdES = signature. This need arises, e.g., in a system with existing regular = signatures. There is no chance to add the required attribute to the = already computed signature, but there is a strong need to add CAdES = properties to such signatures. =20 There is rather simple approach to achieve the same properties without = including signing certificate reference as a signed attribute. Let us = include this reference as an extension in the CAdES-T timestamp = (signature timestamp). To get such timestamp one would need to include = this extension in a timestamp request and a TSA would have to shift this = extension to a timestamp token. =20 Let us define the proposed extension to a timestamp protocol and call = the signature we get a valid CAdES-T signature. More advanced CAdES = signature types turn out from this new CAdES-T perfectly without any = modification. What do you think? =20 Pavel Smirnov Crypto-Pro Tel./Fax: +7 495 780-4820 WWW: http://www.CryptoPro.ru e-mail: spv@CryptoPro.ru =20 Consider the environment before printing this mail. "Thales e-Security Limited is incorporated in England and Wales with = company registration number 2518805. Its registered office is located at = 2 Dashwood Lang Road, The Bourne Business Park, Addlestone, Nr. = Weybridge, Surrey KT15 2NX. The information contained in this e-mail is confidential. It may also be = privileged. It is only intended for the stated addressee(s) and access = to it by any other person is unauthorised. If you are not an addressee = or the intended addressee, you must not disclose, copy, circulate or in = any other way use or rely on the information contained in this e-mail. = Such unauthorised use may be unlawful. If you have received this e-mail = in error please delete it (and all copies) from your system, please also = inform us immediately on +44 (0)1844 201800 or email = postmaster@thales-esecurity.com. Commercial matters detailed or referred = to in this e-mail are subject to a written contract signed for and on = behalf of Thales e-Security Limited".=20 ------=_NextPart_000_001B_01C8C6FB.B5C72F80 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

 Pavel,=

In my opinion, like in previous mail, the AdES signatures could = in 3 important sates from the time perspective.

And for these 3 states there is important that the signature in = the 1st state contains the information about the signer certificate protected by signature.

The 2nd state of the signature is mainly important for = validation of expired certificates and in this case signature must contain evidence = that the signature was created before expiration of signer certificate e. g. = through signature timestamp and any revocation list or OCSP which could contain = information about potential revocation must be available for verifier. =

The 3rd state of the signature is important for the long term validation. Signature in this state must contain not only all = certificates and revocation lists or OCSPs which could contain information about potential = revocation but also the integrity of all this information must be protected because some = algorithms can become not secure. In this case the signature and all information = must be protected with additional more secure HASH (for integrity) in time when = lastly used integrity hash was considered as secure it is usually achived by = archive timestamp.

 

AdES offers for implementers many attributes which could be used = to satisfy these requirements of these 3 states and you NEED NOT to use all of = them.

In my opinion it could be very helpful if some security annex of = AdES standard will contain any recommendation which attribute is useful to = protect which security attack or in which system its usage is = important.

 

In this case, in my opinion, the following attributes are = important for the common usage.

 

1st state

id-contentType

id-messageDigest

id-aa-ets-signingCertificateV2 or id-aa-signingCertificate

 

2nd state

id-contentType

id-messageDigest

id-aa-ets-signingCertificateV2 or id-aa-signingCertificate

id-aa-signatureTimeStampToken=

Signature must contain = certificates for validation of the signature and the whole certification path with CRL or = OCSP and if there are used indirect CRL or OCSP then also certificates for its validation.

 

=C2=A03rd state

id-contentType

id-messageDigest

id-aa-ets-signingCertificateV2 or id-aa-signingCertificate

id-aa-signatureTimeStampToken=

Signature must contain = certificates for validation of the signature and the whole certification path with CRL or = OCSP and if there are used indirect CRL or OCSP then also certificates for its validation.

Each signature of the timestamp = must contain certificates for validation of the timestamp signature and the = whole certification path with CRL or OCSP and if there are used indirect CRL = or OCSP then also certificates for its validation.

Any subsequent id-aa-ets-archiveTimestamp can be = applied only if previous one contains all verification = information.

 

Timestamp itself is electronic signature and in this case the verification information must only be added to the timestamp and not to = de signature which was time stamped. !!!

 

Peter

 

> =C2=A0Notably, one must store certificate and revocation = values for signature-timestamp validation in the timestamp itself, hence, after = receiving CAdES-C-timestamp one cannot add or remove these values from signature-timestamp.

 

>An obvious solution is to allow to include timestamp = validation data in certificate-values and revocation-values attributes of the = signature itself. What do you think?

 

---------- Forwarded message = ----------

From: Peter Rybar g <peterryb@gmail.com>

Date: Wed, 4 Jun 2008 17:41:55 = +0200

Subject: Re: Extending CAdES to support usual signature upgrading to

CAdES-T and = further

To: = spv@cryptopro.ru

Cc: ietf-smime@imc.org, ESI@list.etsi.org, Nick.Pope@thales-esecurity.com

 

Pavel,=

A signer = protects his certificate with his signature.

It must be only = under his control that the verifier will use only his certificate. =

The signer = certificate is usually protected by hash value of signer certificate inside in the = signed attributes signed by SIGNER or it could by done when the certificate is = present in the signed document like in the PDF = signature.

The = "security expiration" of the HASH algorithm used in the signed attributes = like reference to the signer certificate in the long term validation is = another important issue!!! !!!

It requires = archive timestamp or secure HASH in archiving system used in time when the hash algorithm in the signature was secure and must include also the = certificate value.

Your suggest to = use the timestamp for it but it is not correct because the timestamp could be removed with another timestamp and in this case there is no protection from the = substitution attack of the signer certificate.

 =

It is the same = as the usage of the MIME-TYPE of the signed document to prevent signatures from = the attack of changing the type of the visualization of the signed document. Example is on the page:

http://elpi2.szm.com/priklad.ht= m

And one possible = solution how to prevent the signature from this attack is in the = document

http://www.nbusr.sk/en/electronic-signature/approved-formats/inde= x.html

http://www= .nbusr.sk/ipublisher/files/nbusr.sk/elektronicky-podpis/legislativa/9/spe= cifyingcontentformalspecofdocqes_en_071.pdf<= /p>

 =

This attack is = similar as the substitution attack of the signer certificate. =

Only the signer = is able with his signature to protect important information which must be used = by the verifier in the visualization of the signed document. =

 =

It is the attack = on the signed document which contains quite correct information but not only = for one type of the document but also for two or more types of the document. = Then if we try to view it as the first type of the document then the viewer will = read information which is relevant for the first type and another one will be ignored. The same situation happens if we view it as the second type of = the document where the viewer will only recognize the information relevant = to the second type of the document and so on.

The problem = occurs if we sign the document without information about the type of the document = which was shown to the signer.

Then the = verifier could see the different information.

 =

For solving this = attack the application must be able to do:

* In the XAdES = signature =E2=80=93 the type of the signed document must be present in the = MIME-TYPE element of DataObjectFormat signed attribute.

* In the CAdES = signature =E2=80=93 the type of the signed document must be present in the = MIME-TYPE which must be in the MIME header which envelopes the signed document. =

* Or the type of = the signed document is implicitly defined by the signed document content = containing the signature and rules of manipulation of the signed data and document = like in PDF signature.

 =

In this case the signatures of some data without protected information about the type of = the data like the MIME-TYPE protected by the signature could be hazardous = similarly as signatures without the protection of the signer = certificate.

 =

Peter<= /span>

 =

From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] = On Behalf Of Pope, Nick
Sent: Wednesday, June 04, = 2008 10:37 AM
To: 'Pavel V. Smirnov'; ESI@LIST.ETSI.ORG; ietf-smime@imc.org
Subject: RE: Extending = CAdES to support usual signature upgrading to CAdES-T and = further

 

Pavel,

 

I personally = have some sympathy for your view.  I will add this issue to those for = discussion at the next ETSI meeting later in June.

 

Nick

 

 

-----Original Message-----
From: Pavel V. Smirnov [mailto:spv@cryptopro.ru]
Sent: 26 May 2008 = 11:50
To: 'Pope, Nick'; ESI@LIST.ETSI.ORG; ietf-smime@imc.org
Subject: Extending CAdES = to support usual signature upgrading to CAdES-T and = further

 

Hello all and personally Nick,

 

In current CAdES wording a regular signature without at least = one signed attribute (Signing certificate reference) cannot be added with timestamps and validation data to achieve CAdES-T or more advanced CAdES signature. This need arises, e.g., in a system with existing regular signatures. There is no chance to add the required attribute to the = already computed signature, but there is a strong need to add CAdES properties = to such signatures.

 

There is rather simple approach to achieve the same properties = without including signing certificate reference as a signed attribute. Let us = include this reference as an extension in the CAdES-T timestamp (signature = timestamp). To get such timestamp one would need to include this extension in a = timestamp request and a TSA would have to shift this extension to a timestamp = token.

 

Let us define the proposed extension to a timestamp protocol and = call the signature we get a valid CAdES-T signature. More advanced CAdES = signature types turn out from this new CAdES-T perfectly without any modification. = What do you think?

 

Pavel Smirnov

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

 

Consider the environment before = printing this mail.

"Thales e-Security Limited is = incorporated in England and Wales with company registration number = 2518805. Its registered office is located at 2 Dashwood Lang Road, The = Bourne Business Park, Addlestone, Nr. Weybridge, Surrey KT15 = 2NX.

The information contained in this = e-mail is confidential. It may also be privileged. It is only intended = for the stated addressee(s) and access to it by any other person is = unauthorised. If you are not an addressee or the intended addressee, you = must not disclose, copy, circulate or in any other way use or rely on = the information contained in this e-mail. Such unauthorised use may be = unlawful. If you have received this e-mail in error please delete it = (and all copies) from your system, please also inform us immediately on = +44 (0)1844 201800 or email postmaster@thales-esecurity.com. Commercial = matters detailed or referred to in this e-mail are subject to a written = contract signed for and on behalf of Thales e-Security = Limited".

------=_NextPart_000_001B_01C8C6FB.B5C72F80-- 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 m54Lj8JZ029142 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Jun 2008 14:45:08 -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 m54Lj8LG029141; Wed, 4 Jun 2008 14:45:08 -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 m54Lj7W0029125 for ; Wed, 4 Jun 2008 14:45:07 -0700 (MST) (envelope-from root@core3.amsl.com) Received: by core3.amsl.com (Postfix, from userid 0) id CA6B23A6B1E; Wed, 4 Jun 2008 14:45: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-3851bis-03.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080604214501.CA6B23A6B1E@core3.amsl.com> Date: Wed, 4 Jun 2008 14:45: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-03.txt Pages : 41 Date : 2008-6-4 his 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-03.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-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-6-4143956.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 m54H0p8c067526 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Jun 2008 10:00: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 m54H0pE9067524; Wed, 4 Jun 2008 10:00: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 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 m54H0omt067512 for ; Wed, 4 Jun 2008 10:00:50 -0700 (MST) (envelope-from root@core3.amsl.com) Received: by core3.amsl.com (Postfix, from userid 0) id 7BE5F28C215; Wed, 4 Jun 2008 10:00: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-3278bis-00.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080604170001.7BE5F28C215@core3.amsl.com> Date: Wed, 4 Jun 2008 10:00: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-00.txt Pages : 39 Date : 2008-6-3 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-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 Content-Type: Message/External-body; name="draft-ietf-smime-3278bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-6-4094743.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 m54H0pNb067527 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Jun 2008 10:00: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 m54H0pNM067525; Wed, 4 Jun 2008 10:00: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 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 m54H0oiJ067513 for ; Wed, 4 Jun 2008 10:00:50 -0700 (MST) (envelope-from root@core3.amsl.com) Received: by core3.amsl.com (Postfix, from userid 0) id 96FB728C217; Wed, 4 Jun 2008 10:00: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-3850bis-03.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080604170001.96FB728C217@core3.amsl.com> Date: Wed, 4 Jun 2008 10:00: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 Certificate Handling Author(s) : S. Turner, B. Ramsdell Filename : draft-ietf-smime-3850bis-03.txt Pages : 18 Date : 2008-6-4 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-03.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-3850bis-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-6-4095056.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 m54G3qmi053225 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Jun 2008 09:03: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 m54G3q7p053223; Wed, 4 Jun 2008 09:03:52 -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 wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m54G3pg0053206 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL); Wed, 4 Jun 2008 09:03:52 -0700 (MST) (envelope-from aramp@qualcomm.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=aramp@qualcomm.com; q=dns/txt; s=qcdkim; t=1212595432; x=1244131432; h=from:to:date:subject:thread-topic:thread-index: message-id:in-reply-to:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:acceptlanguage: content-type:mime-version:x-ironport-av; z=From:=20"Perez,=20Aram"=20|To:=20PKI X=20,=20"ietf-smime@imc.org"=20|Date:=20Wed,=204=20Jun=202008=2009:03:47=20 -0700|Subject:=20Re:=20Web-based=20ASN.1=20decoding=20too l=20available|Thread-Topic:=20Web-based=20ASN.1=20decodin g=20tool=20available|Thread-Index:=20AcjGSlK0B56RJ/K4QmuS 9tqZTIyH0AAEj9f7|Message-ID:=20|In-Reply-To:=20<50a001c8c64a$543e55b0$fcbb0110$@ com>|Accept-Language:=20en-US|Content-Language:=20en |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20multipart/alternative=3B=0D=0A =09boundary=3D"_000_C46C0AF3F950arampqualcommcom_" |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 200,2160,5309"=3B=20a=3D"3673079"; bh=AnTuq5KFYeB8xBRr15aB8mR9qciaTkpwkm7gN2kPfvM=; b=hcsaii9veicIk67RE2REQPaG/uvkRsUraHECzsRIpx6RQ+Z+2gU0PTSL 9cl681oGsRAtxuuNw+DWz5WstKzAMtEEbagdYh8IAtV90grXLXT73cAWf CqetJeMUugnnADdBKy4I1s5AKs/Bzp5SGbbWx7Qc6ttwu7hmmghRMLMF9 A=; X-IronPort-AV: E=McAfee;i="5200,2160,5309"; a="3673079" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Jun 2008 09:03:51 -0700 Received: from msgtransport05.qualcomm.com (msgtransport05.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m54G3p6Y004910 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 4 Jun 2008 09:03:51 -0700 Received: from nasanexhc02.na.qualcomm.com (nasanexhc02.na.qualcomm.com [172.30.33.23]) by msgtransport05.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m54G3oR9025029 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 4 Jun 2008 09:03:51 -0700 Received: from nasanex01a.na.qualcomm.com (129.46.132.246) by nasanexhc02.na.qualcomm.com (172.30.33.23) with Microsoft SMTP Server (TLS) id 8.1.278.0; Wed, 4 Jun 2008 09:03:50 -0700 Received: from NASANEXMB05.na.qualcomm.com ([129.46.52.178]) by nasanex01a.na.qualcomm.com ([129.46.132.246]) with mapi; Wed, 4 Jun 2008 09:03:50 -0700 From: "Perez, Aram" To: PKIX , "ietf-smime@imc.org" Date: Wed, 4 Jun 2008 09:03:47 -0700 Subject: Re: Web-based ASN.1 decoding tool available Thread-Topic: Web-based ASN.1 decoding tool available Thread-Index: AcjGSlK0B56RJ/K4QmuS9tqZTIyH0AAEj9f7 Message-ID: In-Reply-To: <50a001c8c64a$543e55b0$fcbb0110$@com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C46C0AF3F950arampqualcommcom_" MIME-Version: 1.0 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --_000_C46C0AF3F950arampqualcommcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On 6/4/08 6:53 AM, Peter Hesse wrote: > All, > > We have recently made available a web-based tool for doing an ASN.1 dump.= It > displays the ASCII HEX and the ASN structure, and when you hover over the > structure, it highlights the relevant portion of the hex. (Clicking makes= the > highlight stick.) > > Due to PHP's inefficiency and memory usage during parsing, we have limite= d it > to files 64K and smaller. Still, it is useful for displaying smaller obj= ects > when you don't have dumpasn1 installed or available. > > It can be found here: http://geminisecurity.com/features-downloads/tools#= fd_5 > Click on "Click to try the application" under PHPdumpASN. For Windows, you can also try BERViewer . I haven'= t had time to remove the nag dialog box from the Mac version. Regards, Aram Perez --_000_C46C0AF3F950arampqualcommcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: Web-based ASN.1 decoding tool available O= n 6/4/08 6:53 AM, Peter Hesse  wrote:

> All,
>  
> We have recently made available a web-based tool for doing an ASN.1 du= mp.  It
> displays the ASCII HEX and the ASN structure, and when you hover over = the
> structure, it highlights the relevant portion of the hex. (Clicking ma= kes the
> highlight stick.)
>  
> Due to PHP’s inefficiency and memory usage during parsing, we ha= ve limited it
> to files 64K and smaller.  Still, it is useful for displaying sma= ller objects
> when you don’t have dumpasn1 installed or available.
>  
> It can be found here: http://geminisecurity.com/features-downloads/tools#fd_5=
> Click on “Click to try the application” under PHPdumpASN.<= BR>
For Windows, you can also try BERViewer <http://homepage.mac.com/aramperez/berviewer.h= tml>. I haven’t had time to remove the nag dialog box from the= Mac version.

Regards,
Aram Perez
 --_000_C46C0AF3F950arampqualcommcom_-- 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 m54DrF4B025273 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Jun 2008 06:53:15 -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 m54DrFZ2025272; Wed, 4 Jun 2008 06:53:15 -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 prospect.joyent.us (prospect.joyent.us [8.12.36.36]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m54DrDNh025250; Wed, 4 Jun 2008 06:53:13 -0700 (MST) (envelope-from pmhesse@geminisecurity.com) Received: from PeterVT43 (static-68-163-72-26.res.east.verizon.net [68.163.72.26]) by prospect.joyent.us (Postfix) with ESMTP id 07AF288883; Wed, 4 Jun 2008 13:53:11 +0000 (GMT) From: "Peter Hesse" To: "'pkix'" , Subject: Web-based ASN.1 decoding tool available Date: Wed, 4 Jun 2008 09:53:10 -0400 Message-ID: <50a001c8c64a$543e55b0$fcbb0110$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_50A1_01C8C628.CD2CB5B0" X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcjGSlK0B56RJ/K4QmuS9tqZTIyH0A== Content-Language: en-us Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. ------=_NextPart_000_50A1_01C8C628.CD2CB5B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit All, We have recently made available a web-based tool for doing an ASN.1 dump. It displays the ASCII HEX and the ASN structure, and when you hover over the structure, it highlights the relevant portion of the hex. (Clicking makes the highlight stick.) Due to PHP's inefficiency and memory usage during parsing, we have limited it to files 64K and smaller. Still, it is useful for displaying smaller objects when you don't have dumpasn1 installed or available. It can be found here: http://geminisecurity.com/features-downloads/tools#fd_5 Click on "Click to try the application" under PHPdumpASN. Enjoy! Please send me any feedback. --Peter Hesse _____ Peter Hesse pmhesse@geminisecurity.com Phone: 703-378-5808 x105 Gemini Security Solutions, Inc. Visit our relaunched website! http://geminisecurity.com "A good programmer is someone who always looks both ways before crossing a one-way street." --Doug Linder ------=_NextPart_000_50A1_01C8C628.CD2CB5B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

 

We have recently made available a web-based tool = for doing an ASN.1 dump.  It displays the ASCII HEX and the ASN structure, = and when you hover over the structure, it highlights the relevant portion of the = hex.  (Clicking makes the highlight stick.)

 

Due to PHP’s inefficiency and memory usage = during parsing, we have limited it to files 64K and smaller.  Still, it is = useful for displaying smaller objects when you don’t have dumpasn1 installed or = available.

 

It can be found here: http://g= eminisecurity.com/features-downloads/tools#fd_5

Click on “Click to try the application” = under PHPdumpASN.

 

Enjoy!  Please send me any = feedback.

 

--Peter Hesse

 

 Peter Hesse           &n= bsp;           pmhesse@gemini= security.com

 Phone: = 703-378-5808 x105      Gemini Security Solutions, = Inc.

    Visit our relaunched website! http://geminisecurity.com

"A good programmer is someone who always looks both = ways before
 crossing a one-way street." --Doug = Linder

 

------=_NextPart_000_50A1_01C8C628.CD2CB5B0-- 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 m548avgA043978 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Jun 2008 01:36: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 m548avDd043977; Wed, 4 Jun 2008 01:36: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 UKCRN08.crn.thales-esecurity.com ([193.112.44.5]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m548atOB043960 for ; Wed, 4 Jun 2008 01:36:56 -0700 (MST) (envelope-from Nick.Pope@thales-esecurity.com) Received: by webmail.thales-esecurity.com with Internet Mail Service (5.5.2653.19) id ; Wed, 4 Jun 2008 09:36:53 +0100 Message-ID: <6FC9E49ED3472043A38619BFA97F37B5018746B1@webmail.thales-esecurity.com> From: "Pope, Nick" To: "'Pavel V. Smirnov'" , ESI@LIST.ETSI.ORG, ietf-smime@imc.org Subject: RE: Extending CAdES to support usual signature upgrading to CAdES -T and further Date: Wed, 4 Jun 2008 09:36:50 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8C61E.2203C4D0" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C8C61E.2203C4D0 Content-Type: text/plain Pavel, I personally have some sympathy for your view. I will add this issue to those for discussion at the next ETSI meeting later in June. Nick -----Original Message----- From: Pavel V. Smirnov [mailto:spv@cryptopro.ru] Sent: 26 May 2008 11:50 To: 'Pope, Nick'; ESI@LIST.ETSI.ORG; ietf-smime@imc.org Subject: Extending CAdES to support usual signature upgrading to CAdES-T and further Hello all and personally Nick, In current CAdES wording a regular signature without at least one signed attribute (Signing certificate reference) cannot be added with timestamps and validation data to achieve CAdES-T or more advanced CAdES signature. This need arises, e.g., in a system with existing regular signatures. There is no chance to add the required attribute to the already computed signature, but there is a strong need to add CAdES properties to such signatures. There is rather simple approach to achieve the same properties without including signing certificate reference as a signed attribute. Let us include this reference as an extension in the CAdES-T timestamp (signature timestamp). To get such timestamp one would need to include this extension in a timestamp request and a TSA would have to shift this extension to a timestamp token. Let us define the proposed extension to a timestamp protocol and call the signature we get a valid CAdES-T signature. More advanced CAdES signature types turn out from this new CAdES-T perfectly without any modification. What do you think? Pavel Smirnov Crypto-Pro Tel./Fax: +7 495 780-4820 WWW: http://www.CryptoPro.ru e-mail: spv@CryptoPro.ru Consider the environment before printing this mail. "Thales e-Security Limited is incorporated in England and Wales with company registration number 2518805. Its registered office is located at 2 Dashwood Lang Road, The Bourne Business Park, Addlestone, Nr. Weybridge, Surrey KT15 2NX. The information contained in this e-mail is confidential. It may also be privileged. It is only intended for the stated addressee(s) and access to it by any other person is unauthorised. If you are not an addressee or the intended addressee, you must not disclose, copy, circulate or in any other way use or rely on the information contained in this e-mail. Such unauthorised use may be unlawful. If you have received this e-mail in error please delete it (and all copies) from your system, please also inform us immediately on +44 (0)1844 201800 or email postmaster@thales-esecurity.com. Commercial matters detailed or referred to in this e-mail are subject to a written contract signed for and on behalf of Thales e-Security Limited". ------_=_NextPart_001_01C8C61E.2203C4D0 Content-Type: text/html

Pavel,

 

I personally have some sympathy for your view.  I will add this issue to those for discussion at the next ETSI meeting later in June.

 

Nick

 

 

-----Original Message-----
From: Pavel V. Smirnov [mailto:spv@cryptopro.ru]
Sent: 26 May 2008 11:50
To: 'Pope, Nick'; ESI@LIST.ETSI.ORG; ietf-smime@imc.org
Subject: Extending CAdES to support usual signature upgrading to CAdES-T and further

 

Hello all and personally Nick,

 

In current CAdES wording a regular signature without at least one signed attribute (Signing certificate reference) cannot be added with timestamps and validation data to achieve CAdES-T or more advanced CAdES signature. This need arises, e.g., in a system with existing regular signatures. There is no chance to add the required attribute to the already computed signature, but there is a strong need to add CAdES properties to such signatures.

 

There is rather simple approach to achieve the same properties without including signing certificate reference as a signed attribute. Let us include this reference as an extension in the CAdES-T timestamp (signature timestamp). To get such timestamp one would need to include this extension in a timestamp request and a TSA would have to shift this extension to a timestamp token.

 

Let us define the proposed extension to a timestamp protocol and call the signature we get a valid CAdES-T signature. More advanced CAdES signature types turn out from this new CAdES-T perfectly without any modification. What do you think?

 

Pavel Smirnov

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

 

Consider the environment before printing this mail.

"Thales e-Security Limited is incorporated in England and Wales with company registration number 2518805. Its registered office is located at 2 Dashwood Lang Road, The Bourne Business Park, Addlestone, Nr. Weybridge, Surrey KT15 2NX.

The information contained in this e-mail is confidential. It may also be privileged. It is only intended for the stated addressee(s) and access to it by any other person is unauthorised. If you are not an addressee or the intended addressee, you must not disclose, copy, circulate or in any other way use or rely on the information contained in this e-mail. Such unauthorised use may be unlawful. If you have received this e-mail in error please delete it (and all copies) from your system, please also inform us immediately on +44 (0)1844 201800 or email postmaster@thales-esecurity.com. Commercial matters detailed or referred to in this e-mail are subject to a written contract signed for and on behalf of Thales e-Security Limited".

------_=_NextPart_001_01C8C61E.2203C4D0-- 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 m548UUsf041967 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Jun 2008 01:30:30 -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 m548UUon041964; Wed, 4 Jun 2008 01:30:30 -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 UKCRN08.crn.thales-esecurity.com ([193.112.44.5]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m548URA8041939 for ; Wed, 4 Jun 2008 01:30:28 -0700 (MST) (envelope-from Nick.Pope@thales-esecurity.com) Received: by webmail.thales-esecurity.com with Internet Mail Service (5.5.2653.19) id ; Wed, 4 Jun 2008 09:30:24 +0100 Message-ID: <6FC9E49ED3472043A38619BFA97F37B5018746B0@webmail.thales-esecurity.com> From: "Pope, Nick" To: "'Pavel V. Smirnov'" , ESI@LIST.ETSI.ORG, ietf-smime@imc.org Subject: RE: CAdES. Storing validation data. Date: Wed, 4 Jun 2008 09:30:20 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8C61D.39C7B640" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C8C61D.39C7B640 Content-Type: text/plain Pavel, Apologies for the delay in responding. I think this area requires some consideration, and will bring it up with other related TS 101 733 issues at the next ESI meeting later this month. Nick -----Original Message----- From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Pavel V. Smirnov Sent: 26 May 2008 11:50 To: 'Pope, Nick'; ESI@LIST.ETSI.ORG; ietf-smime@imc.org Subject: CAdES. Storing validation data. Hello all and personally Nick, I want to draw your attention to the following problem. There is only limited possible transformation between CAdES-X Type 1 signature and CAdES-X Long Type 1 signature. Notably, one must store certificate and revocation values for signature-timestamp validation in the timestamp itself, hence, after receiving CAdES-C-timestamp one cannot add or remove these values from signature-timestamp. An obvious solution is to allow to include timestamp validation data in certificate-values and revocation-values attributes of the signature itself. What do you think? Pavel Smirnov Crypto-Pro Tel./Fax: +7 495 780-4820 WWW: http://www.CryptoPro.ru e-mail: spv@CryptoPro.ru Consider the environment before printing this mail. "Thales e-Security Limited is incorporated in England and Wales with company registration number 2518805. Its registered office is located at 2 Dashwood Lang Road, The Bourne Business Park, Addlestone, Nr. Weybridge, Surrey KT15 2NX. The information contained in this e-mail is confidential. It may also be privileged. It is only intended for the stated addressee(s) and access to it by any other person is unauthorised. If you are not an addressee or the intended addressee, you must not disclose, copy, circulate or in any other way use or rely on the information contained in this e-mail. Such unauthorised use may be unlawful. If you have received this e-mail in error please delete it (and all copies) from your system, please also inform us immediately on +44 (0)1844 201800 or email postmaster@thales-esecurity.com. Commercial matters detailed or referred to in this e-mail are subject to a written contract signed for and on behalf of Thales e-Security Limited". ------_=_NextPart_001_01C8C61D.39C7B640 Content-Type: text/html

Pavel,

 

Apologies for the delay in responding.

 

I think this area requires some consideration, and will bring it up with other related TS 101 733 issues at the next ESI meeting later this month.

 

Nick

 

 

-----Original Message-----
From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Pavel V. Smirnov
Sent: 26 May 2008 11:50
To: 'Pope, Nick'; ESI@LIST.ETSI.ORG; ietf-smime@imc.org
Subject: CAdES. Storing validation data.

 

Hello all and personally Nick,

 

I want to draw your attention to the following problem.

 

There is only limited possible transformation between CAdES-X Type 1 signature and CAdES-X Long Type 1 signature. Notably, one must store certificate and revocation values for signature-timestamp validation in the timestamp itself, hence, after receiving CAdES-C-timestamp one cannot add or remove these values from signature-timestamp.

 

An obvious solution is to allow to include timestamp validation data in certificate-values and revocation-values attributes of the signature itself. What do you think?

 

Pavel Smirnov

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

 

Consider the environment before printing this mail.

"Thales e-Security Limited is incorporated in England and Wales with company registration number 2518805. Its registered office is located at 2 Dashwood Lang Road, The Bourne Business Park, Addlestone, Nr. Weybridge, Surrey KT15 2NX.

The information contained in this e-mail is confidential. It may also be privileged. It is only intended for the stated addressee(s) and access to it by any other person is unauthorised. If you are not an addressee or the intended addressee, you must not disclose, copy, circulate or in any other way use or rely on the information contained in this e-mail. Such unauthorised use may be unlawful. If you have received this e-mail in error please delete it (and all copies) from your system, please also inform us immediately on +44 (0)1844 201800 or email postmaster@thales-esecurity.com. Commercial matters detailed or referred to in this e-mail are subject to a written contract signed for and on behalf of Thales e-Security Limited".

------_=_NextPart_001_01C8C61D.39C7B640-- 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 m541meZ0040204 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Jun 2008 18:48:41 -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 m541mesH040202; Tue, 3 Jun 2008 18:48: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 people.com.cn ([202.99.23.227]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m541mbEP040185 for ; Tue, 3 Jun 2008 18:48:39 -0700 (MST) (envelope-from iesg-secretary@ietf.org) Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm3548464076; Wed, 04 Jun 2008 10:02:01 +0800 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm1448413845; Sat, 31 May 2008 16:01:26 +0800 Received: from mail.ietf.org([64.170.98.32]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm6b483c2d8f; Tue, 27 May 2008 22:00:18 +0800 Received: from mail.ietf.org([64.170.98.32]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Tue, 27 May 2008 22:00:16 +0800 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A82643A6C41; Tue, 27 May 2008 06:44:07 -0700 (PDT) X-Original-To: ietf-announce@ietf.org Delivered-To: ietf-announce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 6DA9F3A692C; Tue, 27 May 2008 06:44:05 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Subject: Protocol Action: 'Multiple Signatures in S/MIME' to Proposed Standard Message-Id: <20080527134405.6DA9F3A692C@core3.amsl.com> Date: Tue, 27 May 2008 06:44:05 -0700 (PDT) Cc: Internet Architecture Board , smime chair , smime mailing list , RFC Editor X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.9 List-Id: IETF Announcements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-AIMC-AUTH: (null) X-AIMC-MAILFROM: ietf-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: iesg-secretary@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: iesg-secretary@ietf.org X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG has approved the following document: - 'Multiple Signatures in S/MIME ' as a Proposed Standard This document is the product of the S/MIME Mail Security Working Group. The IESG contact persons are Tim Polk and Pasi Eronen. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-multisig-05.txt Technical Summary CMS SignedData includes the SignerInfo structure to convey per-signer information. SignedData supports multiple signers and multiple signature algorithms per-signer with multiple SignerInfo structures. If a signer attaches more than one SignerInfo, there are concerns that an attacker could perform a downgrade attack by removing the SignerInfo(s) with the 'strong' algorithm(s). This document defines the multiple-signatures attribute, its generation rules, and its processing rules to allow signers to convey multiple SignerInfo while protecting against downgrade attacks. Additionally, this attribute may assist during periods of algorithm migration. Working Group Summary This ID was discussed on the smime mailing list and at several IETF meetings. Initially, there was some confusion about the problem being solved but moving the general attacks against CMS hashes text to an Appendix addressed the WG's concerns. This initial confusion has really been the only major issue. Document Quality This document is new and there are no implementations - yet. There has been interest from multiple vendors about when it will be published as an RFC. Personnel Blake Ramsdell is the document Shepherd. Tim Polk is the responsible Security Area AD. RFC Editor Note Please make the following changes: a) Please remove the "Discussion" section preceding the Table of Contents. b) Please replace all occurrences of "pkcs9(9)" with "pkcs-9(9)". c) In section 2 list item 1), please make the following substitution OLD If both SignerInfo objects are not present, the relying party can easily determine that another SignerInfo has been removed. NEW Relying parties can easily determine that a SignerInfo has been removed if another SignerInfo contains a multi-sig attribute that refers to it. d) In section 8.1, Normative References, please make the following substitution: OLD [PROFILE] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002. NEW [PROFILE] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce 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 m53MKDWd091369 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Jun 2008 15:20:13 -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 m53MKDha091368; Tue, 3 Jun 2008 15:20:13 -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 m53MKCMM091351 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 3 Jun 2008 15:20:13 -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 m53MNj7C028367 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 3 Jun 2008 15:23:45 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sendmail.com; s=ladle.dkim; t=1212531825; bh=ht3qW2wVX7rl1GWBI7Dmty5YUZ0IA32kpHdP p8aPYoo=; 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=dzpLHd hNS777G4buIfcmEwsAfqGPDyRj1uCogo+i2QoknDBixwfq7LYLvEiOL12klg2/Ql+fM ELkiD/X9MYeun0qvKWYur8dUFBXK8sPqq6Wtwqu1jSuJldFjfFV/c2WV5t/YQyg3RFQ y9RayH1jaJctL2Xvs3y5FwUKcXCLKNo= 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 m53MJu5d028831 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Jun 2008 15:20:02 -0700 X-DKIM: Sendmail DKIM Filter v2.2.3 spork.sendmail.com m53MJu5d028831 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sendmail.com; s=spork.dkim; t=1212531605; bh=ht3qW2wVX7rl1GWBI7Dmty5YUZ0IA32kpHdP p8aPYoo=; 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=GK6yCdWnx+o7jOxzb/ny1BuUq7LS59ZfqbJ026 8CUfI23EQcVz7ukgf3lCkFwAErjX1SzIWH0UpaVrbebMNqw39S521QHa8TdpRPtskts bAWQvpQCF8TJseVvMX51ig0AihskDWI6SJXbUEtZzuUjY1Fm5UUtPHnN5DrS55gCms= Date: Tue, 3 Jun 2008 15:20:13 -0700 From: Blake Ramsdell To: "Turner, Sean P." Cc: ietf-smime@imc.org Subject: Re: draft-ietf-smime-3851bis-02 (notes, part 1) Message-ID: <20080603222011.GA2406@dell-desktop.example.com> References: <200805190921.LAA12918@TR-Sys.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-MM-Ex-RefId: 149371::080603152003-1AEDCB90-10316A73/0-0/0-1 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, Jun 03, 2008 at 03:41:54PM -0400, Turner, Sean P. wrote: > Alfred suggests demoting UTCTime to a SHOULD- in his last comment. I think > we should stay aligned with CMS/PKIX - curious what others think. Either UTCTime or GeneralizedTime needs to be a MUST in order for implementations to be compatible with each other. Have the historical problems with UTCTime (now that we're almost nine years into the 2000's) been that much of an issue? The migration to GeneralizedTime is already in place. We have addressed the expressed concern of the two digit ambiguity already. I think it's fine as is. 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 m53JgGCM053852 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Jun 2008 12:42: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 m53JgGoa053851; Tue, 3 Jun 2008 12:42: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 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 m53JgFow053839 for ; Tue, 3 Jun 2008 12:42:15 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 75328 invoked from network); 3 Jun 2008 19:42:14 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@96.231.124.17 with login) by smtp105.biz.mail.re2.yahoo.com with SMTP; 3 Jun 2008 19:42:13 -0000 X-YMail-OSG: eywVsjMVM1ld2DGdWIpO5tvpWP3aKG20ApkLE1bNN23P.Hc8BK6uWNUm1mkJXqVDRTdMFez5Mb56N8op9dn8oeB72_0AraYtU77vqLD91HYgJ5lxGTwAH6KO9u0XURuGS7500UOJh87Mlbdu.gszNzyp X-Yahoo-Newman-Property: ymail-3 From: "Turner, Sean P." To: References: <200805201421.QAA14861@TR-Sys.de> Subject: RE: draft-ietf-smime-3851bis-02 (notes, part 2) Date: Tue, 3 Jun 2008 15:42:06 -0400 Organization: IECA, Inc. Message-ID: <2F75B5E58B954B87B7814C09AE730F1A@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: Aci6hPPfZipj3DO/Rqei+xwSrAK2ugKasBDA In-Reply-To: <200805201421.QAA14861@TR-Sys.de> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alfred, Thanks again for the review. Responses inline. In the version I'm about to post I haven't addressed comment (0) or (29). All, Curious what others feel about (0) and (29). spt >-----Original Message----- >(0) Front Matter / Standards Actions > >The draft already indicates in its front matter: > Obsoletes: 3851 > >During supporting investigations, it became clear that, due to >specific circumstances, this will let us end up with two "valid" >sets of S/MIME specifications -- those for S/MIME v3.2 and >those for S/MIME v2 ! > >The historic reason for this scenario seems to be buried in >the S/MIME v2 specifications being published as Informational >RFCs and not expressly being Obsoleted by the S/MIME v3 RFCs. > >In Section 1.3, this draft lists RFCs 2311 through 2315 as the >documents originally specifying S/MIME v2. In the RFC index, >the entries for all these RFCs list INFORMATIONAL status, > - RFC 2313 is tagged (Obsoleted by RFC2437), > - RFC 2314 is tagged (Obsoleted by RFC2986), but > - RFCs 2311, 2312, and 2315 look like being current. > >Arguably, it would be a matter of CMS to take action for RFC >2315, but at least RFC 2311 and RFC 2312 are clearly within >scope of the S/MIME v3.2 drafts. > >I suggest to take the opportunity to clean up the RFC metadata >and either: > > - also formally Obsolete the S/MIME v2 RFCs with the publication > of the corresponding intended S/MIME v3.2 RFCs, > (i.e. add RFC 2311 to the Obsoletes list of this draft, > add RFC 2312 to the Obsoletes list of [CERT32], and > defer action for RFC 2315 to CMS), or > > - to explicitely declare the S/MIME v2 RFCs as Historic in one place. We should address this one coment (0) and (25) togther seperately. >(14) Section 2.5.3.1 > >The second bullet there says: > > - If an SMIMEEncryptionKeyPreference attribute is not found in a > SignedData object received from the desired recipient, the set of > X.509 certificates SHOULD be searched for a X.509 certificate >| with the same subject name as the signing of a X.509 certificate > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >| which can be used for key management. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >I really do not understand precisely what the last two lines >want to say. Please clean up and clarify. > > >(15) Section 2.7.1.2 > >The visible paragraph structure there is broken; the section >looks like: > > If the following two conditions are met: > > - ... > > - ... > > [[end of section]] > >More closely looking at the text, it turns out that >fortunately the situation can be cured by inserting a >paragraph break in the second bullet. For grammatical >consistency, also the initial capitalization of the bullets >should be changed. > >Thus, the section should be changed to: > > If the following two conditions are met: > > - the sending agent has no knowledge of the encryption capabilities > of the recipient; and, > > - the sending agent has no knowledge of the version of >S/MIME of the > recipient, > > then the sending agent SHOULD use AES 128 because it is a stronger > algorithm and is required by S/MIME v3.2. If the sending agent > chooses not to use AES 128 in this step, it SHOULD use tripleDES. > >Additionally, the punctuation at the end of the first bullet now could >be easily simplified: s/; and,/, and/ Accepted >(16) Section 3.1 ff. -- terminological issues > >Being a designated Standards Track document, the draft should >precisely use established IETF terminology and not >occasionally fall back to common, yet sluggish (ab)use of the >terms regarding the Internet message structure. > >Section 3.1.1 of RFC 4249 summarizes the terms established in >the Internet Mail and MIME RFCs, which I will explain again in my own >words: > > - at each conceptual protocol layer, a protocol data unit is > comprised of a header and a payload (i.e., the "body" in textual > protocols like email), and sometimes a trailer, as well; > > - the header within a protocol layer is comprised of header fields. > > Thus, each Internet (email) message has a single message header > (Section 2.1 of I-D.2822-upd now even uses the term "message header > section"). > In a structured MIME message body, each nesting level has a single > "MIME header", "MIME entity header", or "MIME part header" of its > own (cf. RFC 2045). > (We are not interested in lower level details, like MIME prologue > and epilogue, etc., for the purpose of this draft.) > > Each message header or MIME header is comprised of header fields, > with in turn consist of a field name, the colon separator, and a > field value. > > At the MIME top level, the MIME-related header fields are > integrated in the RFC[2]822 message header; they sometimes > collectively are denoted as the "MIME message header". > >Furthermore, as explained in BCP 13, RFC 4288, the IETF should >not use the popular term "MIME type", in favor of "media type". >The former had not even been defined in [MIME-SPEC], and it >has become even more misleading with the spread of other >protocols making use of these media types. > >I strongly recommend to update the draft to always use this >precise terminology. > >As a side-show, I also recommend consistently using the same >spelling and capitalization for header field names -- >preferably the spelling and case used in the original document >defining the header field --, e.g., replace "content type" and >"Content type" by "Content-Type". > >Because there are some subtle cases, I try to address most >affected instances of these issues I found in the draft text >in detail below. Agree >(17) Section 3.1 -- details > >(17a) 1st paragraph > >Applying the rationale of (16), I suggest to change (also >deleting the repeated second "used" near the end of the third >sentence, to streamline the language a bit): > > S/MIME is used to secure MIME entities. A MIME entity can be a sub- > part, sub-parts of a message, or the whole message with all its sub- > parts. A MIME entity that is the whole message includes only the >| MIME headers and MIME body, and does not include the >RFC-822 headers. > ^ ^ vvvvvv ^ >| Note that S/MIME can also be used to secure MIME entities used in > applications other than Internet mail. If protection of the RFC-822 >| headers is required, the use of the message/rfc822 MIME type is > explained later in this section. >--- ^^^^ > S/MIME is used to secure MIME entities. A MIME entity can be a sub- > part, sub-parts of a message, or the whole message with all its sub- > parts. A MIME entity that is the whole message includes only the >| MIME message headers and MIME body, and does not include >the RFC-822 >| header. Note that S/MIME can also be used to secure MIME entities in > applications other than Internet mail. If protection of the RFC-822 >| header is required, the use of the message/rfc822 media type is > explained later in this section. Accepted >(17b) 1st paragraph below 'Step 3.' > >Please remove the comma after "where" -- or put it in front of >that "where". Deleted the comma >(17c) 2nd paragraph below 'Step 3.' > >Correcting a typo and applying (16), I suggest to change: > >| In order to protect outer, non-content related message headers (for > v v ^^^^^^^ >| nstance, the "Subject", "To", "From" and "CC" fields), the sending > client MAY wrap a full MIME message in a message/rfc822 wrapper in >| order to apply S/MIME security services to these headers. It is up > ^^^^^^^ >| to the receiving client to decide how to present these "inner" > ^^^^^ >| headers along with the unprotected "outer" headers. >--- ^ ^ >| In order to protect outer, non-content related message >header fields >| (for instance, the "Subject", "To", "From" and "Cc" fields), the > sending client MAY wrap a full MIME message in a message/rfc822 >| wrapper in order to apply S/MIME security services to these header >| fields. It is up to the receiving client to decide how to present >| this "inner" header along with the unprotected "outer" header. Accepted >(18) Section 3.1.1, 2nd paragraph > >According to (16), please s/MIME type/media type/ (2x). I only found one. >(19) Section 3.1.2 > >According to (16): > > [...] If no Content-Transfer-Encoding header is > present, the transfer encoding is presumed to be 7BIT. >--- vvvvvv >| [...] If no Content-Transfer-Encoding >header field is > present, the transfer encoding is presumed to be 7BIT. Accepted >(20) Section 3.1.4 > >The legacy example of BITNET seems to be rather aged and of >very low interest -- if any; cf. http://en.wikipedia.org/wiki/BITNET . > >I therefore suggest to simply delete " (like BITNET)" While aged it is part of an example so I think we can leave it. >(21) Section 3.2 > >(21a) section title > >For added precision and consistency, I suggest to add "Media" >in front of "Type" -- cf. 3.4.3.1, discussed in (2x) below: > > 3.2. The application/pkcs7-mime Type >--- > 3.2. The application/pkcs7-mime Media Type Accepted >(21b) 3rd paragraph > >According to (16), please s/MIME type/media type/ (1x). > >(21c) last paragraph > >For added precision, and with respect to (16), the last >sentence should be amended: > >| [...]. The MIME headers of all > application/pkcs7-mime objects SHOULD include the optional "smime- > type" parameter, as described in the following sections. >--- >| [...]. The Content-Type header >| field of all application/pkcs7-mime objects SHOULD include the > optional "smime-type" parameter, as described in the following > sections. Accepted >(22) Section 3.2.1, last paragraph > >According to (16), please s/MIME type/media type/ (1x), and > s/MIME types/media types/ (1x). Fixed >(23) Section 3.2.2, last numbered bullet > >Please correct punctuation and case: > vvvv >| 3. If no common string is assigned. Then the common string of > "OID." is recommended (for example, "OID.1.3.6.1.5.5.7.6.1" > would be DES40). >--- vvv >| 3. If no common string is assigned, then the common string of > "OID." is recommended (for example, "OID.1.3.6.1.5.5.7.6.1" > would be DES40). Accepted >(24) Section 3.4.3 > >According to (16), please s/MIME type/media type/ (2x). Fixed >(25) Section 3.4.3.1 > >(25a) section title > >With respect to (16) please change: > > 3.4.3.1. The application/pkcs7-signature MIME Type >--- > 3.4.3.1. The application/pkcs7-signature Media Type > ^^^^^ > >(25b) 1st paragraph > >According to (16), please s/MIME type/media type/ (1x). Accepted >(26) Section 3.4.3.2 > >(26a) 1st paragraph below 'Step 5' > >Please adjust: > vv >| The multipart/signed Content type has two required parameters: the > protocol parameter and the micalg parameter. >--- vv >| The multipart/signed Content-Type has two required parameters: the > protocol parameter and the micalg parameter. Accepted >(26b) last paragraph: > >The draft says: > >| The SHA-224 algorithm [SHA224] and SHA-384 and SHA-512 algorithms > [FIPS180-3] are not currently recommended in S/MIME, and >are included > here for completeness. > >There's an apparent disparity. SHA-224 is also covered by >FIPS 180-3, and SHA-384 as well as SHA-512 are also covered by >RFC 4634 not even listed as a Reference. Perhaps this has >historical reasonse related to the delayed introduction of >SHA-224 via a Change Notice to FIPS 180-2. > >Since the requirements statement is "not recommended", adding >a bulk of references might be overkill; the basic Ref. should suffice. >Thus, I suggest to drop [SHA224] and simplify the language: > >| The SHA-224, SHA-384, and SHA-512 algorithms [FIPS180-3] are not > currently recommended in S/MIME, and are included here for > completeness. Accepted and I deleted the [SHA224] reference >(27) Setcion 3.9 > >(27a) 2nd paragraph > >According to (16), please change: > > The file suffix in the table below comes from the "name" >parameter in >| the content-type header, or the "filename" parameter on the content- > v ^ ^ vv ^^ ^ >| disposition header. These parameters that give the file suffix are > not listed below as part of the parameter section. >--- > The file suffix in the table below comes from the "name" >parameter in >| the Content-Type header field, or the "filename" parameter on the >| Content-Disposition header field. These parameters that give the > file suffix are not listed below as part of the parameter section. Accepted >(27b) table > >According to (16), please s/MIME type/media type/ (3x). Accepted >(28) Section 4.1 > >The draft says: > > All generated key pairs MUST be generated from a good source of non- > deterministic random input [RANDOM] and the private key MUST be > protected in a secure fashion. > >IMO, this 'MUST' requirement constitutes a *Normative* >Reference; so please promote '[RANDOM]' to Normative, moving >the entry from >B.2 to B.1. Agreed >(29) Section 5 > >Independent on the decision to be made regarding (0) above, >this section needs to be amended. > >(29a) Scenario 1: RFC 2311 *not* Obsoleted / made HISTORIC > >In this case, IANA should at least be directed to update the >media type registrations for > > "application/pkcs7-mime" >and > "application/pkcs7-signature" > >by adding an additional reference to [RFCTHIS], in order to >point the reader to the most current update of the media type >information. > >On the other hand, updating an old media type's information >arguably could require updating the registration entirely, >using the new registration template from BCP 13, RFC 4288. > >I leave it to the high priests of exegesis (or lawyers) to >figure out whether RFC 4288 in fact even normatively requests to do so. > >(29b) Scenario 2: RFC 2311 beinf Obsoleted or made HISTORIC > >In this case, the draft should substantially be amended with >the two new media type registration templates, filled for both >media types, "application/pkcs7-mime" and >"application/pkcs7-signature", and IANA should be directed to >update the registrations to incorporate this new information. Address this with (0). >(30) Section 6, 7th paragraph > >I suggest to make the statement on key size more specific >(again, to not interfere with the future addition of other >signing algorithms having other key size requirements), and to >correct the placement of hyphens, as follows: > > Some S/MIME agents created in the United States have chosen >to create >| 512 bit keys in order to get more advantageous export licenses. >| However, 512 bit keys are considered by many to be cryptographically > insecure. >--- > Some S/MIME agents created in the United States have chosen >to create >| 512-bit RSA keys in order to get more advantageous export licenses. > ^ ^^^^ v vvvv >| However, 512-bit RSA keys are considered by many to be > cryptographically insecure. This paragraph got overtaken by events. >(31) Appendix A > >(31a) general > >At first glance, it comes to surprise that there's a "~~V3dot1" >ASN.1 module. > >For clarity, I suggest adding an introductory statement >indicating that this module has been taken essentially >unchanged from RFC 3851 and still applies to S/MIME v3.2. Since there are no changes listed in Section 1.6 it would be clear but I added the NOTE anyway and the corresponding informative reference to MSG3.1. >(31b) ASN.1 comment below id-cap OID definition > >I suggest to improve the language a bit, by inserting "OID": > > -- The preferBinaryInside indicates an ability to receive messages > -- with binary encoding inside the CMS wrapper >--- vvvvv > -- The preferBinaryInside OID indicates an ability to receive > -- messages with binary encoding inside the CMS wrapper. Accepted >(32) Appendix B > >[ Interestingly, the last item for v3.2 happens to be #32 :-) ] > >(32a) section numbering > >The RFC Editor prefers References as a numbered section, not >as an Appendix. Therefore, I suggest to shuffle the >Appendices and turn this one into Section 7. I guess I'm going to leave this one alone like I did in 3850bis. >(32b) B.1, [FIPS180-3] { oooops } > vvvvvvvvvvv > [FIPS180-3] "Secure Hash Signature Standard (SHS)", National > Institute of Standards and Technology (NIST). FIPS > Publication 180-3. >--- >| [FIPS180-3] "Secure Hash Standard (SHS)", National Institute of > Standards and Technology (NIST), FIPS Publication >| 180-3, June 2007. > ^^^^^^^^^^^ >or better, listing the source first (as also done for ITU-T documents): > >| [FIPS180-3] National Institute of Standards and Technology (NIST), >| "Secure Hash Standard (SHS)", FIPS Publication 180-3, >| June 2007. Fixed >(32c) B.2, [RANDOM] > >Please add "BCP 106, " in front of "RFC 4086". >regarding eventual promotion to Normative, please see item (28) above. Fixed 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 m53Jg4ZM053814 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Jun 2008 12:42: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 m53Jg41Z053813; Tue, 3 Jun 2008 12:42: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 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 m53Jg22a053806 for ; Tue, 3 Jun 2008 12:42:03 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 71823 invoked from network); 3 Jun 2008 19:42:02 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@96.231.124.17 with login) by smtp104.biz.mail.re2.yahoo.com with SMTP; 3 Jun 2008 19:42:02 -0000 X-YMail-OSG: 9syXZJoVM1nCPHOPwLg5HcaTDcxw2BNH9Yacfw0H1_mfpeWs1j8ReHHTvY3dnZKZTnSxS7zCZ3NgoomflOJaqNyMy4ywv6VKNKtrcxL_ob5KFPUeOgZUllgu7LhHUC37XnM- X-Yahoo-Newman-Property: ymail-3 From: "Turner, Sean P." To: References: <200805190921.LAA12918@TR-Sys.de> Subject: RE: draft-ietf-smime-3851bis-02 (notes, part 1) Date: Tue, 3 Jun 2008 15:41:54 -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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 Thread-Index: Aci6acDbQCzqJFdbSIqytOgr/nmchQKgdIGw In-Reply-To: <200805190921.LAA12918@TR-Sys.de> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alfred, Thanks for the review. Responses inline. All, Alfred suggests demoting UTCTime to a SHOULD- in his last comment. I think we should stay aligned with CMS/PKIX - curious what others think. spt >-----Original Message----- >(1) Conventions used ... > >- The RFC Editor will want to make that a proper (numbered) section. > I suggest to move it to between the current sub-sections 1.1 and 1.2. Fixed. >- The comments I sent on the same part of draft-ietf-smime-3850bis-02 > also apply. Fixed. >(2) Section 1 > >(2a) 1st paragraph > >For completeness (and matching of what is said in the >Abtract), I suggest to add a short note on message compression >to the end of the first paragraph of Section 1, for instance: > > As a supplementary service, S/MIME provides for message compression. Added the sentence. >(2b) 2nd paragraph > >Perhaps the most important usage scenario for S/MIME now is >bound to SIP (using the 'sips' URIs) to protect the >negotioation of multimedia session parameters (cf. RFC 3261). >Therefore, I suggest to replace in the second paragraph of >Section 1 the clause "such as HTTP" by "such as HTTP or SIP". Added the SIP reference. >(3) General -- terminology > >It has been generally recognized that the media type concept >defined in [MIME-SPEC] has outgrown the narrow context of >MIME, and RFC 4288 (BCP 13) has confirmed that the popular >sluggish term "MIME Type" >should not be used, in favor of the proper term "Media Type", >which already had been used throughout [MIME-SPEC]. > >Therefore, I recommend to also change in this draft all >occurrences of "MIME type" to "media type" (inclusive of the >title of Section 3.4.3.1). > >Also, when refering to MIME header fields, their names should >be quoted faithfully for clarity and precision; in particular, >the hyphen should always be included after "Content", e.g., > "Content type" --> "Content-type". Agreed >(4) Section 1.1 > >(4a) 1st paragraph > >The draft says: > > This document describes a protocol for adding cryptographic >signature > and encryption services to MIME data. The MIME standard [MIME-SPEC] >| provides a general structure for the content type of Internet >| messages and allows extensions for new content type applications. > >There are two issues with the use of "content type": > >- "structure of the content type" is a slight abuse of language; > "structure of content" is the proper designation. It does say "structure for the content type :) I changed it to ...structure for the content of Internet messages... >- "content type applications" seems to be vague and unclear. > I suggest to use "content type specific applications" or > "content type based applications" instead Choose the later >(4b) 2ns and 3rd paragraph > >Please apply (3) -- 3 occurrences. I did a search for MIME type and replaced them with media type >(5) Section 1.3 > >For clarity, please add another comma after the first instance >of "inclusive", or place this word in parentheses. I tweaked it a bit but I think it's fixed now. >(6) Section 1.4 > >(6a) section title > >The legacy section title obviously is outdated, turning it ambiguous. >It should better be changed: > > 1.4. Changes Since S/MIME v3 >--- >| 1.4. Changes From S/MIME v3 to S/MIME v3.1 > >This should properly complement the correctly entitled new section, > > 1.5. Changes Since S/MIME v3.1 Fixed >(6b) last two paragraphs > >Please apply (3) -- two occurrences. Fixed >(7) Section 1.5 -- typo > >Please replace "in parantheticals" by either "parenthetical" >or "in parenthesis". I deleted "in parantheticals" - it wasn't needed. >(7) Section 1.5 -- typo > >Please replace > vv v > "AES-CBC" in parantheticals. >by either: > parenthetical "AES-CBC". >or: > parenthetic "AES-CBC". >or: > "AES-CBC" in parenthesis. Accepted - I just removed the in parenthesis. >(8) Section 2 -- clarification of the role of [ESS] > >I suggest to add a note to the text in Section 2 clarifying >that RFC 2634 [ESS] is applicable for S/MIME v3.2 as well. > >This is intended to complement the remarks in Section 1.3 >stating that RFC 2634 is part of the S/MIME v3 and S/MIME v3.1 >specification. ESS gets pulled in in section 2.5 when discussing attributes. I did add text to address ESS in section 2. >(9) Section 2.3 > >Please replace > using rsaEncryption algorithm. >by either: > using the rsaEncryption algorithm. >or: > using rsaEncryption. Accepted >(10) Section 2.4.1 > >The draft says: > > vvvvvvvvvvvv > ... the MIME content MUST be stored in the SignedData > encapContentInfo eContent OCTET STRING ... > >This is misleading; the Content-Type has to be stored there, >not the "content". >In line with (3) above, I suggest to use the phrase: > > vvvvvvvvvvv >| ... the media type MUST be stored in the SignedData > encapContentInfo eContent OCTET STRING ... Accepted >(11) Section 2.4.4, 1st paragraph > >I suggest to insert the article "the" giving "reduce the message size". Accepted >(12) Section 2.5 > >(12a) 1st paragraph > >The draft says, using redundant/replicated wording: > > vvvvvvvvvvvvv > The SignerInfo type allows the inclusion of unsigned and signed > attributes to be included along with a signature. > ^^^^^^^^^^^^^^ >I suggest to simplify the wording to: > > The SignerInfo type allows the inclusion of unsigned and signed >| attributes along with a signature. > ^ Accepted >(12b) 2nd-to-last paragraph > >The draft says: > > [..]. Receiving agents SHOULD handle attributes or > values that it does not recognize in a graceful manner. > >The wording "receiving agents ... it does not" should be improved upon. >I suggest either to turn to singular: > > vv vv >| [..]. A Receiving agent SHOULD handle >attributes or > values that it does not recognize in a graceful manner. > >or substitute "they" in the last line: > > [..]. Receiving agents SHOULD handle attributes or >| values they do not recognize in a graceful manner. > ^^^^^^^ Accepted (used the 2nd one) >(13) Section 2.5.1 > >The rules for UTCTime vs. GeneralizedTime are unfortunate for >several reasons, as I have pointed out in recent comments on >RFC 5280. They violate the lessons learned during Y2K that >4 decimal digits should *always* be encoded for year numbers, >and they cause general non-exercising of 'MUST implement' >code, generating a new security risk. > >I strongly recommend to, at a minimum, demote the "MUST" to >encode signing-time through 2049 as UTCTime to a "MUST-", >preferably "SHOULD", to promote starting general migration to >GeneralizedTime. I think we should stay aligned with CMS & PKIX on this. But, I think we should add that receiving agents must support both UTCTime and GeneralizedTime. 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 m52K1nNI029407 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Jun 2008 13:01: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 m52K1nPu029405; Mon, 2 Jun 2008 13:01:49 -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 smtp106.biz.mail.re2.yahoo.com (smtp106.biz.mail.re2.yahoo.com [206.190.52.175]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m52K1lN2029384 for ; Mon, 2 Jun 2008 13:01:48 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 38978 invoked from network); 2 Jun 2008 20:01:46 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@96.231.128.64 with login) by smtp106.biz.mail.re2.yahoo.com with SMTP; 2 Jun 2008 20:01:46 -0000 X-YMail-OSG: KOhLDoMVM1lxQNecY6O4htb1vCJgZAP3pcyYZa.qXufSr7TAAfPKT.CqNUURb9UuTmVUADiSCG2TYAE.zWSOErNGjIr5eDZ0YMZKq1FY3Q-- X-Yahoo-Newman-Property: ymail-3 From: "Turner, Sean P." To: "=?iso-8859-1?Q?'Alfred_H=CEnes'?=" , References: <200805211634.SAA16803@TR-Sys.de> Subject: RE: draft-ietf-smime-3850bis-02 (fwd) Date: Mon, 2 Jun 2008 16:01:42 -0400 Organization: IECA, Inc. Message-ID: <625EF9D4612F4D01B9F427CF37EF12EE@Wylie> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 Thread-Index: Aci7ZHmFwbths/PsSm6VTnmnlcDGFwJg23oQ In-Reply-To: <200805211634.SAA16803@TR-Sys.de> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alfred, Thanks for the review. Responses inline. spt >-----Original Message----- >(1) Conventions used ... > >a) I have not followed the progress of > draft-hoffman-additional-key-words, > but it looks like the evolution of that document might > be worth being monitored or coordinated with, in order > to avoid repeated re-specification of the new keywords. > >b) last paragraph: > > MUST- This term means the same as MUST. However, we >expect at some > point that this algorithm will no longer be a MUST in a future > document. [...] > >I'd give preference to the word-shuffled variant: > >| MUST- This term means the same as MUST. However, we >expect that at >| some point this algorithm will no longer be a MUST in a future > document. [...] We're following Paul's draft. I copied the text from Paul's ID so the text is now aligned. >(2) Section 2.2 > >Without explanation, the draft says: > > Receiving agents MUST support v1 X.509 and v3 X.509 identity > certificates as profiled in [KEYM]. [...] > >This comes to surprise. Why are v2 certificates excluded? > >The deliberations in RFC 5280 seem to make v1 much less preferable. > >If there ideed are reasons for this particular requirement, a >hint on the rationale would be useful. v1 is required for backwards compatibility. v2 isn't used because they add issuerUniqueIdentifier and subjectUniqueIdentifer - both of which were SHOULD NOT in RFCs 2459/3280 and are MUST NOT in RFC5280. >(3) Section 3 > >Below the ASN.1 fragment, please > > s/an upper bounds/an upper bound/ > ^ Fixed >(4) Section 4.3 > >The last paragraph says: > > A receiving agent MUST be capable of verifying the signatures on > certificates and CRLs with key sizes from 512 bits to 2048 bits. > >This requirement seems to be taylored to RSA/DSA key sizes, >but possibly not appropriate for the developing ECDSA context. > >To not inappropriately exclude shorter ECDSA key sizes and >request support for unusually large ECDSA key sizes, the above >statement should perhaps be restricted in scope. Matching the >algorithm support requirements in the earlier parts of 4.3, >but not precluding future more previce specification of ECDSA >use with PKIX, CMS, and S/MIME, I propose to amend the above >statement to say: > > vvvvvvvvvvvvv >| A receiving agent MUST be capable of verifying RSA and DSA >signatures > on certificates and CRLs with key sizes from 512 bits to 2048 bits. Somebody else also noted this. In the next version I added a table and noted that it's for RSA and DSA. >(5) Sections 6 > >The lenghty deliberations on MD2 in this section seem to be >aged, or almost historical now. Shouldn't there be some words >pointing out more recent developments, in particular the >perceived issues with / reduced confidence in MD5 (and perhaps >also SHA-1) as well? We're working on updating the security considerations section in both 3850bis/3851bis. I'm hoping to get the algorithm security considerations text agreed in 3850bis then we can also copy it to 3850bis. >(6) Appendix A > >It is very unusual to label these sections "Appendix". >I suggest to renumber "Appendix A" to "Section 7". This is historical and at this point I guess I'd like to leave the numbering alone so the sections align. If the RFC-editor complains then we'll change it. >"[RFC-2822]" is the only ref. tag used incorporating an RFC number. >I do not know the planned schedule, but it might happen that >2822-upd will be faster on the publication track, making a ref. >update necessary. To prepare for it, and to arrive at a more >homogenous ref. tag style, I suggest replacing "[RFC-2822]" >by "[IMF]". Changed it to IMF noted the work-in-progress. >For clerical completeness, I note the race condition that has >occurred by nearly concurrent publication events, making the >draft miss the ref. update: [KEYM] --> RFC 5280. Fixed