Subject: メス調教してみませんか？

From: "メスブタ婦人"<[email-masked]>
Date: Sat, 1 Sep 2007 07:19:37 +0800 (PHT)

ソフトSMから調教奴隷・まで

「ご主人様はM女好き」はS男性とM女性とのパートナー探し専用です。

http://allbymys.info/nn/mjo_is/

☆こんな女性にはお勧めです☆

夫婦仲が冷め切っている奥様・・・

辱しめ・虐められることに快感を覚えてしまう・・・

アブノーマル・アナルセックスなどに興味がある・・

http://allbymys.info/nn/mjo_is/

☆こんな男性にはお勧めです☆

おバカGALから淫乱熟女までとにかく醜く虐めたい！！

普段の仕事や生活、現代社会に対してのストレスが溜まっている！！

やはり男なので何から何まで支配できるM女性が欲しい！！

http://allbymys.info/nn/mjo_is/

※SMは決して犯罪ではありません。

【お互いの合意の上】ではどんな過激な・変態な行為でも出来てしまうのです。

「ご主人様はM女好き」ではそんな出会いの場をあたえているサイトです。

ただし、18歳未満の男女はご利用できませんのでご理解・ご協力をお願いします。

■■□■こんなサイトもあります！！■□■■

M男性とS女性の出会いの場を求められる場合はこちらから

↓↓↓↓↓↓↓↓↓↓↓↓

http://allbymys.info/nn/dansyaku_is/

メール受信拒否設定希望の方は

[email-masked]

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7UIlEQA074829 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Aug 2007 11:47:14 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7UIlEZ0074828; Thu, 30 Aug 2007 11:47:14 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from [10.20.30.108] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7UIlCaq074820 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 30 Aug 2007 11:47:13 -0700 (MST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To: <00f701c7eb2d$dbbe5c90$0301a8c0@Wylie>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <00f701c7eb2d$dbbe5c90$0301a8c0@Wylie>
Date: Thu, 30 Aug 2007 11:46:29 -0700
To: [email-masked]
From: Paul Hoffman
Subject: RE: UTF8 vs. Punycode
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

At 1:47 PM -0400 8/30/07, Turner, Sean P. wrote:
>Did this issue get resolved?

Simon did not propose a full alternative that we could consider.
Barring that, I would still advocate making the simple change to an
IA5String.

--Paul Hoffman, Director
--VPN Consortium

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7UHlePB067650 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Aug 2007 10:47:40 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7UHleQS067649; Thu, 30 Aug 2007 10:47:40 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] 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.13.5/8.13.5) with SMTP id l7UHlaDa067616 for ; Thu, 30 Aug 2007 10:47:38 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 47528 invoked from network); 30 Aug 2007 17:47:35 -0000
Received: from unknown (HELO Wylie) ([email-masked]@70.108.18.97 with login) by smtp103.biz.mail.re2.yahoo.com with SMTP; 30 Aug 2007 17:47:35 -0000
X-YMail-OSG: 9efh_pcVM1m1Xat0msffr2h_vKs1kzqbjvpmLfXWj_.epgnyn2fOaF2y1pMPvEVXIpTTLWdBUTmnZ6cm1bS8aYv9zazulECC2WZVRW4TdZe0JjpldfNjHNQdV_U.vi8az8yXvEELnqHL6ls-
From: "Turner, Sean P."
To: "'Paul Hoffman'" , "'Simon Josefsson'"
Cc: "'Timothy J. Miller'" , "'Russ Housley'" , , ,
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Subject: RE: UTF8 vs. Punycode
Date: Thu, 30 Aug 2007 13:47:39 -0400
Organization: IECA, Inc.
Message-ID: <00f701c7eb2d$dbbe5c90$0301a8c0@Wylie>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
Thread-Index: AcfexdI1iZOfVAanQsGWfJsT4teg6AMZrPpw
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138
In-Reply-To:
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Did this issue get resolved?

>-----Original Message-----
>From: [email-masked]
>[mailto:[email-masked]] On Behalf Of Paul Hoffman
>Sent: Tuesday, August 14, 2007 6:38 PM
>To: Simon Josefsson
>Cc: Timothy J. Miller; Russ Housley; [email-masked];
>[email-masked]; [email-masked]
>Subject: Re: UTF8 vs. Punycode
>
>
>At 12:05 AM +0200 8/15/07, Simon Josefsson wrote:
>>Paul Hoffman writes:
>>
>>> At 11:30 AM +0200 8/14/07, Simon Josefsson wrote:
>>>>One risk is that the specification cannot use Unicode code points
>>>>from a newer Unicode version than IDNA ToASCII supports, right now
>>>>that means Unicode 3.2.
>>>
>>> That is not necessarily true. The current version of IDNA
>supports
>>> Unicode version 3.2. A future version of IDNA may support later
>>> versions of Unicode.
>>
>>I believe the assumption here is that the document would
>reference the
>>current IDNA version. Or are you suggesting that this
>document should
>>wait until the IDNAbis effort is done?
>
>The former. But that does not change what I said: a later
>version of IDNA that has the additional characters you were
>talking about could be replaced in the spec with near-zero effort.
>
>> >>Some IETF protocols can easily negotiate support for UTF-8 on
>>>>both sides, and using UTF-8 rather than Punycode seems more robust
>>>>and like better engineering to me.
>>>
>>> Un-normalized fails miserably when exact matching is
>needed, such as
>>> it is in IBE.
>>
>>Sending UTF-8 does not preclude normalizing from happening when it is
>>needed.
>
>Ah, I misunderstood your proposal. I thought you meant "send
>UTF-8", not "do some normalization that is not specified here,
>then send UTF-8". It would be good if you could give your
>complete proposal so people can compare them fully.
>
>--Paul Hoffman, Director
>--VPN Consortium
>

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7SEqWth010303 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Aug 2007 07:52:32 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7SEqVlA010302; Tue, 28 Aug 2007 07:52:31 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from ns1.neustar.com (ns1.neustar.com [156.154.16.138]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7SEqUe7010296 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 28 Aug 2007 07:52:31 -0700 (MST) (envelope-from [email-masked])
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 28D5726E6E; Tue, 28 Aug 2007 14:52:30 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IQ2Qg-0002Fr-2W; Tue, 28 Aug 2007 10:52:30 -0400
X-test-idtracker: no
To: IETF-Announce
From: The IESG
Subject: Last Call: draft-ietf-smime-cms-aes-ccm-and-gcm (Using AES-CCM and AES-GCM Authenticated Encryption in the Cryptographic Message Syntax (CMS)) to Proposed Standard
Reply-To: [email-masked]
Cc:
Message-Id:
Date: Tue, 28 Aug 2007 10:52:30 -0400
Sender: [email-masked]
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:

- 'Using AES-CCM and AES-GCM Authenticated Encryption in the
Cryptographic Message Syntax (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
[email-masked] mailing lists by 2007-09-11. Exceptionally,
comments may be sent to [email-masked] 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-aes-ccm-and-gcm-02.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15611&rfc_flag=0

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7SELmSe007732 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Aug 2007 07:21:48 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7SELmxw007730; Tue, 28 Aug 2007 07:21:48 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from ns1.neustar.com (ns1.neustar.com [156.154.16.138]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7SELlhW007724 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 28 Aug 2007 07:21:48 -0700 (MST) (envelope-from [email-masked])
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id BA6D326E6D; Tue, 28 Aug 2007 14:21:46 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IQ1ww-0001wE-Lc; Tue, 28 Aug 2007 10:21:46 -0400
X-test-idtracker: no
To: IETF-Announce
From: The IESG
Subject: Last Call: draft-ietf-smime-cms-auth-enveloped (Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type) to Proposed Standard
Reply-To: [email-masked]
Cc:
Message-Id:
Date: Tue, 28 Aug 2007 10:21:46 -0400
Sender: [email-masked]
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:

- 'Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data
Content Type '
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
[email-masked] mailing lists by 2007-09-11. Exceptionally,
comments may be sent to [email-masked] 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-auth-enveloped-04.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15571&rfc_flag=0

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7P3Nlif023041 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Aug 2007 20:23:47 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7P3NlT7023040; Fri, 24 Aug 2007 20:23:47 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7P3NjgE023033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 24 Aug 2007 20:23:46 -0700 (MST) (envelope-from [email-masked])
Received: from GALATIONS (unknown [207.202.179.27]) by smtp2.pacifier.net (Postfix) with ESMTP id 3E9266A59A; Fri, 24 Aug 2007 20:23:45 -0700 (PDT)
From: "Jim Schaad"
To: "'Kemp, David P.'" ,
References: <009601c7d2c2$29b5fef0$7d21fcd0$@com> <[email-masked]> <[email-masked]> <000001c7e044$0a965210$1fc2f630$@com> <[email-masked]>
In-Reply-To:
Subject: RE: Algorithm Class Data
Date: Fri, 24 Aug 2007 20:23:44 -0700
Message-ID: <00d001c7e6c7$58177080$08465180$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcfgTx74q/G8z7nOQQmMDWY3OLmIXgAt5etQAW/woFA=
Content-Language: en-us
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Dave,

Sorry about the delay, I have been out looking at grapes for the last couple
of days sending much of my time driving.

> -----Original Message-----
> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Kemp, David P.
> Sent: Friday, August 17, 2007 1:18 PM
> To: [email-masked]
> Subject: RE: Algorithm Class Data
>
>
> I'm still a bit confused. Is all this data to be put in a single
> location for:
>
> 1) people to read,
Yes this is an advantage,

> 2) the ASN.1 compiler to read and ignore, or
No, although many might do this.

> 3) the ASN.1 compiler to read and do something with (such as emitting
> diagnostic messages), without affecting bits on the wire

YES this is what we want it to do.

>
> For 1) wouldn't putting the proposed structures in ASN.1
> comments be appropriate, and have no effect on compatibility?
>
> 2) is pointless.
>
> For 3), using the example:
>
> MY-ALG-CLASS ::= CLASS {
> &id OBJECT IDENTIFIER,
> &privKeyType OPTIONAL,
> &pubKeyType,
> &pubKeyParams DEFAULT NULL,
> &sigStructure,
> &sigParams)
>
> alg-DSS MY-ALG-CLASS {id-dss, INTEGER, INTEGER, dss-params, DSS-SIG,
> NULL }
>
> only &id and &sigParams are used by the encoder/decoder to process
> SIGNED data. Is there any expectation that future ASN.1 compilers
> might
> understand enough about this class to complain if the user typed
> something bogus, like:
>
> alg-DSS MY-ALG-CLASS (id-dss, BIT STRING, IA5 STRING, rsa-params,
> ECDSA-SIG, NULL)

No the compiler cannot handle this, if you are looking at the contents of a
.asn file. There is no way for the compiler to know if this is what was
supposed to happen.

>
> If the envisioned compiler cannot assist the user with recovering
> from mistakes like this, then there is no reason to introduce
> an incompatibility. Just put comments around the structure and let
> humans contemplate its beauty.

What I hope will happen, is that compilers will emit the data and start
using it. Here are some different ways that it could be done.

1. The compiler provides the table of data along with some access
functions. This would allow for the coder to ask questions like "What
encoder should I be using for the parameters of a public key for this OID"

2. The compiler can potentially do checks and return a warning if a value
in a field is not contained in a table of values for a field.

3. The compiler could actually automatically do the decode operation in a
single function call for things like parameters without the coder having to
make additional calls.

I guess part of the question is do you think that putting a size restriction
on a field is currently reasonable. Most compilers ignore this piece of
information, but some compilers that understand constraints actually emit
code that can check this before doing an encode operation.

> Dave

Jim

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7P03snX009598 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Aug 2007 17:03:54 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7P03s0m009597; Fri, 24 Aug 2007 17:03:54 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7P03rfA009591 for ; Fri, 24 Aug 2007 17:03:53 -0700 (MST) (envelope-from [email-masked])
Received: by bosco.isi.edu (Postfix, from userid 70) id 7B254E008C; Fri, 24 Aug 2007 17:02:22 -0700 (PDT)
To: [email-masked], [email-masked]
Subject: Corrected Announcement: RFC 5035 on Enhanced Security Services (ESS) Update: Adding CertID Algorithm Agility
From: [email-masked]
Cc: [email-masked], [email-masked]
Message-Id: <[email-masked]>
Date: Fri, 24 Aug 2007 17:02:22 -0700 (PDT)
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

A new Request for Comments is now available in online RFC libraries.

RFC 5035

Title: Enhanced Security Services (ESS) Update:
Adding CertID Algorithm Agility
Author: J. Schaad
Status: Standards Track
Date: August 2007
Mailbox: [email-masked]
Pages: 17
Characters: 32674
Updates: RFC2634
See-Also:

I-D Tag: draft-ietf-smime-escertid-06.txt

URL: http://www.rfc-editor.org/rfc/rfc5035.txt

In the original Enhanced Security Services for S/MIME document (RFC
2634), a structure for cryptographically linking the certificate to
be used in validation with the signature was introduced; this
structure was hardwired to use SHA-1. This document allows for the
structure to have algorithm agility and defines a new attribute for
this purpose. [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 list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [email-masked]. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [email-masked].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [email-masked] with the message body

help: ways_to_get_rfcs. For example:

To: [email-masked]
Subject: getting rfcs

help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked]. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
[email-masked]. Please consult RFC 2223, Instructions to RFC
Authors, for further information.

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.13.5/8.13.5) with ESMTP id l7OMv9kx005672 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Aug 2007 15:57:09 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7OMv9n9005671; Fri, 24 Aug 2007 15:57:09 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7OMv6vL005663 for ; Fri, 24 Aug 2007 15:57:08 -0700 (MST) (envelope-from [email-masked])
Received: by bosco.isi.edu (Postfix, from userid 70) id 2C332E0087; Fri, 24 Aug 2007 15:55:35 -0700 (PDT)
To: [email-masked], [email-masked]
Subject: RFC 5035 on Enhanced Security Services (ESS) Update: Adding CertID Algorithm Agility
From: [email-masked]
Cc: [email-masked], [email-masked]
Message-Id: <[email-masked]>
Date: Fri, 24 Aug 2007 15:55:35 -0700 (PDT)
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

A new Request for Comments is now available in online RFC libraries.

RFC 5035

Title: Enhanced Security Services (ESS) Update:
Adding CertID Algorithm Agility
Author: J. Schaad
Status: Standards Track
Date: August 2007
Mailbox: [email-masked]
Pages: 17
Characters: 32674
Updates/Obsoletes/SeeAlso: None

I-D Tag: draft-ietf-smime-escertid-06.txt

URL: http://www.rfc-editor.org/rfc/rfc5035.txt

In the original Enhanced Security Services for S/MIME document (RFC
2634), a structure for cryptographically linking the certificate to
be used in validation with the signature was introduced; this
structure was hardwired to use SHA-1. This document allows for the
structure to have algorithm agility and defines a new attribute for
this purpose. [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 list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [email-masked]. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [email-masked].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [email-masked] with the message body

help: ways_to_get_rfcs. For example:

To: [email-masked]
Subject: getting rfcs

help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked]. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
[email-masked]. Please consult RFC 2223, Instructions to RFC
Authors, for further information.

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.13.5/8.13.5) with ESMTP id l7K55Tao070997 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 19 Aug 2007 22:05:30 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7K55TYJ070996; Sun, 19 Aug 2007 22:05:29 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from sjpexch1.corp.ad.entrust.com (dmz09.entrust.jp [218.44.241.219]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7K55SYN070989 for ; Sun, 19 Aug 2007 22:05:29 -0700 (MST) (envelope-from [email-masked])
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: Comment on draft-ietf-smime-cades-03.txt (RE: WG LC: draft-ietf-smime-cades-03.txt)
Date: Mon, 20 Aug 2007 14:05:26 +0900
Message-ID: <[email-masked]>
In-Reply-To: <008701c7d867$d1740060$0301a8c0@Wylie>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Comment on draft-ietf-smime-cades-03.txt (RE: WG LC: draft-ietf-smime-cades-03.txt)
Thread-Index: AcfYZ9D6LwekxwVsSDilN901zcnNkAKfzbnQ
From: "Kenji Urushima"
To:
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l7K55TYN070991
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Hi all,

I have two comments about Internet-Draft of CAdES
(draft-ietf-smime-cades-03.txt).

1)
This draft refers "ETSI TS 101 733 V.1.6.3"
however currently it quotes from latest
"ETSI TS 101 733 V.1.7.3 CAdES".
(e.x. 6.4.1 Archive time-stamp attribute definition)

So this I-D should refer v1.7.3.

2)
The following describes informative information about
SigningTime, ContentTimeStamp and SignatureTimeStamp comparision.

--- draft-ietf-smime-cades-03.txt [Page 99] ----
C.3.6. Signing time

Using this attribute a signer may sign over a time which is the claimed
signing time. When an ES with Time-stamp is created (CAdES-T) then
either a trusted time stamp is obtained and added to the ES or a
trusted time mark exists in an audit trail. When a verifier accepts a
signature, the two times shall be within acceptable limits.
In all cases, the claimed signing time cannot be after <<< SHOULD BE
REMOVED
the time identified by the time-stamp or time-mark. <<< SHOULD BE
REMOVED
--- draft-ietf-smime-cades-03.txt [Page 99] ----

--- draft-ietf-smime-cades-03.txt [Page 100] the last paragraph ----
C.3.6. Signing time

Also, the signing time, if present should be between <<< SHOULD BE
REMOVED
the time indicated by this time-stamp and time indicated <<< SHOULD BE
REMOVED
by the CAdES-T time-stamp. <<< SHOULD BE
REMOVED
--- draft-ietf-smime-cades-03.txt [Page 100] ----

I think above two sentenses should be removed.
Since:

- Signing time is not trustworthy time which is based on
local computer time and may gain or lose some seconds or minutes.
So such comparision is not important if timestamps are used.

- SigningTime attribute is quite common attribute which
is defined in CMS.
So adding this attribute in CAdES may easily raise
interoperability issue.

Best regards,

- Kenji URUSHIMA

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Turner, Sean P.
Sent: Tuesday, August 07, 2007 5:25 AM
To: [email-masked]
Subject: WG LC: draft-ietf-smime-cades-03.txt

This message initiates an SMIME Working Group Last Call on the document:

Title : CMS Advanced Electronic Signatures (CAdES)
Author(s) : J. Ross, et al.
Filename : draft-ietf-smime-cades-03.txt
Pages : 132
Date : 2007-8-6

This document obsoletes RFC 3126.

This document defines the format of an electronic signature that can
remain valid over long periods. This includes evidence as to its
validity even if the signer or verifying party later attempts to deny
(i.e., repudiates the validity of the signature).

The format can be considered as an extension to RFC 3852 [4] and RFC
2634 [5], where, when appropriate additional signed and unsigned
attributes have been defined.

The contents of this Informational RFC amounts to a transposition of the
ETSI TS 101 733 V.1.6.3 (CMS Advanced Electronic Signatures - CAdES)
[TS101733] and is technically equivalent to it.

A URL for this Internet-Draft is:
http://ietf.org/internet-drafts/draft-ietf-smime-cades-03.txt

The purpose of this WG Last Call is to ensure that the Working Group has
achieved consensus that the document is suitable for publication as an
Informational RFC.

Please review the document for both technical and editorial problems.
Technical issues should be discussed on this list. Editorial issues may
be sent to the document editor.

The Last Call period will end on 20 August 2006.

Upon completion of the last call, the WG chairs will take action based
upon the consensus of the WG. Possible actions include:

1) recommending to the IETF Security Area Directors
that the document, after possible editorial or
other minor changes, be considered by the IESG
for publication as an Informational RFC
(which generally involves an IETF-wide Last Call); or

2) requiring that outstanding issues be adequately
addressed prior to further action (including,
possibly, another WG Last Call).

Remember that it is our responsibility as Working Group members to
ensure the quality of our documents and of the Internet Standards
process. So, please read and comment!

spt

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7HKI4p5088171 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Aug 2007 13:18:04 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7HKI4Ta088170; Fri, 17 Aug 2007 13:18:04 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7HKI38w088161 for ; Fri, 17 Aug 2007 13:18:03 -0700 (MST) (envelope-from [email-masked])
Received: from Cerberus.missi.ncsc.mil (cerberus.missi.ncsc.mil [144.51.51.8]) by stingray.missi.ncsc.mil with SMTP id l7HKI0qm006345 for ; Fri, 17 Aug 2007 16:18:00 -0400 (EDT)
Received: from 144.51.60.33 by Cerberus.missi.ncsc.mil (InterScan VirusWall 6); Fri, 17 Aug 2007 16:18:02 -0400
Received: from EXCH.missi.ncsc.mil ([144.51.60.19]) by antigone.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.3959); Fri, 17 Aug 2007 16:18:02 -0400
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: Algorithm Class Data
Date: Fri, 17 Aug 2007 16:17:56 -0400
Message-ID:
In-Reply-To: <[email-masked]>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Algorithm Class Data
Thread-Index: AcfgTx74q/G8z7nOQQmMDWY3OLmIXgAt5etQ
References: <009601c7d2c2$29b5fef0$7d21fcd0$@com> <[email-masked]> <[email-masked]> <000001c7e044$0a965210$1fc2f630$@com> <[email-masked]>
From: "Kemp, David P."
To:
X-OriginalArrivalTime: 17 Aug 2007 20:18:02.0273 (UTC) FILETIME=[B64CE110:01C7E10B]
X-TM-AS-Product-Ver: : ISVW-6.0.0.1396-3.6.0.1039-15368000
X-TM-AS-Result: : Yes--8.366300-0-2-1
X-TM-AS-Category-Info: : 2:0.000000
X-TM-AS-MatchedID: : =?us-ascii?B?MTUwNTY3LTcwNjg5MS03MDM5?= =?us-ascii?B?MTItNzAxMjIzLTcwMTU3Ni03MDM3ODItNzA0MzQyLTcwMjI0OC03?= =?us-ascii?B?MDI2ODMtNzAwMDc5LTcwMzcyMC03MDI2MDktNzAwMzI0LTcwOTU4?= =?us-ascii?B?NC03MDU0NjEtNzExNDMyLTcwMDc1Ni03MDkyNTEtNzAyMTk2LTcw?= =?us-ascii?B?NjUzOC0xMzkwMDYtNzA0Mjg3LTcwMzgyOS0xMzkwMTAtNzA1NDQx?= =?us-ascii?B?LTcwMTYxOC03MDMxNTctNzAzNzQ3LTcwNDQyNS03MDM2NjItNzAz?= =?us-ascii?B?ODA3LTcwMTA0MC0xNDgwMzktMTQ4MDUwLTIwMDQw?=
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l7HKI38w088165
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

I'm still a bit confused. Is all this data to be put in a single
location for:

1) people to read,
2) the ASN.1 compiler to read and ignore, or
3) the ASN.1 compiler to read and do something with (such as emitting
diagnostic messages), without affecting bits on the wire

For 1) wouldn't putting the proposed structures in ASN.1
comments be appropriate, and have no effect on compatibility?

2) is pointless.

For 3), using the example:

MY-ALG-CLASS ::= CLASS {
&id OBJECT IDENTIFIER,
&privKeyType OPTIONAL,
&pubKeyType,
&pubKeyParams DEFAULT NULL,
&sigStructure,
&sigParams)

alg-DSS MY-ALG-CLASS {id-dss, INTEGER, INTEGER, dss-params, DSS-SIG,
NULL }

only &id and &sigParams are used by the encoder/decoder to process
SIGNED data. Is there any expectation that future ASN.1 compilers might
understand enough about this class to complain if the user typed
something bogus, like:

alg-DSS MY-ALG-CLASS (id-dss, BIT STRING, IA5 STRING, rsa-params,
ECDSA-SIG, NULL)

If the envisioned compiler cannot assist the user with recovering
from mistakes like this, then there is no reason to introduce
an incompatibility. Just put comments around the structure and let
humans contemplate its beauty.

Dave

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Russ Housley
Sent: Thursday, August 16, 2007 5:04 PM
To: Jim Schaad; [email-masked]
Subject: RE: Algorithm Class Data

Jim:

>I believe that this is useful independent of where tools draw the line.
>This is an advantage of putting more data into a single location for
people
>to read rather than having to go through the entire document for the
same
>data.

I've been thinking about this, and I agree. It really would help
implementors to link all of this information together with
unambiguous ASN.1, but it does lead to a compatibility problem. We
would no longer be using the same definitions as X.509. The new ones
would include this additional information to aid implementors, and
generate exactly the same bits on the wire. I'm not sure the
incompatibility is worth it.

Implementors need to speak up here? The structures proposed by Jim
would replace tables (or some other structure chosen by the
implementor). Are implementors going to embrace the approach offered by
Jim?

Russ

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7HCvMOv039708 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Aug 2007 05:57:22 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7HCvMdg039707; Fri, 17 Aug 2007 05:57:22 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [66.150.120.2]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l7HCvLK3039700 for ; Fri, 17 Aug 2007 05:57:21 -0700 (MST) (envelope-from [email-masked])
Message-Id: <[email-masked]>
Received: (qmail 26288 invoked by uid 0); 17 Aug 2007 12:57:19 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (71.241.252.247) by woodstock.binhost.com with SMTP; 17 Aug 2007 12:57:19 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Fri, 17 Aug 2007 08:56:42 -0400
To: "Jim Schaad" ,
From: Russ Housley
Subject: RE: Algorithm Class Data
In-Reply-To: <013401c7e0c0$1636eef0$42a4ccd0$@com>
References: <009601c7d2c2$29b5fef0$7d21fcd0$@com> <[email-masked]> <[email-masked]> <000001c7e044$0a965210$1fc2f630$@com> <013401c7e0c0$1636eef0$42a4ccd0$@com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Jim:

But, the same structures are important in both situations. All of
the issues you raised are visible in the definition of
AlgorithimIdentifier, which is used in many many places.

Russ

At 07:16 AM 8/17/2007, Jim Schaad wrote:
>Russ,
>
>This is one of the reasons why I have initially restricted this question to
>just the S/MIME group. I was worried about the differences with X.509 for
>certificates and wanted to address that on the PKIX list after the S/MIME
>group had made it's decision.
>
>Jim
>
> > -----Original Message-----
> > From: Russ Housley [mailto:[email-masked]]
> > Sent: Thursday, August 16, 2007 2:04 PM
> > To: Jim Schaad; [email-masked]
> > Subject: RE: Algorithm Class Data
> >
> > Jim:
> >
> > >I believe that this is useful independent of where tools draw the
> > line.
> > >This is an advantage of putting more data into a single location for
> > people
> > >to read rather than having to go through the entire document for the
> > same
> > >data.
> >
> > I've been thinking about this, and I agree. It really would help
> > implementors to link all of this information together with
> > unambiguous ASN.1, but it does lead to a compatibility problem. We
> > would no longer be using the same definitions as X.509. The new ones
> > would include this additional information to aid implementors, and
> > generate exactly the same bits on the wire. I'm not sure the
> > incompatibility is worth it.
> >
> > Implementors need to speak up here? The structures proposed by Jim
> > would replace tables (or some other structure chosen by the
> > implementor). Are implementors going to embrace the approach offered
> > by Jim?
> >
> > Russ

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7HCvLep039697 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Aug 2007 05:57:21 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7HCvLoL039696; Fri, 17 Aug 2007 05:57:21 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [66.150.120.2]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l7HCvJMt039690 for ; Fri, 17 Aug 2007 05:57:20 -0700 (MST) (envelope-from [email-masked])
Message-Id: <[email-masked]>
Received: (qmail 26255 invoked by uid 0); 17 Aug 2007 12:57:17 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (71.241.252.247) by woodstock.binhost.com with SMTP; 17 Aug 2007 12:57:17 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Fri, 17 Aug 2007 08:21:12 -0400
To: "Turner, Sean P." , "'Jim Schaad'" ,
From: Russ Housley
Subject: RE: Algorithm Class Data
In-Reply-To: <003a01c7e074$43ac1e10$0301a8c0@Wylie>
References: <009601c7d2c2$29b5fef0$7d21fcd0$@com> <[email-masked]> <[email-masked]> <000001c7e044$0a965210$1fc2f630$@com> <[email-masked]> <003a01c7e074$43ac1e10$0301a8c0@Wylie>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Yes. The suggestion that Jim made is equally viable in PKIX.

At 10:13 PM 8/16/2007, Turner, Sean P. wrote:
>Should the implementer net be wider that just SMIME?
>
> >-----Original Message-----
> >From: [email-masked]
> >[mailto:[email-masked]] On Behalf Of Russ Housley
> >Sent: Thursday, August 16, 2007 5:04 PM
> >To: Jim Schaad; [email-masked]
> >Subject: RE: Algorithm Class Data
> >
> >
> >Jim:
> >
> >>I believe that this is useful independent of where tools draw
> >the line.
> >>This is an advantage of putting more data into a single location for
> >>people to read rather than having to go through the entire
> >document for
> >>the same data.
> >
> >I've been thinking about this, and I agree. It really would
> >help implementors to link all of this information together
> >with unambiguous ASN.1, but it does lead to a compatibility
> >problem. We would no longer be using the same definitions as
> >X.509. The new ones would include this additional information
> >to aid implementors, and generate exactly the same bits on the
> >wire. I'm not sure the incompatibility is worth it.
> >
> >Implementors need to speak up here? The structures proposed
> >by Jim would replace tables (or some other structure chosen by
> >the implementor). Are implementors going to embrace the
> >approach offered by Jim?
> >
> >Russ
> >

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7HBGbrT027485 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Aug 2007 04:16:37 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7HBGb2Z027484; Fri, 17 Aug 2007 04:16:37 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.174]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7HBGZDU027477 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 17 Aug 2007 04:16:36 -0700 (MST) (envelope-from [email-masked])
Received: from GALATIONS (pool-71-111-68-193.ptldor.dsl-w.verizon.net [71.111.68.193]) by smtp4.pacifier.net (Postfix) with ESMTP id EC3126AC0D; Fri, 17 Aug 2007 04:16:34 -0700 (PDT)
From: "Jim Schaad"
To: "'Russ Housley'" ,
References: <009601c7d2c2$29b5fef0$7d21fcd0$@com> <[email-masked]> <[email-masked]> <000001c7e044$0a965210$1fc2f630$@com>
In-Reply-To:
Subject: RE: Algorithm Class Data
Date: Fri, 17 Aug 2007 04:16:40 -0700
Message-ID: <013401c7e0c0$1636eef0$42a4ccd0$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcfgSv9f4TSkMYjySNmdTHDLikP7VQAdN+4g
Content-Language: en-us
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Russ,

This is one of the reasons why I have initially restricted this question to
just the S/MIME group. I was worried about the differences with X.509 for
certificates and wanted to address that on the PKIX list after the S/MIME
group had made it's decision.

Jim

> -----Original Message-----
> From: Russ Housley [mailto:[email-masked]]
> Sent: Thursday, August 16, 2007 2:04 PM
> To: Jim Schaad; [email-masked]
> Subject: RE: Algorithm Class Data
>
> Jim:
>
> >I believe that this is useful independent of where tools draw the
> line.
> >This is an advantage of putting more data into a single location for
> people
> >to read rather than having to go through the entire document for the
> same
> >data.
>
> I've been thinking about this, and I agree. It really would help
> implementors to link all of this information together with
> unambiguous ASN.1, but it does lead to a compatibility problem. We
> would no longer be using the same definitions as X.509. The new ones
> would include this additional information to aid implementors, and
> generate exactly the same bits on the wire. I'm not sure the
> incompatibility is worth it.
>
> Implementors need to speak up here? The structures proposed by Jim
> would replace tables (or some other structure chosen by the
> implementor). Are implementors going to embrace the approach offered
> by Jim?
>
> Russ

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7H2PHlm082177 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Aug 2007 19:25:17 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7H2PHER082176; Thu, 16 Aug 2007 19:25:17 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp108.biz.mail.re2.yahoo.com (smtp108.biz.mail.re2.yahoo.com [206.190.52.47]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l7H2PFma082169 for ; Thu, 16 Aug 2007 19:25:16 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 82015 invoked from network); 17 Aug 2007 02:25:15 -0000
Received: from unknown (HELO Wylie) ([email-masked]@70.108.40.7 with login) by smtp108.biz.mail.re2.yahoo.com with SMTP; 17 Aug 2007 02:25:14 -0000
X-YMail-OSG: ktG5.WMVM1kYUQWUNjhpxAT75QyJvV5LR_0yz0ZY4jXTFbW6xmg8HKgu8TOQy4P88YnetcBxYQ--
From: "Turner, Sean P."
To: "'Russ Housley'" , "'Jim Schaad'" ,
References: <009601c7d2c2$29b5fef0$7d21fcd0$@com> <[email-masked]> <[email-masked]> <000001c7e044$0a965210$1fc2f630$@com> <[email-masked]>
Subject: RE: Algorithm Class Data
Date: Thu, 16 Aug 2007 22:13:55 -0400
Organization: IECA, Inc.
Message-ID: <003a01c7e074$43ac1e10$0301a8c0@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: <[email-masked]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138
Thread-Index: AcfgUSwW9iUNBevDRDSq3wS8UT2IsAAIwKCA
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Should the implementer net be wider that just SMIME?

>-----Original Message-----
>From: [email-masked]
>[mailto:[email-masked]] On Behalf Of Russ Housley
>Sent: Thursday, August 16, 2007 5:04 PM
>To: Jim Schaad; [email-masked]
>Subject: RE: Algorithm Class Data
>
>
>Jim:
>
>>I believe that this is useful independent of where tools draw
>the line.
>>This is an advantage of putting more data into a single location for
>>people to read rather than having to go through the entire
>document for
>>the same data.
>
>I've been thinking about this, and I agree. It really would
>help implementors to link all of this information together
>with unambiguous ASN.1, but it does lead to a compatibility
>problem. We would no longer be using the same definitions as
>X.509. The new ones would include this additional information
>to aid implementors, and generate exactly the same bits on the
>wire. I'm not sure the incompatibility is worth it.
>
>Implementors need to speak up here? The structures proposed
>by Jim would replace tables (or some other structure chosen by
>the implementor). Are implementors going to embrace the
>approach offered by Jim?
>
>Russ
>

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7GLIXtM055082 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Aug 2007 14:18:33 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7GLIXRT055081; Thu, 16 Aug 2007 14:18:33 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [66.150.120.2]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l7GLIVr4055067 for ; Thu, 16 Aug 2007 14:18:32 -0700 (MST) (envelope-from [email-masked])
Message-Id: <[email-masked]>
Received: (qmail 3573 invoked by uid 0); 16 Aug 2007 21:18:22 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (71.241.252.247) by woodstock.binhost.com with SMTP; 16 Aug 2007 21:18:22 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Thu, 16 Aug 2007 17:03:53 -0400
To: "Jim Schaad" , [email-masked]
From: Russ Housley
Subject: RE: Algorithm Class Data
In-Reply-To: <000001c7e044$0a965210$1fc2f630$@com>
References: <009601c7d2c2$29b5fef0$7d21fcd0$@com> <[email-masked]> <[email-masked]> <000001c7e044$0a965210$1fc2f630$@com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Jim:

>I believe that this is useful independent of where tools draw the line.
>This is an advantage of putting more data into a single location for people
>to read rather than having to go through the entire document for the same
>data.

I've been thinking about this, and I agree. It really would help
implementors to link all of this information together with
unambiguous ASN.1, but it does lead to a compatibility problem. We
would no longer be using the same definitions as X.509. The new ones
would include this additional information to aid implementors, and
generate exactly the same bits on the wire. I'm not sure the
incompatibility is worth it.

Implementors need to speak up here? The structures proposed by Jim
would replace tables (or some other structure chosen by the
implementor). Are implementors going to embrace the approach offered by Jim?

Russ

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7GKSjLr050818 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Aug 2007 13:28:45 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7GKSjSv050817; Thu, 16 Aug 2007 13:28:45 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.174]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7GKShxS050802 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 16 Aug 2007 13:28:44 -0700 (MST) (envelope-from [email-masked])
Received: from GALATIONS (ip67-88-206-98.z206-88-67.customer.algx.net [67.88.206.98]) by smtp4.pacifier.net (Postfix) with ESMTP id 028DE6A5B4; Thu, 16 Aug 2007 13:28:34 -0700 (PDT)
From: "Jim Schaad"
To: "'Russ Housley'" , "'Paul Hoffman'" ,
References: <009601c7d2c2$29b5fef0$7d21fcd0$@com> <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
Subject: RE: Algorithm Class Data
Date: Thu, 16 Aug 2007 13:28:36 -0700
Message-ID: <000001c7e044$0a965210$1fc2f630$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcfcMSVCBgE1ktMpRZu91G5EGI3jLQDvGkQw
Content-Language: en-us
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Russ,

> -----Original Message-----
> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Russ Housley
> Sent: Saturday, August 11, 2007 8:00 AM
> To: Paul Hoffman; Jim Schaad; [email-masked]
> Subject: Re: Algorithm Class Data
>
>
> Jim & Paul:
>
> >>I do not see how these impact the things that go on the wire.
> >
> >That's exactly the point.
> >
> >>Maybe I have not thought about it enough, but an example would help
> >>me understand your proposal better.
> >
> >The idea is to have more programmatic logic in the ASN.1 module
> >itself, I believe. Right now, we have text in the RFC, comments in
> >the ASN.1 module, and the code-reflecting parts of the module.
> >Moving some of the first two into the latter might make
> >interoperability more likely.
>
> That is not useful unless other development tools draw the line in
> the same place, right?
>
> Russ

I believe that this is useful independent of where tools draw the line.
This is an advantage of putting more data into a single location for people
to read rather than having to go through the entire document for the same
data.

Jim

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7EMd1uI059939 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Aug 2007 15:39:01 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7EMd1o0059938; Tue, 14 Aug 2007 15:39:01 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from [165.227.249.213] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7EMcjTn059897 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Aug 2007 15:38:46 -0700 (MST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Date: Tue, 14 Aug 2007 15:38:11 -0700
To: Simon Josefsson
From: Paul Hoffman
Subject: Re: UTF8 vs. Punycode
Cc: "Timothy J. Miller" , Russ Housley , [email-masked], [email-masked], [email-masked]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

At 12:05 AM +0200 8/15/07, Simon Josefsson wrote:
>Paul Hoffman writes:
>
>> At 11:30 AM +0200 8/14/07, Simon Josefsson wrote:
>>>One risk is that the specification cannot use Unicode code points from a
>>>newer Unicode version than IDNA ToASCII supports, right now that means
>>>Unicode 3.2.
>>
>> That is not necessarily true. The current version of IDNA supports
>> Unicode version 3.2. A future version of IDNA may support later
>> versions of Unicode.
>
>I believe the assumption here is that the document would reference the
>current IDNA version. Or are you suggesting that this document should
>wait until the IDNAbis effort is done?

The former. But that does not change what I said: a later version of
IDNA that has the additional characters you were talking about could
be replaced in the spec with near-zero effort.

> >>Some IETF protocols can easily negotiate support for UTF-8 on
>>>both sides, and using UTF-8 rather than Punycode seems more robust and
>>>like better engineering to me.
>>
>> Un-normalized fails miserably when exact matching is needed, such as
>> it is in IBE.
>
>Sending UTF-8 does not preclude normalizing from happening when it is
>needed.

Ah, I misunderstood your proposal. I thought you meant "send UTF-8",
not "do some normalization that is not specified here, then send
UTF-8". It would be good if you could give your complete proposal so
people can compare them fully.

--Paul Hoffman, Director
--VPN Consortium

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7EM5o97057590 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Aug 2007 15:05:50 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7EM5om6057589; Tue, 14 Aug 2007 15:05:50 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from yxa.extundo.com (yxa.extundo.com [83.241.177.38]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7EM5l6Y057580 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 14 Aug 2007 15:05:49 -0700 (MST) (envelope-from [email-masked])
Received: from mocca.josefsson.org (yxa.extundo.com [83.241.177.38]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l7EM5fTi017024 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Aug 2007 00:05:43 +0200
From: Simon Josefsson
To: Paul Hoffman
Cc: "Timothy J. Miller" , Russ Housley , [email-masked], [email-masked], [email-masked]
Subject: Re: UTF8 vs. Punycode
References: <[email-masked]> <[email-masked]> <[email-masked]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:070814:[email-masked]::5RpFs4AcDDHVdLUd:8A5
X-Hashcash: 1:22:070814:[email-masked]::O0RMXX4eryxCHzMq:9vSB
X-Hashcash: 1:22:070814:[email-masked]::PjcRXkxXPlaanNDr:Cmab
X-Hashcash: 1:22:070814:[email-masked]::yynulBCPAuSQFNQc:E14D
X-Hashcash: 1:22:070814:[email-masked]::TsYcvi+WoHVQscx5:HDfC
X-Hashcash: 1:22:070814:[email-masked]::iQNnMH4xb61o71Wt:o/mn
Date: Wed, 15 Aug 2007 00:05:41 +0200
In-Reply-To: (Paul Hoffman's message of "Tue\, 14 Aug 2007 07\:25\:22 -0700")
Message-ID: <[email-masked]>
User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-2.3 required=4.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,SPF_PASS autolearn=ham version=3.1.1
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on yxa-iv
X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com
X-Virus-Status: Clean
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Paul Hoffman writes:

> At 11:30 AM +0200 8/14/07, Simon Josefsson wrote:
>>One risk is that the specification cannot use Unicode code points from a
>>newer Unicode version than IDNA ToASCII supports, right now that means
>>Unicode 3.2.
>
> That is not necessarily true. The current version of IDNA supports
> Unicode version 3.2. A future version of IDNA may support later
> versions of Unicode.

I believe the assumption here is that the document would reference the
current IDNA version. Or are you suggesting that this document should
wait until the IDNAbis effort is done?

>>Some IETF protocols can easily negotiate support for UTF-8 on
>>both sides, and using UTF-8 rather than Punycode seems more robust and
>>like better engineering to me.
>
> Un-normalized fails miserably when exact matching is needed, such as
> it is in IBE.

Sending UTF-8 does not preclude normalizing from happening when it is
needed.

/Simon

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7EEQDks008050 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Aug 2007 07:26:13 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7EEQDNR008049; Tue, 14 Aug 2007 07:26:13 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from [165.227.249.213] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7EEPk04008003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Aug 2007 07:25:49 -0700 (MST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Date: Tue, 14 Aug 2007 07:25:22 -0700
To: Simon Josefsson , "Timothy J. Miller"
From: Paul Hoffman
Subject: Re: UTF8 vs. Punycode
Cc: Russ Housley , [email-masked], [email-masked], [email-masked]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

At 11:30 AM +0200 8/14/07, Simon Josefsson wrote:
>One risk is that the specification cannot use Unicode code points from a
>newer Unicode version than IDNA ToASCII supports, right now that means
>Unicode 3.2.

That is not necessarily true. The current version of IDNA supports
Unicode version 3.2. A future version of IDNA may support later
versions of Unicode.

>Since some time, we have Unicode 5.0, which includes many
>important code points for a variety of languages.

Not to get into a flame-war here, but I think that "important" is a
gross overstatement. There are a few minor scripts and personal name
characters that are not included in Unicode 3.2, but there has been
essentially no public pressure on the IETF to update them.

>Newer versions of
>Unicode will be released in the future. Having to update this
>specification for every IDNA/ToUnicode release seems sub-optimal to me.

Fully agree. It is the responsibility of the IETF to make sure that
is not needed.

>I believe it is better to teach protocols how to deal with non-ASCII
>data, rather than relying on IDNA idiosyncrasies in every IETF protocol.

We disagree here, particularly for security protocols.

>The choice to remain with ASCII has been made for the DNS protocol,
>where it makes some sense due to backwards compatibility reasons, but
>that does not mean we have to make the same choice in every IETF
>protocol.

This makes no sense here. The protocol in question is representing
email addresses. The right side of an email address is a domain name.

>Some IETF protocols can easily negotiate support for UTF-8 on
>both sides, and using UTF-8 rather than Punycode seems more robust and
>like better engineering to me.

Un-normalized fails miserably when exact matching is needed, such as
it is in IBE.

--Paul Hoffman, Director
--VPN Consortium

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7E9UZem046026 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Aug 2007 02:30:35 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7E9UZF9046025; Tue, 14 Aug 2007 02:30:35 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from yxa.extundo.com (yxa.extundo.com [83.241.177.38]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7E9UVBl046014 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 14 Aug 2007 02:30:33 -0700 (MST) (envelope-from [email-masked])
Received: from mocca.josefsson.org (yxa.extundo.com [83.241.177.38]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l7E9UIvB024616 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Aug 2007 11:30:19 +0200
From: Simon Josefsson
To: "Timothy J. Miller"
Cc: Russ Housley , [email-masked], [email-masked], [email-masked]
Subject: Re: UTF8 vs. Punycode
References: <[email-masked]> <[email-masked]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:070814:[email-masked]::FeTaSnULr2uGgjo2:7ed
X-Hashcash: 1:22:070814:[email-masked]::DtDcW6jXShKJBPAQ:2TrR
X-Hashcash: 1:22:070814:[email-masked]::67YN3hyKOvjXSh6b:39Bj
X-Hashcash: 1:22:070814:[email-masked]::eqSn0JnhZ+lIo1mo:HP4b
X-Hashcash: 1:22:070814:[email-masked]::ldiv/2qR2KHyAtjK:Llbb
Date: Tue, 14 Aug 2007 11:30:17 +0200
In-Reply-To: <[email-masked]> (Timothy J. Miller's message of "Mon, 13 Aug 2007 15:30:06 -0500")
Message-ID: <[email-masked]>
User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-2.3 required=4.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,SPF_PASS autolearn=ham version=3.1.1
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on yxa-iv
X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com
X-Virus-Status: Clean
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

"Timothy J. Miller" writes:

> On Aug 13, 2007, at 2:35 PM, Russ Housley wrote:
>
>>
>> This issue was raised by my review of
>> http://www.ietf.org/internet-drafts/draft-ietf-smime-bfibecms-03.txt
>>
>> However, I think that the issue goes beyond this document. The
>> decision made here ought to set a precedent.
>
> What's the risk of *not* forcing to ASCII via punycode? Leave aside
> flaws in unicode handling routines for the moment. In the IBE
> context, a sender would derive an "incorrect" public key (more
> correctly, a different public key) and the recipient would be unable
> to decrypt the message.

One risk is that the specification cannot use Unicode code points from a
newer Unicode version than IDNA ToASCII supports, right now that means
Unicode 3.2. Since some time, we have Unicode 5.0, which includes many
important code points for a variety of languages. Newer versions of
Unicode will be released in the future. Having to update this
specification for every IDNA/ToUnicode release seems sub-optimal to me.

I believe it is better to teach protocols how to deal with non-ASCII
data, rather than relying on IDNA idiosyncrasies in every IETF protocol.

The choice to remain with ASCII has been made for the DNS protocol,
where it makes some sense due to backwards compatibility reasons, but
that does not mean we have to make the same choice in every IETF
protocol. Some IETF protocols can easily negotiate support for UTF-8 on
both sides, and using UTF-8 rather than Punycode seems more robust and
like better engineering to me.

/Simon

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7DLDQvb063318 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Aug 2007 14:13:26 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7DLDQPJ063316; Mon, 13 Aug 2007 14:13:26 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from [165.227.249.213] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7DLDKgZ063289 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Aug 2007 14:13:21 -0700 (MST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Date: Mon, 13 Aug 2007 14:12:57 -0700
To: Russ Housley , [email-masked]
From: Paul Hoffman
Subject: Re: UTF8 vs. Punycode
Cc: [email-masked]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

At 3:35 PM -0400 8/13/07, Russ Housley wrote:
>This issue was raised by my review of
>http://www.ietf.org/internet-drafts/draft-ietf-smime-bfibecms-03.txt
>
>However, I think that the issue goes beyond this document. The
>decision made here ought to set a precedent.
>
>My original comment was:
>
>>1) Section 2 defines EmailIdentitySchema as a UTF8String. The text says:
>>
>> E-mail addresses that contain non-ASCII
>> characters MUST be encoded using punycode [RFC3492].
>>
>>Therefore, the result of the encoding should always be ASCII. Why
>>is an UTF8 String needed?
>
>I think that the use of punycode in an IA5String was the correct
>approach. This approach uses the ToASCII algorithm to generate an
>ASCII string from the Unicode string. The punycode can then be
>operated on using the usual subroutines to handle copy, compare, and
>such.

Fully agree.

>The alternative is to use UTF8, which cannot be operated on using
>the usual subroutines to handle copy, compare, and such.

The last part is not really correct (there are "usual" subroutines in
all languages for copying and comparing UTF-8 strings), but it is
still much better to use Punycode-encoded domain names for
interoperability.

Using IA5String to hold the Punycode would prevent a sloppy
implementer from stuffing UTF-8 into the field. That is a good enough
reason to use it as the holder.

--Paul Hoffman, Director
--VPN Consortium

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7DKuFPK061467 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Aug 2007 13:56:15 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7DKuFqc061466; Mon, 13 Aug 2007 13:56:15 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [66.150.120.2]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l7DKuDRT061446 for ; Mon, 13 Aug 2007 13:56:14 -0700 (MST) (envelope-from [email-masked])
Message-Id: <[email-masked]>
Received: (qmail 22121 invoked by uid 0); 13 Aug 2007 20:56:07 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (71.241.252.247) by woodstock.binhost.com with SMTP; 13 Aug 2007 20:56:07 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Mon, 13 Aug 2007 16:55:44 -0400
To: "Timothy J. Miller"
From: Russ Housley
Subject: Re: UTF8 vs. Punycode
Cc: [email-masked], [email-masked], [email-masked]
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Tim:

I think that the string comparison routines are the key point. The
recipient must recognize their own email address in the recipient
info structure. This is an exact match comparison (as opposed to the
more complicated ones for sorting). If the recipient does not locate
the correct entry in the recipient info structure, then decryption is
not possible.

Russ

At 04:30 PM 8/13/2007, Timothy J. Miller wrote:

>On Aug 13, 2007, at 2:35 PM, Russ Housley wrote:
>
>>
>>This issue was raised by my review of
>>http://www.ietf.org/internet-drafts/draft-ietf-smime-bfibecms-03.txt
>>
>>However, I think that the issue goes beyond this document. The
>>decision made here ought to set a precedent.
>
>What's the risk of *not* forcing to ASCII via punycode? Leave aside
>flaws in unicode handling routines for the moment. In the IBE
>context, a sender would derive an "incorrect" public key (more
>correctly, a different public key) and the recipient would be unable
>to decrypt the message.
>
>-- Tim

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7DKVHN3058632 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Aug 2007 13:31:17 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7DKVHwN058631; Mon, 13 Aug 2007 13:31:17 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp-bedford.mitre.org (smtpproxy1.mitre.org [192.160.51.76]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7DKVFS8058615 for ; Mon, 13 Aug 2007 13:31:16 -0700 (MST) (envelope-from [email-masked])
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.12.11.20060308/8.12.11) with SMTP id l7DKVFvb022951 for ; Mon, 13 Aug 2007 16:31:15 -0400
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (Postfix) with ESMTP id 2BF45BEFB for ; Mon, 13 Aug 2007 16:31:15 -0400 (EDT)
Received: from imcfe2.MITRE.ORG (imcfe2.mitre.org [129.83.29.4]) by smtp-bedford.mitre.org (8.12.11.20060308/8.12.11) with ESMTP id l7DKVF3S022943; Mon, 13 Aug 2007 16:31:15 -0400
Received: from [72.250.4.108] ([129.83.200.194]) by imcfe2.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Aug 2007 16:31:13 -0400
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-8-423898241; protocol="application/pkcs7-signature"
Message-Id: <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
From: "Timothy J. Miller"
Subject: Re: UTF8 vs. Punycode
Date: Mon, 13 Aug 2007 15:30:06 -0500
To: Russ Housley
X-Mailer: Apple Mail (2.752.3)
X-OriginalArrivalTime: 13 Aug 2007 20:31:14.0456 (UTC) FILETIME=[E4D36980:01C7DDE8]
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

--Apple-Mail-8-423898241
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
charset=US-ASCII;
delsp=yes;
format=flowed

On Aug 13, 2007, at 2:35 PM, Russ Housley wrote:

>
> This issue was raised by my review of
> http://www.ietf.org/internet-drafts/draft-ietf-smime-bfibecms-03.txt
>
> However, I think that the issue goes beyond this document. The
> decision made here ought to set a precedent.

What's the risk of *not* forcing to ASCII via punycode? Leave aside
flaws in unicode handling routines for the moment. In the IBE
context, a sender would derive an "incorrect" public key (more
correctly, a different public key) and the recipient would be unable
to decrypt the message.

-- Tim

--Apple-Mail-8-423898241
Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-signature;
name=smime.p7s
Content-Disposition: attachment;
filename=smime.p7s

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIHUzCCA2cw
ggJPoAMCAQICAgaaMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UE
CxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmlt
YXJ5IENBLTEwHhcNMDcwMjI4MTM1MTI0WhcNMDgwODIxMTM1MTI0WjBaMRIwEAYDVQQKEwltaXRy
ZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3RtaWxsZXIxGjAYBgNVBAMT
EU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDdpUHmSTmvwH16
KCBA3uXosw5bClu9nThq5kU/869taPaoWotpX1jnucczEnSrAwgBO9Ns7PIOpCtarIIOL2pRyX7e
xHs6IqmLY+3o3ew1lNZ5gJWhAiy+DBPGrhgDXkHqFAhLho0TA+09uroEmhCZARC3XZHk3pW8/jUS
+lHzLQIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF4DAdBgNVHQ4EFgQUXClSdJbPKPEdSSFG1e6J
IelCzrswHwYDVR0jBBgwFoAUh7QPSI1iM0LBLVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYz
aHR0cDovL3d3dy5taXRyZS5vcmcvdGVjaC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1Ud
EQQVMBOBEXRtaWxsZXJAbWl0cmUub3JnMA0GCSqGSIb3DQEBBQUAA4IBAQC6kURYV/MoIAl9Un6n
KXJ63Fi7y50uR7+f729M3QU3Em+/Is0XDAQ0oFERQu9kZQx6IQt0UFyTwZfDYmjYYOJAEB/691KS
DYBOeu4mzhwASbV7qSrTiDEbFqXupCKKXk5mRD6ECC0os8WF0kEkrUJPdGblBYfjta36hSqC8fOp
gvCLE8JNJIbPr3EmbSsApo0aeXtZZk/q8VNOvM/L25Pxb4TGF9puMUZ8nBolr1obM7aaGXmyGm5A
voGeZBbsnxG9LX+pRM4AP0S5Ttl1CtKReLX7PU0OVcing9RzC02dRxL8OUz53PYqNcJ0xmiwnPec
zCCEYjocKb0dx/U9yMJnMIID5DCCAsygAwIBAgIBBTANBgkqhkiG9w0BAQUFADBaMRIwEAYDVQQK
EwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEkMCIGA1UEAxMbTUlU
UkUgQ29ycG9yYXRpb24gUm9vdCBDQS0xMB4XDTA2MDYwMzE3MTMyMloXDTEyMDYwMzE3MTMyMlow
XTESMBAGA1UEChMJbWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAl
BgNVBAMTHk1JVFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTCCASIwDQYJKoZIhvcNAQEBBQAD
ggEPADCCAQoCggEBAMjwe1ZdEIKoELdLvENnbkbO3mVD54ZX5SjxTzFxhvoqhqSJmLOp32xT7J9K
vBapJRbJv1BFdiSUN3O0q8H66nvQqwm1RYe+tTsWSO351FolGrDT9iDRtfWgH60PCKCbABLRsx3i
GnEvjOQjeAtMn1AugqQWU3PWZXYy1Grbya+NOytYvu1p60bDFSoSAn4Jojv14lUfWHl8s3kahay8
umLSQibiXdEEX8CrSkaXpOaFOuyM6+wpRw7TybO1Dk4zGAUtn0887QvsMDk6evgN2WxMprkHAGUc
JhpI1QXtkfDIl9ukdNiIoM/vdN2QC/+m6b8dA55K5UdlBa9SgRnwapkCAwEAAaOBsTCBrjASBgNV
HRMBAf8ECDAGAQH/AgECMA4GA1UdDwEB/wQEAwIBhjAdBgNVHQ4EFgQUh7QPSI1iM0LBLVEaSB7C
nrsKsa0wHwYDVR0jBBgwFoAUx3BRANhN/uQB1GiWxT2fmpf+dC8wSAYDVR0fBEEwPzA9oDugOYY3
aHR0cDovL3d3dy5taXRyZS5vcmcvdGVjaC9taWkvcGtpL3Jvb3RjYTFfbWl0cmVfb3JnLmNybDAN
BgkqhkiG9w0BAQUFAAOCAQEATW5u664p7N0iAj27Xl/akjdfkSQpaosf6cNyAHu7utCytFfY1WfR
NmvnNDGYkqI3XMFOa18SNjiNsMCH+sFQaO+oyDnPiIkEZQvlfGGrRpqIm6j//Fgz85bnf1kAM5I6
1Np7ofCnciRvp9ZB/+u+9i262tgiJPJrvBcqXmgeT9riCc3RPjxqPNmYslOvNLpIifchelJhF7nI
ge+7RkAUcTJenj8yKwK0J3+PEpgYRQ+V2C62rnjohuxPgMw/fYoNTOlh3MVl7adwyK1ahPw2a9eO
jSWglqoPTaBNeHJqRJZZ6Vi7S55+VAWCfkAqM5m3tUiVzjsp2dFcTJxnYezaoDGCAlQwggJQAgEB
MGMwXTESMBAGA1UEChMJbWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkx
JzAlBgNVBAMTHk1JVFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMQICBpowCQYFKw4DAhoFAKCC
AUcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwODEzMjAzMDA3
WjAjBgkqhkiG9w0BCQQxFgQUhFW5uU0x3SoYURHY74s4FaARiI4wcgYJKwYBBAGCNxAEMWUwYzBd
MRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUG
A1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIGmjB0BgsqhkiG9w0BCRACCzFl
oGMwXTESMBAGA1UEChMJbWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkx
JzAlBgNVBAMTHk1JVFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMQICBpowDQYJKoZIhvcNAQEB
BQAEgYDGf8glDwtgePMawonTs8pmeab8LR2Ik/q+OSi/nH+09fCkT7XI56yQTLOWL2oT5e7jLNok
PY/2RI6t0M7vt0s8byfD8FV7eV1voyc0oju+uSntZDxNETb+wgQPeuA+xKVvqW46m8BxqLIfpIGZ
58YQ7FXE1r94OmO3nvFoPQ7V6gAAAAAAAA==

--Apple-Mail-8-423898241--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7DJZG0Y048653 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Aug 2007 12:35:16 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7DJZGDj048650; Mon, 13 Aug 2007 12:35:16 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [66.150.120.2]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l7DJZDY4048632 for ; Mon, 13 Aug 2007 12:35:15 -0700 (MST) (envelope-from [email-masked])
Message-Id: <[email-masked]>
Received: (qmail 20450 invoked by uid 0); 13 Aug 2007 19:35:07 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (71.241.252.247) by woodstock.binhost.com with SMTP; 13 Aug 2007 19:35:07 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Mon, 13 Aug 2007 15:35:10 -0400
To: [email-masked]
From: Russ Housley
Subject: UTF8 vs. Punycode
Cc: [email-masked], [email-masked]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

This issue was raised by my review of
http://www.ietf.org/internet-drafts/draft-ietf-smime-bfibecms-03.txt

However, I think that the issue goes beyond this document. The
decision made here ought to set a precedent.

My original comment was:

>1) Section 2 defines EmailIdentitySchema as a UTF8String. The text says:
>
> E-mail addresses that contain non-ASCII
> characters MUST be encoded using punycode [RFC3492].
>
>Therefore, the result of the encoding should always be ASCII. Why
>is an UTF8 String needed?

I think that the use of punycode in an IA5String was the correct
approach. This approach uses the ToASCII algorithm to generate an
ASCII string from the Unicode string. The punycode can then be
operated on using the usual subroutines to handle copy, compare, and such.

The alternative is to use UTF8, which cannot be operated on using the
usual subroutines to handle copy, compare, and such.

I understand that the authors are receiving conflicting advice on
this point from Jim Schaad and myself. I have sent email to Jim to
try and understand his point of view, but Jim has not responded. The
text in the most revision of this document was updated to use UTF8,
without requiring punycode. I think this was the wrong way to
resolve this one. I would prefer to retain the use of punycode and
carry the email address in an IA5 string. The reason that I prefer
this solution is that traditional character comparison routines can be used.

What do others think?

Russ

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7DJGfXZ045873 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Aug 2007 12:16:41 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7DJGfpF045872; Mon, 13 Aug 2007 12:16:41 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [66.150.120.2]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l7DJGeA0045862 for ; Mon, 13 Aug 2007 12:16:41 -0700 (MST) (envelope-from [email-masked])
Message-Id: <[email-masked]>
Received: (qmail 30052 invoked by uid 0); 13 Aug 2007 19:16:29 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (71.241.252.247) by woodstock.binhost.com with SMTP; 13 Aug 2007 19:16:29 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Mon, 13 Aug 2007 15:16:33 -0400
To: [email-masked]
From: Russ Housley
Subject: Re: Late WG Last Call Comments: draft-ietf-smime-bfibecms-03.txt
Cc: [email-masked]
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Draft -05 was just posted.

>>I was not able to review this document before WG Last Call
>>ended. However, I do have some comments. Please treat them as
>>late WG Last Call comment or early IETF Last Call comments.
>>
>> > http://www.ietf.org/internet-drafts/draft-ietf-smime-bfibecms-03.txt
>>
>>1) Section 2 defines EmailIdentitySchema as a UTF8String. The text says:
>>
>> E-mail addresses that contain non-ASCII
>> characters MUST be encoded using punycode [RFC3492].
>>
>>Therefore, the result of the encoding should always be ASCII. Why
>>is an UTF8 String needed?
>
>I understand that the authors are receiving conflicting advice from
>Jim Schaad and myself. I have sent email to Jim to try and
>understand his point of view, but Jim has not responded. The text
>was updated to use UTF8, without requiring punycode. I think this
>was the wrong way to resolve this one. I would prefer to retain the
>use of punycode and carry the email address in an IA5 string. The
>reason that I prefer this solution is that traditional character
>comparison routines can be used.
>
>Since Jim is not engaging in the conversation, I would like to know
>what others think.

I wish others would speak up on this point. I think this is an
important topic, and I expect the decision that we make here to set a
precedent for other decisions. I'll start another thread in case
this subject line is being ignored by people that might be interested
in this topic.

>>2) There is a line-wrap problem in the ASN.1 module, which makes
>>the indenting inconsistent:
>>
>> IBECMS-module { joint-iso-itu-t(2) country(16) us(840)
>> organization(1)
>> identicrypt(114334) ibcs(1) cms(4) module(5) version(1)
>> }
>
>The fix to this one introduced another error. Please insert the
>missing space:
>s/organization(1)identicrypt(114334)/organization(1) identicrypt(114334)/

This problem has been fixed.

>>3) There are errors in the ASN.1. It does not compile! The
>>following are corrected:
>>
>> IBERecipientInfo ::= SEQUENCE {
>> cmsVersion INTEGER { v3(3) },
>> keyFetchMethod OBJECT IDENTIFIER,
>> recipientIdentity IBEIdentityInfo,
>> serverInfo SEQUENCE SIZE (1..MAX) OF
>> OIDValuePairs OPTIONAL,
>> encryptedKey EncryptedKey
>> }
>>
>> EncryptedKey ::= OCTET STRING
>>
>>If you prefer, the EncryptedKey definition could be imported from CMS.
>
>The EncryptedKey definition was added, but one of the problems in
>the IBERecipientInfo structure was not corrected. The "SIZE" key
>word is still missing, which causes the compile to fail.

The ASN.1 module now comples. Thanks.

Russ

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7DIF3Lb039135 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Aug 2007 11:15:03 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7DIF3mI039134; Mon, 13 Aug 2007 11:15:03 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from ns3.neustar.com (ns3.neustar.com [156.154.24.138]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7DIF2KX039127 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 13 Aug 2007 11:15:03 -0700 (MST) (envelope-from [email-masked])
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 2CC69175E6; Mon, 13 Aug 2007 18:15:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IKeRR-0000xH-NK; Mon, 13 Aug 2007 14:15:01 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-bfibecms-05.txt
Message-Id:
Date: Mon, 13 Aug 2007 14:15:01 -0400
Sender: [email-masked]
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-05.txt
Pages : 15
Date : 2007-8-13

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-05.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the
username "anonymous" and a password of your e-mail address. After
logging in, type "cd internet-drafts" and then
"get draft-ietf-smime-bfibecms-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
[email-masked].
In the body type:
"FILE /internet-drafts/draft-ietf-smime-bfibecms-05.txt".

NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.

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: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="[email-masked]"

Content-Type: text/plain
Content-ID: <[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-bfibecms-05.txt

--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-smime-bfibecms-05.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--OtherAccess--

--NextPart--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7BG05V0078109 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 11 Aug 2007 09:00:05 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7BG05Sw078106; Sat, 11 Aug 2007 09:00:05 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [66.150.120.2]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l7BG04Wq078092 for ; Sat, 11 Aug 2007 09:00:04 -0700 (MST) (envelope-from [email-masked])
Message-Id: <[email-masked]>
Received: (qmail 32457 invoked by uid 0); 11 Aug 2007 16:00:00 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (71.241.252.247) by woodstock.binhost.com with SMTP; 11 Aug 2007 16:00:00 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Sat, 11 Aug 2007 11:00:02 -0400
To: Paul Hoffman , "Jim Schaad" ,
From: Russ Housley
Subject: Re: Algorithm Class Data
In-Reply-To:
References: <009601c7d2c2$29b5fef0$7d21fcd0$@com> <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Jim & Paul:

>>I do not see how these impact the things that go on the wire.
>
>That's exactly the point.
>
>>Maybe I have not thought about it enough, but an example would help
>>me understand your proposal better.
>
>The idea is to have more programmatic logic in the ASN.1 module
>itself, I believe. Right now, we have text in the RFC, comments in
>the ASN.1 module, and the code-reflecting parts of the module.
>Moving some of the first two into the latter might make
>interoperability more likely.

That is not useful unless other development tools draw the line in
the same place, right?

Russ

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l780WKP9082497 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Aug 2007 17:32:20 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l780WK7N082496; Tue, 7 Aug 2007 17:32:20 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mail.voltage.com (mail.voltage.com [209.213.222.98]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l780WIaC082490 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 7 Aug 2007 17:32:19 -0700 (MST) (envelope-from [email-masked])
Received: from influenza.voltage.com (influenza.voltage.com [172.16.0.77]) by mail.voltage.com (8.13.7/8.13.7) with ESMTP id l780WXWM006319; Tue, 7 Aug 2007 17:32:33 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Late WG Last Call Comments: draft-ietf-smime-bfibecms-03.txt
Date: Tue, 7 Aug 2007 17:32:58 -0700
Message-ID: <[email-masked]>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Late WG Last Call Comments: draft-ietf-smime-bfibecms-03.txt
Thread-Index: AcfZUikSmM0k9+rETjC6qNy2Gz5pEQAAV9iA
References: <[email-masked]> <[email-masked]> <[email-masked]>
From: "Luther Martin"
To: "Blake Ramsdell" , "Mark Schertler"
Cc: "Russ Housley" , ,
X-Proofpoint-Virus-Version: vendor=fsecure engine=4.65.5502:2.3.11,1.2.37,4.0.164 definitions=2007-08-07_07:2007-08-07,2007-08-07,2007-08-07 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=3.1.0-0708060001 definitions=main-0708070141
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l780WKaB082491
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Another version will be in later this week.

> -----Original Message-----
> From: Blake Ramsdell [mailto:[email-masked]]
> Sent: Tuesday, August 07, 2007 5:21 PM
> To: Luther Martin; Mark Schertler
> Cc: Russ Housley; [email-masked]; [email-masked]
> Subject: Re: Late WG Last Call Comments:
draft-ietf-smime-bfibecms-03.txt
>
> Russ Housley wrote:
> > Draft -04 of this document came out, but many of my concerns were
not
> > addressed.
>
> Authors, where are we on this?
>
> Blake
> --
> Blake Ramsdell | Sendmail, Inc. | http://www.sendmail.com

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l780LGQ2081820 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Aug 2007 17:21:16 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l780LGlg081819; Tue, 7 Aug 2007 17:21:16 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l780LF7j081809 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 7 Aug 2007 17:21:15 -0700 (MST) (envelope-from [email-masked])
Received: from Gulfstream.local (c-24-17-217-200.hsd1.mn.comcast.net [24.17.217.200]) (authenticated bits=0) by foon.sendmail.com (Switch-3.2.5/Switch-3.2.0) with ESMTP id l780L2pR020102 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 7 Aug 2007 17:21:04 -0700
X-DKIM: Sendmail DKIM Filter v1.0.0 foon.sendmail.com l780L2pR020102
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sendmail.com; s=tls.dkim; t=1186532473; bh=yRp0+bpt0TkodB5gOFo+Jgw9bSwItcWMUXfeQf SuIgU=; h=X-DomainKeys:DomainKey-Signature:Message-ID:Date:From: User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To: Content-Type:Content-Transfer-Encoding; b=Zf95f2SHPr5maBwbXzzkdQjz P7Z1xRmeLnWPBxDiZLS+79uSTFYzL2TPwbkJLBF+WYHld0wSCq0GJP55ksb4WEdUit9 mxPxzcaDd42zFUE/Rb9IXN/pzFlzSYgYQ5pRYLGMhq3w//8byG7a8gVJWJgM2qU9z0f xy9FEtweBWEV8=
X-DomainKeys: Sendmail DomainKeys Filter v0.6.0 foon.sendmail.com l780L2pR020102
DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=RT9xvcH7be54Uom3nQlk5qX7wTkf2nUKp7XAac2Z08Cx48CKoiXCK601Vn1IQDVjh lGjMfbYobDP4X1JdR8vBWtf6370z9wwt8443BhQYGFLA7uwhE1ym+eyhi1UmxmFKhBY Wp49sKyL1LVNh3GtgKkpg9Ghv39/pg9jyZG/AAk=
Message-ID: <[email-masked]>
Date: Tue, 07 Aug 2007 17:20:52 -0700
From: Blake Ramsdell
User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728)
MIME-Version: 1.0
To: Luther Martin , Mark Schertler
CC: Russ Housley , [email-masked], [email-masked]
Subject: Re: Late WG Last Call Comments: draft-ietf-smime-bfibecms-03.txt
References: <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Russ Housley wrote:
> Draft -04 of this document came out, but many of my concerns were not
> addressed.

Authors, where are we on this?

Blake
--
Blake Ramsdell | Sendmail, Inc. | http://www.sendmail.com

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l76KZMdu045087 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Aug 2007 13:35:22 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l76KZMPM045086; Mon, 6 Aug 2007 13:35:22 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] 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.13.5/8.13.5) with SMTP id l76KZKO7045080 for ; Mon, 6 Aug 2007 13:35:21 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 61378 invoked from network); 6 Aug 2007 20:35:19 -0000
Received: from unknown (HELO Wylie) ([email-masked]@70.108.2.68 with login) by smtp103.biz.mail.re2.yahoo.com with SMTP; 6 Aug 2007 20:35:19 -0000
X-YMail-OSG: Tq4HIu4VM1lQafF3E7BCKLC2ltxthaI7FlTmRlpYd0xFSc4i3nkIensKe_0Hvk24pAEGnmj_E0sAoYkNJtVJpBmgFJUhI6XZKy4xiVrCO8poeZV24azPyAUbpvzukIA4TFnAM97JrEExVxU-
Reply-To:
From: "Turner, Sean P."
To:
Subject: WG LC: draft-ietf-smime-cades-03.txt
Date: Mon, 6 Aug 2007 16:24:40 -0400
Organization: IECA, Inc.
Message-ID: <008701c7d867$d1740060$0301a8c0@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.3138
Thread-Index: AcfYZ9D6LwekxwVsSDilN901zcnNkA==
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

This message initiates an SMIME Working Group Last Call on the document:

Title : CMS Advanced Electronic Signatures (CAdES)
Author(s) : J. Ross, et al.
Filename : draft-ietf-smime-cades-03.txt
Pages : 132
Date : 2007-8-6

This document obsoletes RFC 3126.

This document defines the format of an electronic signature that can remain
valid over long periods. This includes evidence as to its validity even if
the signer or verifying party later attempts to deny (i.e., repudiates the
validity of the signature).

The format can be considered as an extension to RFC 3852 [4] and RFC 2634
[5], where, when appropriate additional signed and unsigned attributes have
been defined.

The contents of this Informational RFC amounts to a transposition of the
ETSI TS 101 733 V.1.6.3 (CMS Advanced Electronic Signatures - CAdES)
[TS101733] and is technically equivalent to it.

A URL for this Internet-Draft is:
http://ietf.org/internet-drafts/draft-ietf-smime-cades-03.txt

The purpose of this WG Last Call is to ensure that the Working Group has
achieved consensus that the document is suitable for publication as an
Informational RFC.

Please review the document for both technical and editorial problems.
Technical issues should be discussed on this list. Editorial issues may be
sent to the document editor.

The Last Call period will end on 20 August 2006.

Upon completion of the last call, the WG chairs will take action based upon
the consensus of the WG. Possible actions include:

1) recommending to the IETF Security Area Directors
that the document, after possible editorial or
other minor changes, be considered by the IESG
for publication as an Informational RFC
(which generally involves an IETF-wide Last Call); or

2) requiring that outstanding issues be adequately
addressed prior to further action (including,
possibly, another WG Last Call).

Remember that it is our responsibility as Working Group members to ensure
the quality of our documents and of the Internet Standards process. So,
please read and comment!

spt

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l76IF4We034603 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Aug 2007 11:15:04 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l76IF4EP034602; Mon, 6 Aug 2007 11:15:04 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from ns3.neustar.com (ns3.neustar.com [156.154.24.138]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l76IF3oS034596 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 6 Aug 2007 11:15:04 -0700 (MST) (envelope-from [email-masked])
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 9C615175EC; Mon, 6 Aug 2007 18:15:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1II76c-0003xj-42; Mon, 06 Aug 2007 14:15:02 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-cades-03.txt
Message-Id:
Date: Mon, 06 Aug 2007 14:15:02 -0400
Sender: [email-masked]
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 : CMS Advanced Electronic Signatures (CAdES)
Author(s) : J. Ross, et al.
Filename : draft-ietf-smime-cades-03.txt
Pages : 132
Date : 2007-8-6

This document defines the format of an electronic signature that can
remain valid over long periods. This includes evidence as to its
validity even if the signer or verifying party later attempts to deny
(i.e., repudiates the validity of the signature).

The format can be considered as an extension to RFC 3852 [4] and
RFC 2634 [5], where, when appropriate additional signed and
unsigned attributes have been defined.

The contents of this Informational RFC amounts to a
transposition of the ETSI TS 101 733 V.1.6.3 (CMS Advanced
Electronic Signatures - CAdES) [TS101733] and is technically
equivalent to it.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-cades-03.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the
username "anonymous" and a password of your e-mail address. After
logging in, type "cd internet-drafts" and then
"get draft-ietf-smime-cades-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
[email-masked].
In the body type:
"FILE /internet-drafts/draft-ietf-smime-cades-03.txt".

NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.

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: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="[email-masked]"

Content-Type: text/plain
Content-ID: <[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-cades-03.txt

--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-smime-cades-03.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--OtherAccess--

--NextPart--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l73Knxia054594 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Aug 2007 13:49:59 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l73Knx4Z054593; Fri, 3 Aug 2007 13:49:59 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from kraid.nerim.net (smtp-105-friday.nerim.net [62.4.16.105]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l73Knvrs054580 for ; Fri, 3 Aug 2007 13:49:58 -0700 (MST) (envelope-from [email-masked])
Received: from GALATIONS (louvremontana.pck.nerim.net [213.41.176.68]) by kraid.nerim.net (Postfix) with ESMTP id E6DF1CF0C5; Fri, 3 Aug 2007 22:49:55 +0200 (CEST)
From: "Jim Schaad"
To: "'Russ Housley'" ,
References: <009601c7d2c2$29b5fef0$7d21fcd0$@com> <[email-masked]>
In-Reply-To: <[email-masked]>
Subject: RE: Algorithm Class Data
Date: Fri, 3 Aug 2007 22:49:56 +0200
Message-ID: <000001c7d60f$da5a8f50$8f0fadf0$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcfS75fZwtOH3IJqQQeFzTB4POrkRgDANeIA
Content-Language: en-us
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Russ,

Here would be an example. (Please note - this is conceptual ASN.1 not real
ASN.1)

MY-ALG-CLASS ::= CLASS {
&id OBJECT IDENTIFIER,
&privKeyType OPTIONAL,
&pubKeyType,
&pubKeyParams DEFAULT NULL,
&sigStructure,
&sigParams)

alg-DSS MY-ALG-CLASS { id-dss, INTEGER, INTEGER, dss-params, DSS-SIG, NULL }

All of the data is not associated together in META-DATA - this does not
affect what goes out over the wires, however the information could
potentially be used in the encode/decoder with some re-writes of the data
such as

SIGNED(ToBeSigned) ::= {
toBeSigned ToBeSigned
algorithm SEQUENCE {
sigId MY-ALG-CLASS.&id({SigAlgs}),
params MY-ALG-CLASS.&sigParams ({SigAlgs}{@sigId}) OPTIONAL,
},
Signature BIT STRING (CONTAINING
MY-ALG-CLASS.&sigStructure([email-masked]}))
}

This data structure COULD be encoded/decoded directly by the ASN.1 system.

Jim

> -----Original Message-----
> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Russ Housley
> Sent: Monday, July 30, 2007 11:04 PM
> To: Jim Schaad; [email-masked]
> Subject: Re: Algorithm Class Data
>
>
> Jim:
>
> I do not see how these impact the things that go on the wire. Maybe
> I have not thought about it enough, but an example would help me
> understand your proposal better.
>
> Russ
>
>
> At 11:56 AM 7/30/2007, Jim Schaad wrote:
>
> >At the face-to-face meeting I presented the fact that Paul Hoffman and
> I are
> >currently working on a 2002 freeware ASN.1 compiler. As part of this
> work
> >we are requested to do re-writes of the core IETF ASN.1 modules to
> update
> >them. This message is looking at one portion of the update that we
> are
> >contemplating.
> >
> >
> >The current ITU definition of ALGORITHM contains just an OID and an
> open
> >type. From my point of view this seems to be missing a lot of data
> that
> >should be associated together. So the first question would be what
> >information exists that COULD be associated together. This meta data
> is
> >generally collected somewhere, but is not associated in the current
> ASN.1
> >file.
> >
> >The following information what I think could be associated. I would
> like to
> >start by seeing if this is a complete set of data that could be
> associated.
> >
> >Signature
> > OID, Parameters, Signature Value, Public Key, Private Key
> >
> >Transport Encryption
> > OID, Parameters, EncryptedKey (contents of OCTET STRING ?),
> Public Key,
> >Private Key
> >
> >Key Agree Encryption
> > OID, Parameter, EncryptedKey (contents of OCTET STRING ?), Public
> Key,
> >Private Key, OtherKeyAttributes Set
> >
> >Symmetric Key Encryption
> > OID, Parameters, S/MIME Parameters
> >
> >KEK Encryption
> > OID, Parameters, OtherKeyAttibutes Set
> >
> >Key Derivation Algorithm
> > OID, Parameters, input format?
> >
> >Digest Algorithm
> > OID, Parameters
> >
> >MAC Algorithm
> > OID, Parameters
> >
> >
> >
> >
> >Jim

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l73KnxpE054596 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Aug 2007 13:49:59 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l73KnxQR054595; Fri, 3 Aug 2007 13:49:59 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from kraid.nerim.net (smtp-105-friday.nerim.net [62.4.16.105]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l73KnvOV054581 for ; Fri, 3 Aug 2007 13:49:58 -0700 (MST) (envelope-from [email-masked])
Received: from GALATIONS (louvremontana.pck.nerim.net [213.41.176.68]) by kraid.nerim.net (Postfix) with ESMTP id 51F0ACF0CE; Fri, 3 Aug 2007 22:49:56 +0200 (CEST)
From: "Jim Schaad"
To: "'Kemp, David P.'" ,
References: <009601c7d2c2$29b5fef0$7d21fcd0$@com>
In-Reply-To:
Subject: RE: Algorithm Class Data
Date: Fri, 3 Aug 2007 22:49:56 +0200
Message-ID: <000101c7d60f$da954e60$8fbfeb20$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcfSwikpxB9ML2rdTCa4U2bCqn1VngAElp3AAMbtYdA=
Content-Language: en-us
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Dave,

What I am looking at doing the associations for is the data structures not
the data themselves. Thus for example, I have several different tables in
my system that say what the different structures are that are associated
with each algorithm OID. The ability to encode this in the ASN.1 module,
and thus potentially to have the data transferred to my program, seems to me
to be a good thing.

Jim

> -----Original Message-----
> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Kemp, David P.
> Sent: Monday, July 30, 2007 9:10 PM
> To: [email-masked]
> Subject: RE: Algorithm Class Data
>
>
> Jim,
>
> What is the purpose of "associating" information in an ASN.1 module?
> Since ASN.1 describes the syntax of (for example) a signature as
> transmitted between systems (OID, Parameters, and Signature Value),
> I'm not sure what a compiler would do with other data associated
> with a signature. The public key used to validate a signature is
> not contained in the same data object as the signature value itself
> (certificate vs. signed object), a private key might not appear
> in any ASN.1 module at all, and the data over which a signature is
> computed may be external.
>
> Since ASN.1 is not a procedural language, it's not clear how an
> association between a private key and a signature could even be
> expressed. The private key used to generate a signature is
> buried somewhere behind a PKCS#11 call.
>
> Wouldn't you want to simply associate a specific data type with
> the algorithm OID that selects it, just as an attribute OID
> selects the syntax of the attribute value?
>
> Dave
>
>
>
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Jim Schaad
> Sent: Monday, July 30, 2007 11:56 AM
> To: [email-masked]
> Subject: Algorithm Class Data
>
>
> At the face-to-face meeting I presented the fact that Paul Hoffman and
> I
> are
> currently working on a 2002 freeware ASN.1 compiler. As part of this
> work
> we are requested to do re-writes of the core IETF ASN.1 modules to
> update
> them. This message is looking at one portion of the update that we are
> contemplating.
>
>
> The current ITU definition of ALGORITHM contains just an OID and an
> open
> type. From my point of view this seems to be missing a lot of data
> that
> should be associated together. So the first question would be what
> information exists that COULD be associated together. This meta data
> is
> generally collected somewhere, but is not associated in the current
> ASN.1
> file.
>
> The following information what I think could be associated. I would
> like to
> start by seeing if this is a complete set of data that could be
> associated.
>
> Signature
> OID, Parameters, Signature Value, Public Key, Private Key
>
> Transport Encryption
> OID, Parameters, EncryptedKey (contents of OCTET STRING ?), Public
> Key,
> Private Key
>
> Key Agree Encryption
> OID, Parameter, EncryptedKey (contents of OCTET STRING ?), Public
> Key,
> Private Key, OtherKeyAttributes Set
>
> Symmetric Key Encryption
> OID, Parameters, S/MIME Parameters
>
> KEK Encryption
> OID, Parameters, OtherKeyAttibutes Set
>
> Key Derivation Algorithm
> OID, Parameters, input format?
>
> Digest Algorithm
> OID, Parameters
>
> MAC Algorithm
> OID, Parameters
>
>
>
>
> Jim
>
>