Subject: (광고) 아기의 안전! - 그린드림이 드리는 봄맞이 Event @

From: 그린드림<[email-masked]>
Date: Thu, 31 Mar 2005 19:37:44 -0500

1. 본 메일은 정보통신부 권고사항에 의거 작성한 [광고] 메일입니다.

2. 귀하의 전자 우편주소는 개방형 게시판 및 www.iloveschool.co.kr/frame/frame.asp의 url에서 취득하였으며 메일외 어떠한 개인 정보도 가지고 있지 않습니다.

3. 본 메일은 발신 전용 메일이므로 회신되지 않으며 수신 거부시에는 거부하실 메일주소를 입력후에 수신거부버턴을 눌러주세요.

Enter your email address if you don't want to receive this mail.

수신거부 메일주소 :

서울 강동구 천호동 34-1 그랜드밸리 1-402 (주)그린드림, 대표자 : 박대화

대표전화 : 02-470-2940 개인정보관리책임자 : 오수미 ([email-masked])

사업자등록번호 : 212-81-69751 , 통신판매신고번호 : 제 25-1207 호

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2UKgreF022872; Wed, 30 Mar 2005 12:42:53 -0800 (PST) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2UKgrXc022871; Wed, 30 Mar 2005 12:42:53 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2UKgqq5022864 for ; Wed, 30 Mar 2005 12:42:52 -0800 (PST) (envelope-from [email-masked])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08693; Wed, 30 Mar 2005 15:42:49 -0500 (EST)
Message-Id: <[email-masked]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-certcapa-04.txt
Date: Wed, 30 Mar 2005 15:42:49 -0500
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 : X.509 Certificate Extension for S/MIME Capabilities
Author(s) : S. Santesson
Filename : draft-ietf-smime-certcapa-04.txt
Pages : 6
Date : 2005-3-30

This document defines a certificate extension for inclusion of S/MIME
capabilities in public key certificates defined by RFC 3280.

S/MIME Capabilities provides an optional method to communicate
cryptographic capabilities of the certified subject as a complement
to use of the S/MIME Capabilities signed attribute in S/MIME messages
according to RFC 3851.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-certcapa-04.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-certcapa-04.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-certcapa-04.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-certcapa-04.txt

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

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

--OtherAccess--

--NextPart--

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j29Gvbcm093202; Wed, 9 Mar 2005 08:57:37 -0800 (PST) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j29GvbEm093201; Wed, 9 Mar 2005 08:57:37 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.174]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j29GvU7C093192 for ; Wed, 9 Mar 2005 08:57:37 -0800 (PST) (envelope-from [email-masked])
Received: from romans (wireless-130-129-135-49.ietf62.ietf.org [130.129.135.49]) by smtp4.pacifier.net (Postfix) with ESMTP id 271E06AEBE; Wed, 9 Mar 2005 08:57:24 -0800 (PST)
Reply-To:
From: "Jim Schaad"
To: "'Russ Housley'"
Cc:
Subject: RE: Change request for CMS
Date: Wed, 9 Mar 2005 10:59:41 -0600
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527
In-Reply-To: <[email-masked]>
Thread-Index: AcUXpmZnVEDB1UBySCexpW5Ix4AU+QNIrAmw
Message-Id: <[email-masked]>
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Russ,

While I agree that it might be useful, the EncryptedData object rather
intentionally does not have any key eminence in it. It does not even really
have the location for the key derivation function which is probably more
problematic that the fact that there is not a name for a password.

jim

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Russ Housley
> Sent: Saturday, February 19, 2005 7:23 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: Change request for CMS
>
>
> Jim:
>
> I have been thinking about this, and I do not think that this
> is the only place where this situation comes into play. The
> other place that I found is in EncryptedData. An identifier
> of the key needed for decryption would be helpful.
>
> So far, I have not heard from anyone except you about this
> idea. I do not want to work on it unless there is a
> constituency that agrees it ought to be done.
>
> Russ
>
>
> At 04:15 PM 1/27/2005, Jim Schaad wrote:
> >Russ,
> >
> >Yes I am just trying to name the password, I suppose that all I need
> >for such an identifier is really a UTF8String. I was just trying to
> >re-use what was already there.
> >
> >An update for this would be fine for me.
> >
> >jim
> >
> > > -----Original Message-----
> > > From: [email-masked]
> > > [mailto:[email-masked]] On Behalf Of Russ Housley
> > > Sent: Thursday, January 27, 2005 7:17 AM
> > > To: [email-masked]
> > > Cc: [email-masked]
> > > Subject: Re: Change request for CMS
> > >
> > >
> > > Jim:
> > >
> > > I can see how this helps enrollment.
> > >
> > > Aren't you trying to name the password? Assuming the password is
> > > one to one and onto with the KEK, the identifier actually names
> > > both.
> > >
> > > For a change of this size, I think that an update to the document
> > > (as opposed to the whole document) is appropriate.
> > >
> > > Russ
> > >
> > > At 03:23 PM 1/26/2005, Jim Schaad wrote:
> > > >Russ,
> > > >
> > > >Sometimes I wonder if this will ever end - the endless
> updates to
> > > >documents as we find things that seem to be lacking. Oh
> well.....
> > > >
> > > >
> > > >I find myself wanting to identify a key using the password
> > > >recipient info type in an enveloped data structure.
> Specifcally I
> > > >am
> > > sending a
> > > >enveloped data structure between a server and a client
> > > system. They do
> > > >not yet have certificates setup so that there is no way to
> > > use a public/private key pair.
> > > >They however do have an identifier/passphase setup
> between them.
> > > >It would be convient if one could place the identifier in the
> > > >PasswordRecipientInfo structure so that all of the data
> is together
> > > >rather than looking in many different places for the
> > > infomration needed.
> > > >
> > > >
> > > >I would like to change the structure to
> > > >
> > > >PasswordRecipientInfo ::= SEQUENCE {
> > > > version CMSVersion -- {v0, v1}
> > > > kekid [1] KEKIdentifier OPTIONAL, -- if present version = 1
> > > > keyDerivationAlgorithm [0]
> > > KeyyDerivationAlgorithmIdentifier OPTIONAL,
> > > > keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
> > > > encryptedKey EncryptedKey
> > > >}
> > > >
> > > >
> > > >Jim
> > >
> > >
> > >
>
>
>