Subject: [4]:

From: "Popplewell" <[email-masked]>
Date: Mon, 05 Feb 2007 01:58:44 +0000

We offer the software for downloads only. 

http://qbyqybj.oemcheckoutplace.com

To: [email-masked], [email-masked]
Subject:  RFC 5083 on Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type
From: [email-masked]
Cc: [email-masked], [email-masked]
Date: Fri, 30 Nov 2007 13:09:49 -0800 (PST)
Sender: [email-masked]

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

        RFC 5083

        Title:      Cryptographic Message Syntax (CMS)  
                    Authenticated-Enveloped-Data 
                    Content Type 
        Author:     R. Housley
        Status:     Standards Track
        Date:       November 2007
        Mailbox:    [email-masked]
        Pages:      10
        Characters: 22810
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-smime-cms-auth-enveloped-06.txt

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

This document describes an additional content type for the
Cryptographic Message Syntax (CMS).  The authenticated-enveloped-data
content type is intended for use with authenticated encryption modes.
All of the various key management techniques that are supported in
the CMS enveloped-data content type are also supported by the CMS
authenticated-enveloped-data content type.  [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

...

To: [email-masked], [email-masked]
Subject:  RFC 5084 on Using AES-CCM and AES-GCM Authenticated Encryption in the Cryptographic Message Syntax (CMS)
From: [email-masked]
Cc: [email-masked], [email-masked]
Date: Fri, 30 Nov 2007 13:09:51 -0800 (PST)
Sender: [email-masked]

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

        RFC 5084

        Title:      Using AES-CCM and AES-GCM Authenticated 
                    Encryption in the Cryptographic Message Syntax 
                    (CMS) 
        Author:     R. Housley
        Status:     Standards Track
        Date:       November 2007
        Mailbox:    [email-masked]
        Pages:      11
        Characters: 21822
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-smime-cms-aes-ccm-and-gcm-03.txt

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

This document specifies the conventions for using the AES-CCM and the
AES-GCM authenticated encryption algorithms with the Cryptographic
Message Syntax (CMS) authenticated-enveloped-data content type.  
[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

...

Cc: "Peter Gutmann" <[email-masked]>, <[email-masked]>
From: "Timothy J. Miller" <[email-masked]>
Subject: Re: S/MIME key distribution proposal
Date: Wed, 28 Nov 2007 10:23:52 -0600
To: Anders Rundgren <[email-masked]>
Sender: [email-masked]

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

On Nov 24, 2007, at 3:46 AM, Anders Rundgren wrote:

> It seems that interrogating a Web Service associated with the target
> domain (like __mail_encryption.example.com) would be fairly simple to
> get going and facilitates immediate responses.  If the acquired  
> certificate
> is issued by a known party and conforms with the mail-address, it  
> seems
> that you can automate this.  Using a TLS connection to the service you
> might even accept any e-mail certificate issuer by "reusing" the  
> trust in the
> server certificate.  For encryption purposes this should be  
> satisfactory.

Depends on your needs.  DoD encrypted S/MIME is intended for end-to- 
end message privacy.  How do you get this by reusing a web service  
TLS certificate?

In addition, how do you get by the rfc822Name matching requirements?   
As far as I know *only* Microsoft Outlook can be configured to ignore  
the required match between the recipient's email address and the  
rfc822Name extension when encrypting a message.

> Using the most current key is also a factor that were missing in Ian's
> proposal.

This is a problem for all distribution methods *except* direct end  
user to end user exchanges.  Publication *always* lags issuance, and  
often enough fails completely.

> A security implication with using DNS + a WebService is that a bad
> provider could replace your encryption key with something that would
> allow it to read incoming messages in clear.

Not just a bad provider.  This exposes the key distribution mechanism  
to DNS hijacking as well.

> 						OTOH, that is what they
> already do today 99.9% of the time.  In fact, this scheme allows an
> enterprise to add content control by performing the decryption on the
> server.  For outgoing messages I believe Outlook already supports
> some kind of message "escrow" mechanism...

If the goal is end-to-end message privacy, then server-side  
decryption is a major violation.  If you allow *either* server-side  
decryption or end-user decryption, you've just made the protocol even  
more complex than it currently is (and now you have the problem of no  
knowing the complete security profile of your S/MIME deployment--are  
messages decrypted at the server or not, who chooses, and in what  
instances?).

-- Tim

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

--Apple-Mail-4-1063986942--

Cc: [email-masked]
From: "Timothy J. Miller" <[email-masked]>
Subject: Re: S/MIME key distribution proposal
Date: Wed, 28 Nov 2007 10:13:47 -0600
To: Peter Gutmann <[email-masked]>
Sender: [email-masked]

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

On Nov 23, 2007, at 2:53 AM, Peter Gutmann wrote:

> That's *way* outside the scope of the proposal.  The point is that  
> if the user
> has an email key then chances are the MUA will already have it  
> available,
> since it needs to use it to process incoming mail.  In that case  
> it's a
> relatively trivial step to send it out in response to a "gimme your  
> key"
> request.  Things like CRLs are an entirely different matter, you go  
> to a CA
> for those (or wherever you choose to get them from).

And it may be too large to email, anyway.  DoD CRLs currently stand  
at about 120MB in the aggregate, averaging about 12MB per CA.

Everyone should be using OCSP anyway.  Do we have OCSP stapling for S/ 
MIME?

> At most I'd go for:
>
>   GETKEYS protocols addresses
>
>   protocols := SMIME, OpenPGP, ...
>   addresses := <optional email addresses to get keys for>
>
>   mesage-body = <human-readable message to say something like "Your  
> mailer
>   doesn't understand this message, please reply with your public  
> key if you
>   can">
>
> I'm not sure about the ability to include an optional email  
> address, on the
> one hand it makes things more flexible, but then you're starting to  
> bloat it
> up into a general-purpose key-server protocol, which it absolutely  
> isn't meant
> to be.  It's just a request to the MUA for the public key(s) that  
> it holds for
> the user/owner of the email address, in a manner that doesn't  
> require manual
> user processing if the MUA understands the request.

My concern would be with email address mismatches.  This is common in  
the DoD, where currently email addresses are assigned by location  
(this is changing, slowly, to permanent email addresses), but  
locations change frequently.  With the additional wrinkles of  
organizational mailboxes and XOs doing sent-on-behalf-of, the current  
RFC and implementation requirement of matching the rfc822Name  
extension with the originating email address causes us real  
significant operational pain.

In short, if you send a GETKEYS to the CO's email and the XO is  
running the MUA when it gets received, whose encryption cert should  
be returned?

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

--Apple-Mail-3-1063381986--

From: =?iso-8859-1?Q?J=F6rg_Schwenk?= <[email-masked]>
To: "'Anders Rundgren'" <[email-masked]>, "'Peter Gutmann'" <[email-masked]>, <[email-masked]>
Subject: AW: S/MIME key distribution proposal
Date: Tue, 27 Nov 2007 13:49:35 +0100
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_003A_01C830FC.58223DB0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I'd think that since email is asynchronous communication anyway, the =
delay
in the MUA's response does not matter.

Also in contrast to a DNS or Web Service based solution, you will reach =
the
only entity that EXACTLY knows where the certificate is from only by =
email.

CRLs can later be retrieved by the requesting MUA from the URL given in =
the
certificate.

J=F6rg

-----Urspr=FCngliche Nachricht-----
Von: [email-masked] =
[mailto:[email-masked]] Im
Auftrag von Anders Rundgren
Gesendet: Samstag, 24. November 2007 10:47
An: Peter Gutmann; [email-masked]
Betreff: Re: S/MIME key distribution proposal

>Conversely, if you want [email-masked]'s public key, the best way
>to get it is to go straight to the horse's mouth and ask =
[email-masked],
>or in this case a proxy, his MUA.

If MUA means mail-client this introduces a noticeable latency as well as
only working when the MUA is on-line.   This alone makes this proposal
a rather handicapped scheme IMO.

It seems that interrogating a Web Service associated with the target
domain (like __mail_encryption.example.com) would be fairly simple to
get going and facilitates immediate responses.  If the acquired =
certificate
is issued by a known party and conforms with the mail-address, it seems
that you can automate this.  Using a TLS connection to the service you
might even accept any e-mail certificate issuer by "reusing" the trust =
in
the
server certificate.  For encryption purposes this should be =
satisfactory.

Using the most current key is also a factor that were missing in Ian's
proposal.

A security implication with using DNS + a WebService is that a bad
provider could replace your encryption key with something that would
allow it to read incoming messages in clear.  OTOH, that is what they
already do today 99.9% of the time.  In fact, this scheme allows an
enterprise to add content control by performing the decryption on the
server.  For outgoing messages I believe Outlook already supports
some kind of message "escrow" mechanism...

Anders

------=_NextPart_000_003A_01C830FC.58223DB0
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_003A_01C830FC.58223DB0--

From: "Turner, Sean P." <[email-masked]>
To: <[email-masked]>
Subject: Agenda Posted
Date: Mon, 26 Nov 2007 08:43:04 -0500
Organization: IECA, Inc.
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0084_01C83008.5C449810
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

I have posted a draft agenda at:

http://www3.ietf.org/proceedings/07dec/agenda/smime.txt

spt

------=_NextPart_000_0084_01C83008.5C449810
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7036.0">
<TITLE>Agenda Posted</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P><FONT SIZE=3D2 FACE=3D"Arial">I have posted a draft agenda at:</FONT>
</P>

<P><A =
HREF=3D"http://www3.ietf.org/proceedings/07dec/agenda/smime.txt"><U><FONT=
 COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">http://www3.ietf.org/proceedings/07dec/agenda/smime.txt</F=
ONT></U></A>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">spt</FONT>
</P>

</BODY>
</HTML>
------=_NextPart_000_0084_01C83008.5C449810--

Content-class: urn:content-classes:message
Subject: R: R: TimeStampedData draft updated - please comment
Date: Mon, 26 Nov 2007 10:31:23 +0100
From: "Santoni Adriano" <[email-masked]>
To: "Russ Housley" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

So you are suggesting that in the TimeStampedData structure:

1) the 'content' field should be a MIME element (and therefore contain a MIME content-type header), 

2) the 'mimeType' field should be removed (as a consequence of the previous point).

Did I take your right?

I would not oppose to this arrangement, if it helped gathering more consensus.

My only objection is that it will require a mix of text- and BER-based processing in order to fully open and disassemble a TimeStampedData instance. This is a bit unelegant IMO (but I know it is just normal in the S/MIME field, which I was not specifically addressing btw).

Adriano

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] Per conto di Russ Housley
Inviato: venerdì 23 novembre 2007 20.41
A: Santoni Adriano
Cc: [email-masked]; [email-masked]
Oggetto: Re: R: TimeStampedData draft updated - please comment

Santoni:

Sorry for not being clear.  My comment is directed toward you, but I included the ASN.1 fragment from Denis to highlight my point.

Please take a look at RFC 3852.  You will see that content types (object identifiers) are used to identify the format of any content.  Many have been registered over the years.  If you see TimeStampedData as an addition to the CMS, then this same technique needs to be employed.  In the CMS, as I said in my earlier message, the id-data object identifier is used when the content is MIME encoded.  The MIME type is not carried in the fields of the CMS.

Russ

At 02:46 AM 11/21/2007, Santoni Adriano wrote:

>Russ,
>
>I am not sure if you were addressing your comment to me or to Denis...
>
>At any rate, I would like to point out that the syntax I am proposing 
>implies no MIME encoding at all. The data (like e.g. a patent, an 
>offer, a contract, an income statement, a device driver, a security 
>patch, a sensitive database, etc) is bundled in its native form, "as 
>is". And thus, there is no MIME header to speak of.
>That's why I have provided for a 'mimeType' field: as a hint for the 
>recipient/verifying application to guess what kind of data is carried 
>within the TimeStampedData block, and what to do with it.
>
>Adriano
>
>
>-----Messaggio originale-----
>Da: [email-masked]
>[mailto:[email-masked]] Per conto di Russ Housley
>Inviato: martedì 20 novembre 2007 22.53
>A: [email-masked]; [email-masked]
>Oggetto: Re: TimeStampedData draft updated - please comment
>
>
>In S/MIME, the id-data content type is used when the content is MIME 
>encoded.  Then, then MIME header in the content is used to determine 
>the format of the content.  Why does this suggest a different approach?
>
>Russ
>
>At 08:16 AM 11/19/2007, Denis Pinkas wrote:
>
> >Adriano,
> >
> >Thank you for this new proposal. I skimmed through it.
> >
> >It is interesting, but I fear that it is targeted to the wrong WG.
> >Since this would be an extension of CMS, this work item would rather 
> >belong to the S-MIME WG.
> >For this reason, I copy the S-MIME WG.
> >
> >In addition, some polishing would be needed.
> >
> >Rather than long words, you will find hereafter a rewriting of the
> >ASN.1 with a few explanatory comments.
> >
> >    TimeStampedData ::= SEQUENCE {
> >       version        [0] Version DEFAULT v1,
> >       fileName           UTF8String,
> >       mimeType           PrintableString,
> >       fileLocation       UTF8String OPTIONAL,
> >       -- fileLocation is only a hint.
> >       -- The file may or may not be stored at that location.
> >       content            OCTET STRING,
> >       temporalEvidences  TemporalEvidences }
> >
> >    Version  ::=  INTEGER  { v1(0) }
> >    TemporalEvidences ::= SEQUENCE (SIZE(1..MAX)) OF TemporalEvidence
> >
> >-- This structure allows multiple levels of temporal evidences.
> >
> >    TemporalEvidence ::= SEQUENCE {
> >       evidences            Evidences,
> >       certificateLists     CertificateLists  OPTIONAL
> >}
> >
> >    CertificateLists :: = SEQUENCE (SIZE(1..MAX)) OF CertificateList
> >
> >    Evidence ::= CHOICE {
> >       timeStamps     [0] SEQUENCE (SIZE(1..MAX)) OF TimeStampToken }
> >
> >-- For each level there can be one or more time-stamps tokens.
> >
> >-- Before re-time stamping a set of former time-stamp tokens,
> >-- the CRLs of the previous level of time-stamps tokens can be 
> >captured
> >-- and inserted in the data structure.
> >
> >Denis
> >
> >
> > >Hello there,
> > >
> > >here I am again with my TimeStampedData proposal.
> > >
> > >I have submitted a new draft (also attached here) that takes into
> > account some of the remarks and suggestions received so far.
> > >
> > >I have made room for additional types of temporal evidence, like
> > e.g. RFC 4998, while keeping RFC 3161 as the basis of interoperability.
> > >
> > >I would like to invite everybody involved in time-stamping and
> > archiving e-documents to comment upon it: has it improved?
> > something is missing?
> > >
> > >In particular, please state:
> > >- are you interested in this work?
> > >- do you agree to adopt it as a new PKIX work item?
> > >- are you going to use this format, once it is finished?
> > >
> > >Is anybody willing to spend a few words on this draft during the
> > IETF meeting in Vancouver (as I cannot attend myself) ?
> > >
> > >And finally, is anybody willing to invest a little time in
> > co-authoring this draft with me?
> > >
> > >Adriano
> > >Actalis S.p.A.
> > >Milano, ITALY
> > >
> > >
> > >
> > >
> > >-----Messaggio originale-----
> > >Da: [email-masked]
> > [mailto:[email-masked]] Per conto di Santoni Adriano
> > >Inviato: lunedì 3 settembre 2007 10.42
> > >A: [email-masked]
> > >Oggetto: R: R: Draft on TimeStampedData
> > >
> > >
> > >Let me summarize the issues discussed so far:
> > >
> > >1) allow EvidenceRecord (RFC 4998) in addition to TimeStampToken 
> > >(RFC
> > >3161)
> > >
> > >In principle, I have no objections as long as we do not complicate
> > things too much and do not hamper interoperability.
> > >
> > >There are at least two possible approaches to accomodate RFC 4998:
> > >
> > >   a) explicitly provide for (one) ER in the TimeStampedData
> > syntax, as an alternative to the SET OF TimeStampToken;
> > >   b) do not mention any specific standard for the "evidence", but
> > just mention RFC 3161 and RFC 4998 as two possibilities;
> > >
> > >In any case, it must be possible for the verifying application to
> > easily detect which of the two (or more) kind of "evidence" has been 
> > used in the TimeStampedData envelope under examination. If we 
> > restrict the kinds of evidence to the two above, then a extra 
> > tagging may not be necessary, as an EvidenceRecord is a SEQUENCE, 
> > while the other choice would be a SET OF. Although unelegant, it 
> > would work. On the other hand, if we do not want to restrict the 
> > kinds of evidence to the two above, then of course we should somehow 
> > add an extra tagging level, because nobody knows at this time what 
> > syntax a third kind of evidence would conform to.
> > >
> > >In any case, for the sake of interoperability, strong emphasis
> > should be given to RFC 3161 as today this is the most widely 
> > implemented type of evidence.
> > >
> > >In conclusion: I agree with allowing RFC 4998 if we do that in a
> > way that does not modify the strong emphasis on RFC 3161 and does 
> > not hamper interoperability (which must be based on supporting RFC 
> > 3161, even though certain applications may also support RFC 4998).
> > >
> > >2) filename vs. URI
> > >
> > >Some remarked that an URI (or URI Reference) would be more
> > versatile than a simple filename. That is obviously true, but it 
> > implies that the 'content' field of TimeStampedData may be empty.
> > This is not what I was addressing in my original proposal. It would 
> > not just require the 'content' field to be declared OPTIONAL: it 
> > would make interoperability very difficult to achieve unless we 
> > restrict the URI schemes to a very small subset (e.g. http:, cid:, 
> > file:, ldap:) of the myriad possibilities. In any case, it would 
> > require ages of interoperability testing. And it would make life 
> > much harder for software implementors, without much of a benefit in 
> > view. I strongly believe in keeping things simple as much as possible.
> > >
> > >3) multiple contents and RFC 4073
> > >
> > >The 'content' field in the TimeStampedData envelope is not
> > structured, in my original proposal. It is just an OCTET STRING.
> > That allows for any kind of content to be conveyed, even a 
> > ContentCollection according to RFC 4073.
> > >
> > >Another remark has been made with reference to RFC 4073: the
> > ContentWithAttributes structure, also defined in RFC 4073, could in 
> > principle be used to bundle some content with the corrisponding 
> > evidence (the goal of my draft). Although this is true, it would 
> > require definining some additional OIDs, and mandating the presence 
> > of certain Attributes tagged by those OIDs. I frankly believe the 
> > TimeStampedData structure that I am proposing is better, first 
> > because it is dedicated and second because it "implements the 
> > ContentInfo interface", so to speak. It is simpler to manage for 
> > applications already able to parse different kinds of ContentInfo 
> > envelopes (there are a great many), possibly in a recursive way.
> > >
> > >Adriano
> > >
> > >
> > >-----Messaggio originale-----
> > >Da: Young H Etheridge [mailto:[email-masked]]
> > >Inviato: venerdì 31 agosto 2007 17.48
> > >A: Santoni Adriano
> > >Cc: [email-masked]
> > >Oggetto: Re: R: Draft on TimeStampedData
> > >
> > >Adriano,
> > >
> > >To add to your thought processes:  I believe that a URI of
> > "file:///private.stuff" addresses your concern for privacy of the 
> > physical URI.  But, allowing URI in the syntax will make less 
> > private repositories, not necessarily file systems, more universally 
> > accessible.  The intent of the URI in RFC 3986 is to also allow for 
> > abstractly identifying a resource, not necessarily providing a 
> > physical resource.  In this manner the URI could then be used as an 
> > object identity in database(s).
> > >
> > >Take care,
> > >
> > >yhe
> > >
> > >Santoni Adriano wrote:
> > >> To accomodate for RFC 4998, I would propose the following syntax:
> > >>
> > >> TimeStampedData ::= SEQUENCE {
> > >>      version                 INTEGER { v1(1) },
> > >>      fileName                UTF8String,
> > >>      mimeType                PrintableString,
> > >>      content         OCTET STRING,
> > >>      evidence                Evidence
> > >> }
> > >>
> > >> Evidence ::= CHOICE {
> > >>      timeStamps              [0] SET (SIZE(1..MAX)) OF TimeStampToken,
> > >>      evidenceRecord  [1] EvidenceRecord -- according to RFC 4998 
> > >> }
> > >>
> > >> (I am not sure whether it would be better to use explicit or 
> > >> implicit
> > >> tags...)
> > >>
> > >> Regarding the idea of having an URI instead of a filename: I'd
> > prefer to think over things a little bit more, and maybe collect
> more feedback.
> > >>
> > >> In my mind, I can send a TimeStampedData envelope to business
> > partners and/or public agencies via email. If the timestamped 
> > document is a local one, which I think is a meaningful and realistic 
> > scenario, then I do not want my company's hostnames and pathnames to 
> > be included in the envelope so that the recipient can see them.
> > >>
> > >> Adriano
> > >>
> > >>
> > >>
> > >> -----Messaggio originale-----
> > >> Da: [email-masked]
> > >> [mailto:[email-masked]]
> > >> Per conto di Julien Stern
> > >> Inviato: venerdì 31 agosto 2007 13.43
> > >> A: [email-masked]
> > >> Oggetto: Re: Draft on TimeStampedData
> > >>
> > >>
> > >> On Fri, Aug 31, 2007 at 12:06:00PM +0200, Tilo Kienitz wrote:
> > >>
> > >>> Adriano,
> > >>>
> > >>>
> > >>>> After pondering on this and other remarks, I cannot help but 
> > >>>> agree with Steve.
> > >>>>
> > >>>> My original and essential goal is that of facilitating 
> > >>>> interoperability in a currently unregulated field. If we allow 
> > >>>> for several "degrees of freedom", than interoperability will be
> > hampered from the beginning.
> > >>>> So I'd better stick to RFC 3161 for now. We could include 
> > >>>> support for RFC 4998 Evidence Records later on, at the time 
> > >>>> when they become a widespread reality comparable to RFC 3161 
> > >>>> TimeStampTokens (which are widely implemented).
> > >>>>
> > >>> I would prefer to have both options: RFC 3161 and RFC 4998. For 
> > >>> our customers evidence records are a widespread reality already.
> > >>> A standardized way to put some data and their evidence record 
> > >>> into a single file would be useful.
> > >>>
> > >>
> > >> I strongly concur with this comment. Allowing the usage of ERS
> > as well as simple timestamps would allow the TimestampedData to 
> > leverage all the work of RFC 4998 regarding timestamps instead of 
> > reinventing the wheel in the future.
> > >>
> > >> Regards,
> > >>
> > >> --
> > >> Julien
> > >>
> > >>
> > >>> Kind regards
> > >>> Tilo
> > >>>
> > >>>
> > >>>
> > >>>> -----Messaggio originale-----
> > >>>> Da: Stephen Kent [mailto:[email-masked]]
> > >>>> Inviato: giovedì 30 agosto 2007 23.05
> > >>>> A: Young H Etheridge
> > >>>> Cc: Santoni Adriano; [email-masked]
> > >>>> Oggetto: Re: R: Draft on TimeStampedData
> > >>>>
> > >>>> At 4:33 PM -0400 8/30/07, Young H Etheridge wrote:
> > >>>>
> > >>>>>> ...
> > >>>>>>
> > >>>>> Agreed, w.r.t. normative vs informative.  The above quote from
> > >>>>> RFC-4998 merely underscores that this draft should also 
> > >>>>> suggest, informatively, that the choice of Timestamp should be 
> > >>>>> one that meets the normative syntax for Timestamp and not 
> > >>>>> specify that which is in RFC-3161.  Nothing gets broken by 
> > >>>>> being less restrictive and generally more informative to the community-at-large.
> > >>>>>
> > >>>> I have to disagree with your conclusion. If we require 3161
> > time stamps in an RFC of the sort Adriano proposed, then everyone 
> > can parse them if they comply with the RFC. If the RFC says "insert 
> > the time stamp from any standard you want here, and just tell us 
> > which one you used" then we have a problem. A compliant 
> > implementation can generate data structures containing time stamps 
> > that other compliant implementations cannot parse. That's the sort 
> > of interoperability problem we try to avoid in the IETF.
> > >>>>
> > >>>>
> > >>>>> My notion of resilience does not mean "more encompassing" but 
> > >>>>> that of providing the user community with choice and an 
> > >>>>> enhanced safeguard against the possibility of the weakening of an algorithm.
> > >>>>>
> > >>>> Choices can be good, but they can create interoperability
> > problems in some cases, like this one. Also, we have algorithm 
> > agility as a requirement in all of our work, so the second concern 
> > you cite does not seem to apply here.
> > >>>>
> > >>>> Steve
> > >>>>
> > >>> --
> > >>> Tilo Kienitz
> > >>> SecCommerce Informationssysteme GmbH Obenhauptstr. 5 D - 22335 
> > >>> Hamburg
> > >>> Germany                                   http://www.seccommerce.de

From: "Anders Rundgren" <[email-masked]>
To: "Peter Gutmann" <[email-masked]>, <[email-masked]>
Subject: Re: S/MIME key distribution proposal
Date: Sat, 24 Nov 2007 10:46:44 +0100
Sender: [email-masked]

>Conversely, if you want [email-masked]'s public key, the best way
>to get it is to go straight to the horse's mouth and ask [email-masked],
>or in this case a proxy, his MUA.

If MUA means mail-client this introduces a noticeable latency as well as
only working when the MUA is on-line.   This alone makes this proposal
a rather handicapped scheme IMO.

It seems that interrogating a Web Service associated with the target
domain (like __mail_encryption.example.com) would be fairly simple to
get going and facilitates immediate responses.  If the acquired certificate
is issued by a known party and conforms with the mail-address, it seems
that you can automate this.  Using a TLS connection to the service you
might even accept any e-mail certificate issuer by "reusing" the trust in the
server certificate.  For encryption purposes this should be satisfactory.

Using the most current key is also a factor that were missing in Ian's
proposal.

A security implication with using DNS + a WebService is that a bad
provider could replace your encryption key with something that would
allow it to read incoming messages in clear.  OTOH, that is what they
already do today 99.9% of the time.  In fact, this scheme allows an
enterprise to add content control by performing the decryption on the
server.  For outgoing messages I believe Outlook already supports
some kind of message "escrow" mechanism...

Anders

Date: Fri, 23 Nov 2007 14:41:28 -0500
To: "Santoni Adriano" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: R: TimeStampedData draft updated - please comment
Cc: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Santoni:

Sorry for not being clear.  My comment is directed toward you, but I 
included the ASN.1 fragment from Denis to highlight my point.

Please take a look at RFC 3852.  You will see that content types 
(object identifiers) are used to identify the format of any 
content.  Many have been registered over the years.  If you see 
TimeStampedData as an addition to the CMS, then this same technique 
needs to be employed.  In the CMS, as I said in my earlier message, 
the id-data object identifier is used when the content is MIME 
encoded.  The MIME type is not carried in the fields of the CMS.

Russ

At 02:46 AM 11/21/2007, Santoni Adriano wrote:

>Russ,
>
>I am not sure if you were addressing your comment to me or to Denis...
>
>At any rate, I would like to point out that the syntax I am 
>proposing implies no MIME encoding at all. The data (like e.g. a 
>patent, an offer, a contract, an income statement, a device driver, 
>a security patch, a sensitive database, etc) is bundled in its 
>native form, "as is". And thus, there is no MIME header to speak of. 
>That's why I have provided for a 'mimeType' field: as a hint for the 
>recipient/verifying application to guess what kind of data is 
>carried within the TimeStampedData block, and what to do with it.
>
>Adriano
>
>
>-----Messaggio originale-----
>Da: [email-masked] 
>[mailto:[email-masked]] Per conto di Russ Housley
>Inviato: martedì 20 novembre 2007 22.53
>A: [email-masked]; [email-masked]
>Oggetto: Re: TimeStampedData draft updated - please comment
>
>
>In S/MIME, the id-data content type is used when the content is MIME 
>encoded.  Then, then MIME header in the content is used to determine 
>the format of the content.  Why does this suggest a different approach?
>
>Russ
>
>At 08:16 AM 11/19/2007, Denis Pinkas wrote:
>
> >Adriano,
> >
> >Thank you for this new proposal. I skimmed through it.
> >
> >It is interesting, but I fear that it is targeted to the wrong WG.
> >Since this would be an extension of CMS, this work item would rather
> >belong to the S-MIME WG.
> >For this reason, I copy the S-MIME WG.
> >
> >In addition, some polishing would be needed.
> >
> >Rather than long words, you will find hereafter a rewriting of the
> >ASN.1 with a few explanatory comments.
> >
> >    TimeStampedData ::= SEQUENCE {
> >       version        [0] Version DEFAULT v1,
> >       fileName           UTF8String,
> >       mimeType           PrintableString,
> >       fileLocation       UTF8String OPTIONAL,
> >       -- fileLocation is only a hint.
> >       -- The file may or may not be stored at that location.
> >       content            OCTET STRING,
> >       temporalEvidences  TemporalEvidences }
> >
> >    Version  ::=  INTEGER  { v1(0) }
> >    TemporalEvidences ::= SEQUENCE (SIZE(1..MAX)) OF TemporalEvidence
> >
> >-- This structure allows multiple levels of temporal evidences.
> >
> >    TemporalEvidence ::= SEQUENCE {
> >       evidences            Evidences,
> >       certificateLists     CertificateLists  OPTIONAL
> >}
> >
> >    CertificateLists :: = SEQUENCE (SIZE(1..MAX)) OF CertificateList
> >
> >    Evidence ::= CHOICE {
> >       timeStamps     [0] SEQUENCE (SIZE(1..MAX)) OF TimeStampToken }
> >
> >-- For each level there can be one or more time-stamps tokens.
> >
> >-- Before re-time stamping a set of former time-stamp tokens,
> >-- the CRLs of the previous level of time-stamps tokens can be captured
> >-- and inserted in the data structure.
> >
> >Denis
> >
> >
> > >Hello there,
> > >
> > >here I am again with my TimeStampedData proposal.
> > >
> > >I have submitted a new draft (also attached here) that takes into
> > account some of the remarks and suggestions received so far.
> > >
> > >I have made room for additional types of temporal evidence, like
> > e.g. RFC 4998, while keeping RFC 3161 as the basis of interoperability.
> > >
> > >I would like to invite everybody involved in time-stamping and
> > archiving e-documents to comment upon it: has it improved?
> > something is missing?
> > >
> > >In particular, please state:
> > >- are you interested in this work?
> > >- do you agree to adopt it as a new PKIX work item?
> > >- are you going to use this format, once it is finished?
> > >
> > >Is anybody willing to spend a few words on this draft during the
> > IETF meeting in Vancouver (as I cannot attend myself) ?
> > >
> > >And finally, is anybody willing to invest a little time in
> > co-authoring this draft with me?
> > >
> > >Adriano
> > >Actalis S.p.A.
> > >Milano, ITALY
> > >
> > >
> > >
> > >
> > >-----Messaggio originale-----
> > >Da: [email-masked]
> > [mailto:[email-masked]] Per conto di Santoni Adriano
> > >Inviato: lunedì 3 settembre 2007 10.42
> > >A: [email-masked]
> > >Oggetto: R: R: Draft on TimeStampedData
> > >
> > >
> > >Let me summarize the issues discussed so far:
> > >
> > >1) allow EvidenceRecord (RFC 4998) in addition to TimeStampToken (RFC
> > >3161)
> > >
> > >In principle, I have no objections as long as we do not complicate
> > things too much and do not hamper interoperability.
> > >
> > >There are at least two possible approaches to accomodate RFC 4998:
> > >
> > >   a) explicitly provide for (one) ER in the TimeStampedData
> > syntax, as an alternative to the SET OF TimeStampToken;
> > >   b) do not mention any specific standard for the "evidence", but
> > just mention RFC 3161 and RFC 4998 as two possibilities;
> > >
> > >In any case, it must be possible for the verifying application to
> > easily detect which of the two (or more) kind of "evidence" has been
> > used in the TimeStampedData envelope under examination. If we restrict
> > the kinds of evidence to the two above, then a extra tagging may not
> > be necessary, as an EvidenceRecord is a SEQUENCE, while the other
> > choice would be a SET OF. Although unelegant, it would work. On the
> > other hand, if we do not want to restrict the kinds of evidence to the
> > two above, then of course we should somehow add an extra tagging
> > level, because nobody knows at this time what syntax a third kind of
> > evidence would conform to.
> > >
> > >In any case, for the sake of interoperability, strong emphasis
> > should be given to RFC 3161 as today this is the most widely
> > implemented type of evidence.
> > >
> > >In conclusion: I agree with allowing RFC 4998 if we do that in a
> > way that does not modify the strong emphasis on RFC 3161 and does not
> > hamper interoperability (which must be based on supporting RFC 3161,
> > even though certain applications may also support RFC 4998).
> > >
> > >2) filename vs. URI
> > >
> > >Some remarked that an URI (or URI Reference) would be more
> > versatile than a simple filename. That is obviously true, but it
> > implies that the 'content' field of TimeStampedData may be empty.
> > This is not what I was addressing in my original proposal. It would
> > not just require the 'content' field to be declared OPTIONAL: it would
> > make interoperability very difficult to achieve unless we restrict the
> > URI schemes to a very small subset (e.g. http:, cid:, file:, ldap:) of
> > the myriad possibilities. In any case, it would require ages of
> > interoperability testing. And it would make life much harder for
> > software implementors, without much of a benefit in view. I strongly
> > believe in keeping things simple as much as possible.
> > >
> > >3) multiple contents and RFC 4073
> > >
> > >The 'content' field in the TimeStampedData envelope is not
> > structured, in my original proposal. It is just an OCTET STRING.
> > That allows for any kind of content to be conveyed, even a
> > ContentCollection according to RFC 4073.
> > >
> > >Another remark has been made with reference to RFC 4073: the
> > ContentWithAttributes structure, also defined in RFC 4073, could in
> > principle be used to bundle some content with the corrisponding
> > evidence (the goal of my draft). Although this is true, it would
> > require definining some additional OIDs, and mandating the presence of
> > certain Attributes tagged by those OIDs. I frankly believe the
> > TimeStampedData structure that I am proposing is better, first because
> > it is dedicated and second because it "implements the ContentInfo
> > interface", so to speak. It is simpler to manage for applications
> > already able to parse different kinds of ContentInfo envelopes (there
> > are a great many), possibly in a recursive way.
> > >
> > >Adriano
> > >
> > >
> > >-----Messaggio originale-----
> > >Da: Young H Etheridge [mailto:[email-masked]]
> > >Inviato: venerdì 31 agosto 2007 17.48
> > >A: Santoni Adriano
> > >Cc: [email-masked]
> > >Oggetto: Re: R: Draft on TimeStampedData
> > >
> > >Adriano,
> > >
> > >To add to your thought processes:  I believe that a URI of
> > "file:///private.stuff" addresses your concern for privacy of the
> > physical URI.  But, allowing URI in the syntax will make less private
> > repositories, not necessarily file systems, more universally
> > accessible.  The intent of the URI in RFC 3986 is to also allow for
> > abstractly identifying a resource, not necessarily providing a
> > physical resource.  In this manner the URI could then be used as an
> > object identity in database(s).
> > >
> > >Take care,
> > >
> > >yhe
> > >
> > >Santoni Adriano wrote:
> > >> To accomodate for RFC 4998, I would propose the following syntax:
> > >>
> > >> TimeStampedData ::= SEQUENCE {
> > >>      version                 INTEGER { v1(1) },
> > >>      fileName                UTF8String,
> > >>      mimeType                PrintableString,
> > >>      content         OCTET STRING,
> > >>      evidence                Evidence
> > >> }
> > >>
> > >> Evidence ::= CHOICE {
> > >>      timeStamps              [0] SET (SIZE(1..MAX)) OF TimeStampToken,
> > >>      evidenceRecord  [1] EvidenceRecord -- according to RFC 4998 }
> > >>
> > >> (I am not sure whether it would be better to use explicit or
> > >> implicit
> > >> tags...)
> > >>
> > >> Regarding the idea of having an URI instead of a filename: I'd
> > prefer to think over things a little bit more, and maybe collect 
> more feedback.
> > >>
> > >> In my mind, I can send a TimeStampedData envelope to business
> > partners and/or public agencies via email. If the timestamped document
> > is a local one, which I think is a meaningful and realistic scenario,
> > then I do not want my company's hostnames and pathnames to be included
> > in the envelope so that the recipient can see them.
> > >>
> > >> Adriano
> > >>
> > >>
> > >>
> > >> -----Messaggio originale-----
> > >> Da: [email-masked]
> > >> [mailto:[email-masked]]
> > >> Per conto di Julien Stern
> > >> Inviato: venerdì 31 agosto 2007 13.43
> > >> A: [email-masked]
> > >> Oggetto: Re: Draft on TimeStampedData
> > >>
> > >>
> > >> On Fri, Aug 31, 2007 at 12:06:00PM +0200, Tilo Kienitz wrote:
> > >>
> > >>> Adriano,
> > >>>
> > >>>
> > >>>> After pondering on this and other remarks, I cannot help but
> > >>>> agree with Steve.
> > >>>>
> > >>>> My original and essential goal is that of facilitating
> > >>>> interoperability in a currently unregulated field. If we allow
> > >>>> for several "degrees of freedom", than interoperability will be
> > hampered from the beginning.
> > >>>> So I'd better stick to RFC 3161 for now. We could include support
> > >>>> for RFC 4998 Evidence Records later on, at the time when they
> > >>>> become a widespread reality comparable to RFC 3161
> > >>>> TimeStampTokens (which are widely implemented).
> > >>>>
> > >>> I would prefer to have both options: RFC 3161 and RFC 4998. For
> > >>> our customers evidence records are a widespread reality already.
> > >>> A standardized way to put some data and their evidence record into
> > >>> a single file would be useful.
> > >>>
> > >>
> > >> I strongly concur with this comment. Allowing the usage of ERS
> > as well as simple timestamps would allow the TimestampedData to
> > leverage all the work of RFC 4998 regarding timestamps instead of
> > reinventing the wheel in the future.
> > >>
> > >> Regards,
> > >>
> > >> --
> > >> Julien
> > >>
> > >>
> > >>> Kind regards
> > >>> Tilo
> > >>>
> > >>>
> > >>>
> > >>>> -----Messaggio originale-----
> > >>>> Da: Stephen Kent [mailto:[email-masked]]
> > >>>> Inviato: giovedì 30 agosto 2007 23.05
> > >>>> A: Young H Etheridge
> > >>>> Cc: Santoni Adriano; [email-masked]
> > >>>> Oggetto: Re: R: Draft on TimeStampedData
> > >>>>
> > >>>> At 4:33 PM -0400 8/30/07, Young H Etheridge wrote:
> > >>>>
> > >>>>>> ...
> > >>>>>>
> > >>>>> Agreed, w.r.t. normative vs informative.  The above quote from
> > >>>>> RFC-4998 merely underscores that this draft should also suggest,
> > >>>>> informatively, that the choice of Timestamp should be one that
> > >>>>> meets the normative syntax for Timestamp and not specify that
> > >>>>> which is in RFC-3161.  Nothing gets broken by being less
> > >>>>> restrictive and generally more informative to the community-at-large.
> > >>>>>
> > >>>> I have to disagree with your conclusion. If we require 3161
> > time stamps in an RFC of the sort Adriano proposed, then everyone can
> > parse them if they comply with the RFC. If the RFC says "insert the
> > time stamp from any standard you want here, and just tell us which one
> > you used" then we have a problem. A compliant implementation can
> > generate data structures containing time stamps that other compliant
> > implementations cannot parse. That's the sort of interoperability
> > problem we try to avoid in the IETF.
> > >>>>
> > >>>>
> > >>>>> My notion of resilience does not mean "more encompassing" but
> > >>>>> that of providing the user community with choice and an enhanced
> > >>>>> safeguard against the possibility of the weakening of an algorithm.
> > >>>>>
> > >>>> Choices can be good, but they can create interoperability
> > problems in some cases, like this one. Also, we have algorithm agility
> > as a requirement in all of our work, so the second concern you cite
> > does not seem to apply here.
> > >>>>
> > >>>> Steve
> > >>>>
> > >>> --
> > >>> Tilo Kienitz
> > >>> SecCommerce Informationssysteme GmbH Obenhauptstr. 5 D - 22335
> > >>> Hamburg
> > >>> Germany                                   http://www.seccommerce.de

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: S/MIME key distribution proposal
Date: Fri, 23 Nov 2007 21:53:17 +1300
Sender: [email-masked]

[Replying to several messages at once]

"Tony Capel" <[email-masked]> writes:

>and also recommended to include current CRL (especially for parties who have
>not gotten around to making them available publicly!)

That's *way* outside the scope of the proposal.  The point is that if the user
has an email key then chances are the MUA will already have it available,
since it needs to use it to process incoming mail.  In that case it's a
relatively trivial step to send it out in response to a "gimme your key"
request.  Things like CRLs are an entirely different matter, you go to a CA
for those (or wherever you choose to get them from).

Conversely, if you want [email-masked]'s public key, the best way to get it
is to go straight to the horse's moutn and ask [email-masked], or in this
case a proxy, his MUA.

Peter Sylvester <[email-masked]> writes:

>One has to think a bit what to do if a user has multiple keys, well, open the
>same dialogue as with SSL client keys for example. Should requester be able
>to send a list of trusteworthy CA DNs?

I'd prefer to avoid building an entire email-key-request protocol for this.
It's more an official record of a convenient convention, "If you get email
with a key request in the subject, respond with the public keys that you hold
for the user" (so it'd be a purely informational RFC, not a standards-track
one).  It's up to the recipient what they do with them, whether they trust
them, whether they do a CRL lookup, ...

At most I'd go for:

  GETKEYS protocols addresses

  protocols := SMIME, OpenPGP, ...
  addresses := <optional email addresses to get keys for>

  mesage-body = <human-readable message to say something like "Your mailer
  doesn't understand this message, please reply with your public key if you
  can">

I'm not sure about the ability to include an optional email address, on the
one hand it makes things more flexible, but then you're starting to bloat it
up into a general-purpose key-server protocol, which it absolutely isn't meant
to be.  It's just a request to the MUA for the public key(s) that it holds for
the user/owner of the email address, in a manner that doesn't require manual
user processing if the MUA understands the request.

(To put it another way, let's see if the basic GETKEYS gets adopted.  We can
always bloat it up in version 2 if there's a demand for it).

"Anders Rundgren" <[email-masked]> writes:

>If this is good or not depends on what you want to achieve.
>
>If the goal is establishing confidential communication between a limited
>number of parties it seems that on-line based schemes (IM, Skype) tailored
>after TLS could also be a viable alternative.

That's too complicated, I'll leave it to someone else.  The point of this is
to automate the current manual process of "Hey, could you send me your key so
we can talk", replacing the need for tedious manual processing with an
automated method.  If the MUA knows the user's key, they can send it out.  If
not they can notify the user as per the current situation (or whatever the MUA
author decides to do in response to the message).

Peter.

From: "Anders Rundgren" <[email-masked]>
To: "Peter Gutmann" <[email-masked]>, <[email-masked]>
Subject: Re: S/MIME key distribution proposal
Date: Thu, 22 Nov 2007 22:46:18 +0100
Sender: [email-masked]

If this is good or not depends on what you want to achieve.

If the goal is establishing confidential communication between a limited number of parties it seems that on-line based schemes (IM,
Skype) tailored after TLS could also be a viable alternative.   Message encryption is a PITA and doesn't really work for the
mass-market due to the absence of a working key recovery scheme.

For ordinary enterprise-messaging server-to-server encryption is the only realistic alternative in order to comply with various
information leakage and content control policies that are currently being put in place.  Massive use of end-to-end encryption is
simply not feasible no matter how useful it may appear to be.

Another fly in Ian's soup is that the US government (which is the entity who have thrown the most money on this since long dead
horse called S/MIME) so far haven't actually published their keys.  BTW, in this context it is worth mentioning that for citizens,
you rather often deal with a department rather than an officer since you typically do not know the government people that well.
The only working and [almost] established way of securely communicating with a department is through the web.

It seems that S/MIME encryption works fine for communities having strong IT support.  On the Internet it doesn't work equally well
and has also been displaced by the web.  On the Internet we primarily need to improve authentication and reducing spam.

AR

----- Original Message ----- 
From: "Peter Gutmann" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, November 22, 2007 15:50
Subject: S/MIME key distribution proposal

https://financialcryptography.com/mt/archives/000966.html

  If an email can be used to send the key (signed), then why can't an email be
  used to request a key? Imagine that we added an email convention, a little
  like those old maillist conventions, that did this:

    Subject: GETSMIME [email-masked]

  and send it off. A mailclient like Thunderbird could simply reply by
  forwarding the key. (How this is done is an exercise for the reader. If you
  can't think of 3 ways in the next 3 minutes, you need more exercise.)

Seems like a very simple, straightforward way to automate getting someone's
key for S/MIME email purposes.  Is it worth doing this as an RFC to get it
standardised in mailers?

Peter.

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: S/MIME key distribution proposal
Date: Fri, 23 Nov 2007 03:50:34 +1300
Sender: [email-masked]

https://financialcryptography.com/mt/archives/000966.html

  If an email can be used to send the key (signed), then why can't an email be
  used to request a key? Imagine that we added an email convention, a little
  like those old maillist conventions, that did this:

    Subject: GETSMIME [email-masked]

  and send it off. A mailclient like Thunderbird could simply reply by
  forwarding the key. (How this is done is an exercise for the reader. If you
  can't think of 3 ways in the next 3 minutes, you need more exercise.)

Seems like a very simple, straightforward way to automate getting someone's
key for S/MIME email purposes.  Is it worth doing this as an RFC to get it
standardised in mailers?

Peter.

Content-class: urn:content-classes:message
Subject: R: TimeStampedData draft updated - please comment
Date: Wed, 21 Nov 2007 08:46:18 +0100
From: "Santoni Adriano" <[email-masked]>
To: "Russ Housley" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Russ,

I am not sure if you were addressing your comment to me or to Denis...

At any rate, I would like to point out that the syntax I am proposing implies no MIME encoding at all. The data (like e.g. a patent, an offer, a contract, an income statement, a device driver, a security patch, a sensitive database, etc) is bundled in its native form, "as is". And thus, there is no MIME header to speak of. That's why I have provided for a 'mimeType' field: as a hint for the recipient/verifying application to guess what kind of data is carried within the TimeStampedData block, and what to do with it.

Adriano

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] Per conto di Russ Housley
Inviato: martedì 20 novembre 2007 22.53
A: [email-masked]; [email-masked]
Oggetto: Re: TimeStampedData draft updated - please comment

In S/MIME, the id-data content type is used when the content is MIME encoded.  Then, then MIME header in the content is used to determine the format of the content.  Why does this suggest a different approach?

Russ

At 08:16 AM 11/19/2007, Denis Pinkas wrote:

>Adriano,
>
>Thank you for this new proposal. I skimmed through it.
>
>It is interesting, but I fear that it is targeted to the wrong WG.
>Since this would be an extension of CMS, this work item would rather 
>belong to the S-MIME WG.
>For this reason, I copy the S-MIME WG.
>
>In addition, some polishing would be needed.
>
>Rather than long words, you will find hereafter a rewriting of the 
>ASN.1 with a few explanatory comments.
>
>    TimeStampedData ::= SEQUENCE {
>       version        [0] Version DEFAULT v1,
>       fileName           UTF8String,
>       mimeType           PrintableString,
>       fileLocation       UTF8String OPTIONAL,
>       -- fileLocation is only a hint.
>       -- The file may or may not be stored at that location.
>       content            OCTET STRING,
>       temporalEvidences  TemporalEvidences }
>
>    Version  ::=  INTEGER  { v1(0) }
>    TemporalEvidences ::= SEQUENCE (SIZE(1..MAX)) OF TemporalEvidence
>
>-- This structure allows multiple levels of temporal evidences.
>
>    TemporalEvidence ::= SEQUENCE {
>       evidences            Evidences,
>       certificateLists     CertificateLists  OPTIONAL
>}
>
>    CertificateLists :: = SEQUENCE (SIZE(1..MAX)) OF CertificateList
>
>    Evidence ::= CHOICE {
>       timeStamps     [0] SEQUENCE (SIZE(1..MAX)) OF TimeStampToken }
>
>-- For each level there can be one or more time-stamps tokens.
>
>-- Before re-time stamping a set of former time-stamp tokens,
>-- the CRLs of the previous level of time-stamps tokens can be captured
>-- and inserted in the data structure.
>
>Denis
>
>
> >Hello there,
> >
> >here I am again with my TimeStampedData proposal.
> >
> >I have submitted a new draft (also attached here) that takes into
> account some of the remarks and suggestions received so far.
> >
> >I have made room for additional types of temporal evidence, like
> e.g. RFC 4998, while keeping RFC 3161 as the basis of interoperability.
> >
> >I would like to invite everybody involved in time-stamping and
> archiving e-documents to comment upon it: has it improved? 
> something is missing?
> >
> >In particular, please state:
> >- are you interested in this work?
> >- do you agree to adopt it as a new PKIX work item?
> >- are you going to use this format, once it is finished?
> >
> >Is anybody willing to spend a few words on this draft during the
> IETF meeting in Vancouver (as I cannot attend myself) ?
> >
> >And finally, is anybody willing to invest a little time in
> co-authoring this draft with me?
> >
> >Adriano
> >Actalis S.p.A.
> >Milano, ITALY
> >
> >
> >
> >
> >-----Messaggio originale-----
> >Da: [email-masked]
> [mailto:[email-masked]] Per conto di Santoni Adriano
> >Inviato: lunedì 3 settembre 2007 10.42
> >A: [email-masked]
> >Oggetto: R: R: Draft on TimeStampedData
> >
> >
> >Let me summarize the issues discussed so far:
> >
> >1) allow EvidenceRecord (RFC 4998) in addition to TimeStampToken (RFC 
> >3161)
> >
> >In principle, I have no objections as long as we do not complicate
> things too much and do not hamper interoperability.
> >
> >There are at least two possible approaches to accomodate RFC 4998:
> >
> >   a) explicitly provide for (one) ER in the TimeStampedData
> syntax, as an alternative to the SET OF TimeStampToken;
> >   b) do not mention any specific standard for the "evidence", but
> just mention RFC 3161 and RFC 4998 as two possibilities;
> >
> >In any case, it must be possible for the verifying application to
> easily detect which of the two (or more) kind of "evidence" has been 
> used in the TimeStampedData envelope under examination. If we restrict 
> the kinds of evidence to the two above, then a extra tagging may not 
> be necessary, as an EvidenceRecord is a SEQUENCE, while the other 
> choice would be a SET OF. Although unelegant, it would work. On the 
> other hand, if we do not want to restrict the kinds of evidence to the 
> two above, then of course we should somehow add an extra tagging 
> level, because nobody knows at this time what syntax a third kind of 
> evidence would conform to.
> >
> >In any case, for the sake of interoperability, strong emphasis
> should be given to RFC 3161 as today this is the most widely 
> implemented type of evidence.
> >
> >In conclusion: I agree with allowing RFC 4998 if we do that in a
> way that does not modify the strong emphasis on RFC 3161 and does not 
> hamper interoperability (which must be based on supporting RFC 3161, 
> even though certain applications may also support RFC 4998).
> >
> >2) filename vs. URI
> >
> >Some remarked that an URI (or URI Reference) would be more
> versatile than a simple filename. That is obviously true, but it 
> implies that the 'content' field of TimeStampedData may be empty.
> This is not what I was addressing in my original proposal. It would 
> not just require the 'content' field to be declared OPTIONAL: it would 
> make interoperability very difficult to achieve unless we restrict the 
> URI schemes to a very small subset (e.g. http:, cid:, file:, ldap:) of 
> the myriad possibilities. In any case, it would require ages of 
> interoperability testing. And it would make life much harder for 
> software implementors, without much of a benefit in view. I strongly 
> believe in keeping things simple as much as possible.
> >
> >3) multiple contents and RFC 4073
> >
> >The 'content' field in the TimeStampedData envelope is not
> structured, in my original proposal. It is just an OCTET STRING. 
> That allows for any kind of content to be conveyed, even a 
> ContentCollection according to RFC 4073.
> >
> >Another remark has been made with reference to RFC 4073: the
> ContentWithAttributes structure, also defined in RFC 4073, could in 
> principle be used to bundle some content with the corrisponding 
> evidence (the goal of my draft). Although this is true, it would 
> require definining some additional OIDs, and mandating the presence of 
> certain Attributes tagged by those OIDs. I frankly believe the 
> TimeStampedData structure that I am proposing is better, first because 
> it is dedicated and second because it "implements the ContentInfo 
> interface", so to speak. It is simpler to manage for applications 
> already able to parse different kinds of ContentInfo envelopes (there 
> are a great many), possibly in a recursive way.
> >
> >Adriano
> >
> >
> >-----Messaggio originale-----
> >Da: Young H Etheridge [mailto:[email-masked]]
> >Inviato: venerdì 31 agosto 2007 17.48
> >A: Santoni Adriano
> >Cc: [email-masked]
> >Oggetto: Re: R: Draft on TimeStampedData
> >
> >Adriano,
> >
> >To add to your thought processes:  I believe that a URI of
> "file:///private.stuff" addresses your concern for privacy of the 
> physical URI.  But, allowing URI in the syntax will make less private 
> repositories, not necessarily file systems, more universally 
> accessible.  The intent of the URI in RFC 3986 is to also allow for 
> abstractly identifying a resource, not necessarily providing a 
> physical resource.  In this manner the URI could then be used as an 
> object identity in database(s).
> >
> >Take care,
> >
> >yhe
> >
> >Santoni Adriano wrote:
> >> To accomodate for RFC 4998, I would propose the following syntax:
> >>
> >> TimeStampedData ::= SEQUENCE {
> >>      version                 INTEGER { v1(1) },
> >>      fileName                UTF8String,
> >>      mimeType                PrintableString,
> >>      content         OCTET STRING,
> >>      evidence                Evidence
> >> }
> >>
> >> Evidence ::= CHOICE {
> >>      timeStamps              [0] SET (SIZE(1..MAX)) OF TimeStampToken,
> >>      evidenceRecord  [1] EvidenceRecord -- according to RFC 4998 }
> >>
> >> (I am not sure whether it would be better to use explicit or 
> >> implicit
> >> tags...)
> >>
> >> Regarding the idea of having an URI instead of a filename: I'd
> prefer to think over things a little bit more, and maybe collect more feedback.
> >>
> >> In my mind, I can send a TimeStampedData envelope to business
> partners and/or public agencies via email. If the timestamped document 
> is a local one, which I think is a meaningful and realistic scenario, 
> then I do not want my company's hostnames and pathnames to be included 
> in the envelope so that the recipient can see them.
> >>
> >> Adriano
> >>
> >>
> >>
> >> -----Messaggio originale-----
> >> Da: [email-masked] 
> >> [mailto:[email-masked]]
> >> Per conto di Julien Stern
> >> Inviato: venerdì 31 agosto 2007 13.43
> >> A: [email-masked]
> >> Oggetto: Re: Draft on TimeStampedData
> >>
> >>
> >> On Fri, Aug 31, 2007 at 12:06:00PM +0200, Tilo Kienitz wrote:
> >>
> >>> Adriano,
> >>>
> >>>
> >>>> After pondering on this and other remarks, I cannot help but 
> >>>> agree with Steve.
> >>>>
> >>>> My original and essential goal is that of facilitating 
> >>>> interoperability in a currently unregulated field. If we allow 
> >>>> for several "degrees of freedom", than interoperability will be
> hampered from the beginning.
> >>>> So I'd better stick to RFC 3161 for now. We could include support 
> >>>> for RFC 4998 Evidence Records later on, at the time when they 
> >>>> become a widespread reality comparable to RFC 3161 
> >>>> TimeStampTokens (which are widely implemented).
> >>>>
> >>> I would prefer to have both options: RFC 3161 and RFC 4998. For 
> >>> our customers evidence records are a widespread reality already.
> >>> A standardized way to put some data and their evidence record into 
> >>> a single file would be useful.
> >>>
> >>
> >> I strongly concur with this comment. Allowing the usage of ERS
> as well as simple timestamps would allow the TimestampedData to 
> leverage all the work of RFC 4998 regarding timestamps instead of 
> reinventing the wheel in the future.
> >>
> >> Regards,
> >>
> >> --
> >> Julien
> >>
> >>
> >>> Kind regards
> >>> Tilo
> >>>
> >>>
> >>>
> >>>> -----Messaggio originale-----
> >>>> Da: Stephen Kent [mailto:[email-masked]]
> >>>> Inviato: giovedì 30 agosto 2007 23.05
> >>>> A: Young H Etheridge
> >>>> Cc: Santoni Adriano; [email-masked]
> >>>> Oggetto: Re: R: Draft on TimeStampedData
> >>>>
> >>>> At 4:33 PM -0400 8/30/07, Young H Etheridge wrote:
> >>>>
> >>>>>> ...
> >>>>>>
> >>>>> Agreed, w.r.t. normative vs informative.  The above quote from
> >>>>> RFC-4998 merely underscores that this draft should also suggest, 
> >>>>> informatively, that the choice of Timestamp should be one that 
> >>>>> meets the normative syntax for Timestamp and not specify that 
> >>>>> which is in RFC-3161.  Nothing gets broken by being less 
> >>>>> restrictive and generally more informative to the community-at-large.
> >>>>>
> >>>> I have to disagree with your conclusion. If we require 3161
> time stamps in an RFC of the sort Adriano proposed, then everyone can 
> parse them if they comply with the RFC. If the RFC says "insert the 
> time stamp from any standard you want here, and just tell us which one 
> you used" then we have a problem. A compliant implementation can 
> generate data structures containing time stamps that other compliant 
> implementations cannot parse. That's the sort of interoperability 
> problem we try to avoid in the IETF.
> >>>>
> >>>>
> >>>>> My notion of resilience does not mean "more encompassing" but 
> >>>>> that of providing the user community with choice and an enhanced 
> >>>>> safeguard against the possibility of the weakening of an algorithm.
> >>>>>
> >>>> Choices can be good, but they can create interoperability
> problems in some cases, like this one. Also, we have algorithm agility 
> as a requirement in all of our work, so the second concern you cite 
> does not seem to apply here.
> >>>>
> >>>> Steve
> >>>>
> >>> --
> >>> Tilo Kienitz
> >>> SecCommerce Informationssysteme GmbH Obenhauptstr. 5 D - 22335 
> >>> Hamburg
> >>> Germany                                   http://www.seccommerce.de

Date: Tue, 20 Nov 2007 16:53:20 -0500
To: [email-masked], [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: TimeStampedData draft updated - please comment
Sender: [email-masked]

In S/MIME, the id-data content type is used when the content is MIME 
encoded.  Then, then MIME header in the content is used to determine 
the format of the content.  Why does this suggest a different approach?

Russ

At 08:16 AM 11/19/2007, Denis Pinkas wrote:

>Adriano,
>
>Thank you for this new proposal. I skimmed through it.
>
>It is interesting, but I fear that it is targeted to the wrong WG.
>Since this would be an extension of CMS, this work item
>would rather belong to the S-MIME WG.
>For this reason, I copy the S-MIME WG.
>
>In addition, some polishing would be needed.
>
>Rather than long words, you will find hereafter a rewriting of the ASN.1
>with a few explanatory comments.
>
>    TimeStampedData ::= SEQUENCE {
>       version        [0] Version DEFAULT v1,
>       fileName           UTF8String,
>       mimeType           PrintableString,
>       fileLocation       UTF8String OPTIONAL,
>       -- fileLocation is only a hint.
>       -- The file may or may not be stored at that location.
>       content            OCTET STRING,
>       temporalEvidences  TemporalEvidences
>}
>
>    Version  ::=  INTEGER  { v1(0) }
>    TemporalEvidences ::= SEQUENCE (SIZE(1..MAX)) OF TemporalEvidence
>
>-- This structure allows multiple levels of temporal evidences.
>
>    TemporalEvidence ::= SEQUENCE {
>       evidences            Evidences,
>       certificateLists     CertificateLists  OPTIONAL
>}
>
>    CertificateLists :: = SEQUENCE (SIZE(1..MAX)) OF CertificateList
>
>    Evidence ::= CHOICE {
>       timeStamps     [0] SEQUENCE (SIZE(1..MAX)) OF TimeStampToken }
>
>-- For each level there can be one or more time-stamps tokens.
>
>-- Before re-time stamping a set of former time-stamp tokens,
>-- the CRLs of the previous level of time-stamps tokens can be captured
>-- and inserted in the data structure.
>
>Denis
>
>
> >Hello there,
> >
> >here I am again with my TimeStampedData proposal.
> >
> >I have submitted a new draft (also attached here) that takes into 
> account some of the remarks and suggestions received so far.
> >
> >I have made room for additional types of temporal evidence, like 
> e.g. RFC 4998, while keeping RFC 3161 as the basis of interoperability.
> >
> >I would like to invite everybody involved in time-stamping and 
> archiving e-documents to comment upon it: has it improved? 
> something is missing?
> >
> >In particular, please state:
> >- are you interested in this work?
> >- do you agree to adopt it as a new PKIX work item?
> >- are you going to use this format, once it is finished?
> >
> >Is anybody willing to spend a few words on this draft during the 
> IETF meeting in Vancouver (as I cannot attend myself) ?
> >
> >And finally, is anybody willing to invest a little time in 
> co-authoring this draft with me?
> >
> >Adriano
> >Actalis S.p.A.
> >Milano, ITALY
> >
> >
> >
> >
> >-----Messaggio originale-----
> >Da: [email-masked] 
> [mailto:[email-masked]] Per conto di Santoni Adriano
> >Inviato: lunedì 3 settembre 2007 10.42
> >A: [email-masked]
> >Oggetto: R: R: Draft on TimeStampedData
> >
> >
> >Let me summarize the issues discussed so far:
> >
> >1) allow EvidenceRecord (RFC 4998) in addition to TimeStampToken (RFC 3161)
> >
> >In principle, I have no objections as long as we do not complicate 
> things too much and do not hamper interoperability.
> >
> >There are at least two possible approaches to accomodate RFC 4998:
> >
> >   a) explicitly provide for (one) ER in the TimeStampedData 
> syntax, as an alternative to the SET OF TimeStampToken;
> >   b) do not mention any specific standard for the "evidence", but 
> just mention RFC 3161 and RFC 4998 as two possibilities;
> >
> >In any case, it must be possible for the verifying application to 
> easily detect which of the two (or more) kind of "evidence" has 
> been used in the TimeStampedData envelope under examination. If we 
> restrict the kinds of evidence to the two above, then a extra 
> tagging may not be necessary, as an EvidenceRecord is a SEQUENCE, 
> while the other choice would be a SET OF. Although unelegant, it 
> would work. On the other hand, if we do not want to restrict the 
> kinds of evidence to the two above, then of course we should 
> somehow add an extra tagging level, because nobody knows at this 
> time what syntax a third kind of evidence would conform to.
> >
> >In any case, for the sake of interoperability, strong emphasis 
> should be given to RFC 3161 as today this is the most widely 
> implemented type of evidence.
> >
> >In conclusion: I agree with allowing RFC 4998 if we do that in a 
> way that does not modify the strong emphasis on RFC 3161 and does 
> not hamper interoperability (which must be based on supporting RFC 
> 3161, even though certain applications may also support RFC 4998).
> >
> >2) filename vs. URI
> >
> >Some remarked that an URI (or URI Reference) would be more 
> versatile than a simple filename. That is obviously true, but it 
> implies that the 'content' field of TimeStampedData may be empty. 
> This is not what I was addressing in my original proposal. It would 
> not just require the 'content' field to be declared OPTIONAL: it 
> would make interoperability very difficult to achieve unless we 
> restrict the URI schemes to a very small subset (e.g. http:, cid:, 
> file:, ldap:) of the myriad possibilities. In any case, it would 
> require ages of interoperability testing. And it would make life 
> much harder for software implementors, without much of a benefit in 
> view. I strongly believe in keeping things simple as much as possible.
> >
> >3) multiple contents and RFC 4073
> >
> >The 'content' field in the TimeStampedData envelope is not 
> structured, in my original proposal. It is just an OCTET STRING. 
> That allows for any kind of content to be conveyed, even a 
> ContentCollection according to RFC 4073.
> >
> >Another remark has been made with reference to RFC 4073: the 
> ContentWithAttributes structure, also defined in RFC 4073, could in 
> principle be used to bundle some content with the corrisponding 
> evidence (the goal of my draft). Although this is true, it would 
> require definining some additional OIDs, and mandating the presence 
> of certain Attributes tagged by those OIDs. I frankly believe the 
> TimeStampedData structure that I am proposing is better, first 
> because it is dedicated and second because it "implements the 
> ContentInfo interface", so to speak. It is simpler to manage for 
> applications already able to parse different kinds of ContentInfo 
> envelopes (there are a great many), possibly in a recursive way.
> >
> >Adriano
> >
> >
> >-----Messaggio originale-----
> >Da: Young H Etheridge [mailto:[email-masked]]
> >Inviato: venerdì 31 agosto 2007 17.48
> >A: Santoni Adriano
> >Cc: [email-masked]
> >Oggetto: Re: R: Draft on TimeStampedData
> >
> >Adriano,
> >
> >To add to your thought processes:  I believe that a URI of 
> "file:///private.stuff" addresses your concern for privacy of the 
> physical URI.  But, allowing URI in the syntax will make less 
> private repositories, not necessarily file systems, more 
> universally accessible.  The intent of the URI in RFC 3986 is to 
> also allow for abstractly identifying a resource, not necessarily 
> providing a physical resource.  In this manner the URI could then 
> be used as an object identity in database(s).
> >
> >Take care,
> >
> >yhe
> >
> >Santoni Adriano wrote:
> >> To accomodate for RFC 4998, I would propose the following syntax:
> >>
> >> TimeStampedData ::= SEQUENCE {
> >>      version                 INTEGER { v1(1) },
> >>      fileName                UTF8String,
> >>      mimeType                PrintableString,
> >>      content         OCTET STRING,
> >>      evidence                Evidence
> >> }
> >>
> >> Evidence ::= CHOICE {
> >>      timeStamps              [0] SET (SIZE(1..MAX)) OF TimeStampToken,
> >>      evidenceRecord  [1] EvidenceRecord -- according to RFC 4998
> >> }
> >>
> >> (I am not sure whether it would be better to use explicit or implicit
> >> tags...)
> >>
> >> Regarding the idea of having an URI instead of a filename: I'd 
> prefer to think over things a little bit more, and maybe collect more feedback.
> >>
> >> In my mind, I can send a TimeStampedData envelope to business 
> partners and/or public agencies via email. If the timestamped 
> document is a local one, which I think is a meaningful and 
> realistic scenario, then I do not want my company's hostnames and 
> pathnames to be included in the envelope so that the recipient can see them.
> >>
> >> Adriano
> >>
> >>
> >>
> >> -----Messaggio originale-----
> >> Da: [email-masked] [mailto:[email-masked]]
> >> Per conto di Julien Stern
> >> Inviato: venerdì 31 agosto 2007 13.43
> >> A: [email-masked]
> >> Oggetto: Re: Draft on TimeStampedData
> >>
> >>
> >> On Fri, Aug 31, 2007 at 12:06:00PM +0200, Tilo Kienitz wrote:
> >>
> >>> Adriano,
> >>>
> >>>
> >>>> After pondering on this and other remarks, I cannot help but agree
> >>>> with Steve.
> >>>>
> >>>> My original and essential goal is that of facilitating
> >>>> interoperability in a currently unregulated field. If we allow for
> >>>> several "degrees of freedom", than interoperability will be 
> hampered from the beginning.
> >>>> So I'd better stick to RFC 3161 for now. We could include support
> >>>> for RFC 4998 Evidence Records later on, at the time when they become
> >>>> a widespread reality comparable to RFC 3161 TimeStampTokens (which
> >>>> are widely implemented).
> >>>>
> >>> I would prefer to have both options: RFC 3161 and RFC 4998. For our
> >>> customers evidence records are a widespread reality already.
> >>> A standardized way to put some data and their evidence record into a
> >>> single file would be useful.
> >>>
> >>
> >> I strongly concur with this comment. Allowing the usage of ERS 
> as well as simple timestamps would allow the TimestampedData to 
> leverage all the work of RFC 4998 regarding timestamps instead of 
> reinventing the wheel in the future.
> >>
> >> Regards,
> >>
> >> --
> >> Julien
> >>
> >>
> >>> Kind regards
> >>> Tilo
> >>>
> >>>
> >>>
> >>>> -----Messaggio originale-----
> >>>> Da: Stephen Kent [mailto:[email-masked]]
> >>>> Inviato: giovedì 30 agosto 2007 23.05
> >>>> A: Young H Etheridge
> >>>> Cc: Santoni Adriano; [email-masked]
> >>>> Oggetto: Re: R: Draft on TimeStampedData
> >>>>
> >>>> At 4:33 PM -0400 8/30/07, Young H Etheridge wrote:
> >>>>
> >>>>>> ...
> >>>>>>
> >>>>> Agreed, w.r.t. normative vs informative.  The above quote from
> >>>>> RFC-4998 merely underscores that this draft should also suggest,
> >>>>> informatively, that the choice of Timestamp should be one that
> >>>>> meets the normative syntax for Timestamp and not specify that which
> >>>>> is in RFC-3161.  Nothing gets broken by being less restrictive and
> >>>>> generally more informative to the community-at-large.
> >>>>>
> >>>> I have to disagree with your conclusion. If we require 3161 
> time stamps in an RFC of the sort Adriano proposed, then everyone 
> can parse them if they comply with the RFC. If the RFC says "insert 
> the time stamp from any standard you want here, and just tell us 
> which one you used" then we have a problem. A compliant 
> implementation can generate data structures containing time stamps 
> that other compliant implementations cannot parse. That's the sort 
> of interoperability problem we try to avoid in the IETF.
> >>>>
> >>>>
> >>>>> My notion of resilience does not mean "more encompassing" but that
> >>>>> of providing the user community with choice and an enhanced
> >>>>> safeguard against the possibility of the weakening of an algorithm.
> >>>>>
> >>>> Choices can be good, but they can create interoperability 
> problems in some cases, like this one. Also, we have algorithm 
> agility as a requirement in all of our work, so the second concern 
> you cite does not seem to apply here.
> >>>>
> >>>> Steve
> >>>>
> >>> --
> >>> Tilo Kienitz
> >>> SecCommerce Informationssysteme GmbH
> >>> Obenhauptstr. 5
> >>> D - 22335 Hamburg
> >>> Germany                                   http://www.seccommerce.de

To: [email-masked]
From: [email-masked]
Date: Fri, 16 Nov 2007 16:00:01 -0500
Cc: [email-masked]
Subject: I-D Action:draft-ietf-smime-multisig-03.txt 
Reply-To: [email-masked]
Sender: [email-masked]

--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           : Multiple Signatures in S/MIME
	Author(s)       : I. Property
	Filename        : draft-ietf-smime-multisig-03.txt
	Pages           : 19
	Date            : 2007-11-16

CMS SignedData includes the SignerInfo structure to convey per-signer 
information. SignedData supports multiple signers and multiple 
signature algorithms per-signer with multiple SignerInfo structures. 
If a signer attaches more than one SignerInfo, there are concerns 
that an attacker could perform a downgrade attack by removing the 
SignerInfo(s) with the 'strong' algorithm(s). This document defines 

 the multiple-signatures attribute, its generation rules, and its 
processing rules to allow signers to convey multiple SignerInfo while 
protecting against downgrade attacks. Additionally, this attribute 
may assist during periods of algorithm migration. 

Conventions used in this document 

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 

Discussion 

This draft is being discussed on the 'ietf-smime' mailing list. To 
subscribe, send a message to [email-masked] with the 
single word subscribe in the body of the message. There is a Web site 
for the mailing list at <http://www.imc.org/ietf-smime/>.

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

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

Content-Type: text/plain
Content-ID: <2007-11-16155945.I-D\@ietf.org>

--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce

--NextPart--

Date: Mon, 19 Nov 2007 15:23:13 -0800
To: [email-masked], [email-masked], [email-masked]
From: Paul Hoffman <[email-masked]>
Subject: Fwd: Document Action: 'Additional Diffie-Hellman Groups for   use with IETF Standards' to Informational RFC
Sender: [email-masked]

>The IESG has approved the following document:
>
>- 'Additional Diffie-Hellman Groups for use with IETF Standards '
>    <draft-lepinski-dh-groups-03.txt> as an Informational RFC
>
>This document has been reviewed in the IETF but is not the product of an
>IETF Working Group.
>
>The IESG contact person is Tim Polk.
>
>A URL of this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-lepinski-dh-groups-03.txt
>
>Technical Summary
>
>This document specifies (eight) Diffie-Hellman groups for use with
>security protocols developed by five different IETF WGs (IPsec, PKIX,
>S/MIME, SSH, SSL, and TLS).  The specified groups include three
>modular exponentiation groups and five elliptic curve groups.  Several
>of the Diffie-Hellman groups specified in this draft are already
>defined in WG-specific RFCs (e.g., RFC 3526 and RFC 4753) and I-Ds,
>but without the test data provided here. The group definitions and
>test data are derived from a NIST document that is available only
>on the NIST web site as a PDF.  This draft translates the parameter
>terminology from the with NIST document into a form consistent with
>RFCs that define Diffie-Hellman groups (in protocol-specific contexts),
>and removes extraneous test data that would not be relevant to IETF
>protocols.
>
>Working Group Summary
>
>This document was not the product of any working group, but has been
>reviewed by experts from several relevant wgs.  Specifically, this
>document
>incorporates comments from: Tero Kivinen, the designated
>approver of additional Diffie-Hellman groups for IKE; Sean
>Turner S/MIME WG co-chair;  and Pasi Eronen (TLS WG co-chair).  Steve
>Kent (PKIX co-chair) is a co-author of this document and he ensured
>that PKIX concerns were addressed. No input was solicited form the
>SSH WG co-chairs, as that protocol provides a trivial means of
>accommodating additional (mod p) Diffie-Hellman groups. SSH provides
>no means of accommodating Elliptic Curve Diffie-Hellman groups, and
>as a result, the document is silent on use of Elliptic Curve
>Diffie-Hellman groups with SSH. (There is an expired I-D that
>describes how to use Elliptic Curve Diffie-Hellman with SSH. If it
>is re-submitted and adopted by the SSH WG, it would be appropriate
>to amend this draft to include it as well.)
>
>Protocol Quality
>
>Tim Polk reviewed this specification for the IESG.  Larry Bassham, who
>drafted the base NIST document, has also reviewed the specification.

From: The IESG <[email-masked]>
To: IETF-Announce <[email-masked]>
Cc: Internet Architecture Board <[email-masked]>, RFC Editor <[email-masked]>, smime mailing list <[email-masked]>, smime chair <[email-masked]>
Subject: Document Action: 'CMS Advanced Electronic Signatures  (CAdES)' to Informational RFC 
Date: Mon, 19 Nov 2007 14:41:27 -0500
Sender: [email-masked]

The IESG has approved the following document:

- 'CMS Advanced Electronic Signatures (CAdES) '
   <draft-ietf-smime-cades-07.txt> as an Informational RFC

This document is the product of the S/MIME Mail Security Working Group. 

The IESG contact persons are Tim Polk and Sam Hartman.

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

Technical Summary
 
   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.7.3 (CMS Advanced 
   Electronic Signatures - CAdES) [TS101733] and is technically 
   equivalent to it.
 
Working Group Summary
 
   While this work was initatiated in ETSI, this document was also
   discussed  by the S/MIME working group.  Issues were identified
   and resolved to maintain compatibility with implementations of
   RFC 3126, which it obsoletes.
 
Protocol Quality
 
Tim Polk reviewed this document for the IESG.

Date: Mon, 19 Nov 2007 14:16:58 +0100
From: "Denis Pinkas" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Cc: "S-MIME / IETF" <[email-masked]>
Subject: Re: TimeStampedData draft updated - please comment
Sender: [email-masked]

Adriano,

Thank you for this new proposal. I skimmed through it.

It is interesting, but I fear that it is targeted to the wrong WG.
Since this would be an extension of CMS, this work item 
would rather belong to the S-MIME WG.
For this reason, I copy the S-MIME WG. 

In addition, some polishing would be needed.

Rather than long words, you will find hereafter a rewriting of the ASN.1 
with a few explanatory comments.

   TimeStampedData ::= SEQUENCE { 
      version        [0] Version DEFAULT v1, 
      fileName           UTF8String, 
      mimeType           PrintableString, 
      fileLocation       UTF8String OPTIONAL, 
      -- fileLocation is only a hint. 
      -- The file may or may not be stored at that location.
      content            OCTET STRING, 
      temporalEvidences  TemporalEvidences 
}

   Version  ::=  INTEGER  { v1(0) } 
   TemporalEvidences ::= SEQUENCE (SIZE(1..MAX)) OF TemporalEvidence 

-- This structure allows multiple levels of temporal evidences.

   TemporalEvidence ::= SEQUENCE {
      evidences            Evidences,
      certificateLists     CertificateLists  OPTIONAL
}

   CertificateLists :: = SEQUENCE (SIZE(1..MAX)) OF CertificateList

   Evidence ::= CHOICE { 
      timeStamps     [0] SEQUENCE (SIZE(1..MAX)) OF TimeStampToken }

-- For each level there can be one or more time-stamps tokens.

-- Before re-time stamping a set of former time-stamp tokens, 
-- the CRLs of the previous level of time-stamps tokens can be captured 
-- and inserted in the data structure.

Denis

>Hello there,
>
>here I am again with my TimeStampedData proposal.
>
>I have submitted a new draft (also attached here) that takes into account some of the remarks and suggestions received so far.
>
>I have made room for additional types of temporal evidence, like e.g. RFC 4998, while keeping RFC 3161 as the basis of interoperability.
>
>I would like to invite everybody involved in time-stamping and archiving e-documents to comment upon it: has it improved? something is missing?
>
>In particular, please state:
>- are you interested in this work?
>- do you agree to adopt it as a new PKIX work item?
>- are you going to use this format, once it is finished?
>
>Is anybody willing to spend a few words on this draft during the IETF meeting in Vancouver (as I cannot attend myself) ?
>
>And finally, is anybody willing to invest a little time in co-authoring this draft with me?
>
>Adriano
>Actalis S.p.A.
>Milano, ITALY
>
>
>
>
>-----Messaggio originale-----
>Da: [email-masked] [mailto:[email-masked]] Per conto di Santoni Adriano
>Inviato: lunedì 3 settembre 2007 10.42
>A: [email-masked]
>Oggetto: R: R: Draft on TimeStampedData
>
>
>Let me summarize the issues discussed so far:
>
>1) allow EvidenceRecord (RFC 4998) in addition to TimeStampToken (RFC 3161)
>
>In principle, I have no objections as long as we do not complicate things too much and do not hamper interoperability. 
>
>There are at least two possible approaches to accomodate RFC 4998:
>
>   a) explicitly provide for (one) ER in the TimeStampedData syntax, as an alternative to the SET OF TimeStampToken;
>   b) do not mention any specific standard for the "evidence", but just mention RFC 3161 and RFC 4998 as two possibilities;
>
>In any case, it must be possible for the verifying application to easily detect which of the two (or more) kind of "evidence" has been used in the TimeStampedData envelope under examination. If we restrict the kinds of evidence to the two above, then a extra tagging may not be necessary, as an EvidenceRecord is a SEQUENCE, while the other choice would be a SET OF. Although unelegant, it would work. On the other hand, if we do not want to restrict the kinds of evidence to the two above, then of course we should somehow add an extra tagging level, because nobody knows at this time what syntax a third kind of evidence would conform to.
>
>In any case, for the sake of interoperability, strong emphasis should be given to RFC 3161 as today this is the most widely implemented type of evidence.
>
>In conclusion: I agree with allowing RFC 4998 if we do that in a way that does not modify the strong emphasis on RFC 3161 and does not hamper interoperability (which must be based on supporting RFC 3161, even though certain applications may also support RFC 4998).
>
>2) filename vs. URI 
>
>Some remarked that an URI (or URI Reference) would be more versatile than a simple filename. That is obviously true, but it implies that the 'content' field of TimeStampedData may be empty. This is not what I was addressing in my original proposal. It would not just require the 'content' field to be declared OPTIONAL: it would make interoperability very difficult to achieve unless we restrict the URI schemes to a very small subset (e.g. http:, cid:, file:, ldap:) of the myriad possibilities. In any case, it would require ages of interoperability testing. And it would make life much harder for software implementors, without much of a benefit in view. I strongly believe in keeping things simple as much as possible.
>
>3) multiple contents and RFC 4073
>
>The 'content' field in the TimeStampedData envelope is not structured, in my original proposal. It is just an OCTET STRING. That allows for any kind of content to be conveyed, even a ContentCollection according to RFC 4073.
>
>Another remark has been made with reference to RFC 4073: the ContentWithAttributes structure, also defined in RFC 4073, could in principle be used to bundle some content with the corrisponding evidence (the goal of my draft). Although this is true, it would require definining some additional OIDs, and mandating the presence of certain Attributes tagged by those OIDs. I frankly believe the TimeStampedData structure that I am proposing is better, first because it is dedicated and second because it "implements the ContentInfo interface", so to speak. It is simpler to manage for applications already able to parse different kinds of ContentInfo envelopes (there are a great many), possibly in a recursive way.
>
>Adriano 
>
>
>-----Messaggio originale-----
>Da: Young H Etheridge [mailto:[email-masked]]
>Inviato: venerdì 31 agosto 2007 17.48
>A: Santoni Adriano
>Cc: [email-masked]
>Oggetto: Re: R: Draft on TimeStampedData
>
>Adriano,
>
>To add to your thought processes:  I believe that a URI of "file:///private.stuff" addresses your concern for privacy of the physical URI.  But, allowing URI in the syntax will make less private repositories, not necessarily file systems, more universally accessible.  The intent of the URI in RFC 3986 is to also allow for abstractly identifying a resource, not necessarily providing a physical resource.  In this manner the URI could then be used as an object identity in database(s).
>
>Take care,
>
>yhe
>
>Santoni Adriano wrote:
>> To accomodate for RFC 4998, I would propose the following syntax:
>>
>> TimeStampedData ::= SEQUENCE {
>> 	version			INTEGER { v1(1) },
>> 	fileName		UTF8String,
>> 	mimeType 	 	PrintableString,
>> 	content		OCTET STRING,
>> 	evidence		Evidence
>> }
>>
>> Evidence ::= CHOICE {
>> 	timeStamps		[0] SET (SIZE(1..MAX)) OF TimeStampToken,
>> 	evidenceRecord	[1] EvidenceRecord -- according to RFC 4998
>> }
>>
>> (I am not sure whether it would be better to use explicit or implicit
>> tags...)
>>
>> Regarding the idea of having an URI instead of a filename: I'd prefer to think over things a little bit more, and maybe collect more feedback.
>>
>> In my mind, I can send a TimeStampedData envelope to business partners and/or public agencies via email. If the timestamped document is a local one, which I think is a meaningful and realistic scenario, then I do not want my company's hostnames and pathnames to be included in the envelope so that the recipient can see them.
>>
>> Adriano
>>
>>
>>
>> -----Messaggio originale-----
>> Da: [email-masked] [mailto:[email-masked]]
>> Per conto di Julien Stern
>> Inviato: venerdì 31 agosto 2007 13.43
>> A: [email-masked]
>> Oggetto: Re: Draft on TimeStampedData
>>
>>
>> On Fri, Aug 31, 2007 at 12:06:00PM +0200, Tilo Kienitz wrote:
>>   
>>> Adriano,
>>>
>>>     
>>>> After pondering on this and other remarks, I cannot help but agree 
>>>> with Steve.
>>>>
>>>> My original and essential goal is that of facilitating 
>>>> interoperability in a currently unregulated field. If we allow for 
>>>> several "degrees of freedom", than interoperability will be hampered from the beginning.
>>>> So I'd better stick to RFC 3161 for now. We could include support 
>>>> for RFC 4998 Evidence Records later on, at the time when they become 
>>>> a widespread reality comparable to RFC 3161 TimeStampTokens (which 
>>>> are widely implemented).
>>>>       
>>> I would prefer to have both options: RFC 3161 and RFC 4998. For our 
>>> customers evidence records are a widespread reality already.
>>> A standardized way to put some data and their evidence record into a 
>>> single file would be useful.
>>>     
>>
>> I strongly concur with this comment. Allowing the usage of ERS as well as simple timestamps would allow the TimestampedData to leverage all the work of RFC 4998 regarding timestamps instead of reinventing the wheel in the future.
>>
>> Regards,
>>
>> --
>> Julien
>>
>>   
>>> Kind regards
>>> Tilo
>>>
>>>
>>>     
>>>> -----Messaggio originale-----
>>>> Da: Stephen Kent [mailto:[email-masked]]
>>>> Inviato: giovedì 30 agosto 2007 23.05
>>>> A: Young H Etheridge
>>>> Cc: Santoni Adriano; [email-masked]
>>>> Oggetto: Re: R: Draft on TimeStampedData
>>>>
>>>> At 4:33 PM -0400 8/30/07, Young H Etheridge wrote:
>>>>       
>>>>>> ...
>>>>>>           
>>>>> Agreed, w.r.t. normative vs informative.  The above quote from
>>>>> RFC-4998 merely underscores that this draft should also suggest, 
>>>>> informatively, that the choice of Timestamp should be one that 
>>>>> meets the normative syntax for Timestamp and not specify that which 
>>>>> is in RFC-3161.  Nothing gets broken by being less restrictive and 
>>>>> generally more informative to the community-at-large.
>>>>>         
>>>> I have to disagree with your conclusion. If we require 3161 time stamps in an RFC of the sort Adriano proposed, then everyone can parse them if they comply with the RFC. If the RFC says "insert the time stamp from any standard you want here, and just tell us which one you used" then we have a problem. A compliant implementation can generate data structures containing time stamps that other compliant implementations cannot parse. That's the sort of interoperability problem we try to avoid in the IETF.
>>>>
>>>>       
>>>>> My notion of resilience does not mean "more encompassing" but that 
>>>>> of providing the user community with choice and an enhanced 
>>>>> safeguard against the possibility of the weakening of an algorithm.
>>>>>         
>>>> Choices can be good, but they can create interoperability problems in some cases, like this one. Also, we have algorithm agility as a requirement in all of our work, so the second concern you cite does not seem to apply here.
>>>>
>>>> Steve
>>>>       
>>> --
>>> Tilo Kienitz
>>> SecCommerce Informationssysteme GmbH
>>> Obenhauptstr. 5
>>> D - 22335 Hamburg
>>> Germany                                   http://www.seccommerce.de

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D Action:draft-ietf-smime-multisig-03.txt 
Date: Fri, 16 Nov 2007 16:00:01 -0500
Sender: [email-masked]

--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           : Multiple Signatures in S/MIME
	Author(s)       : I. Property
	Filename        : draft-ietf-smime-multisig-03.txt
	Pages           : 19
	Date            : 2007-11-16

CMS SignedData includes the SignerInfo structure to convey per-signer 
information. SignedData supports multiple signers and multiple 
signature algorithms per-signer with multiple SignerInfo structures. 
If a signer attaches more than one SignerInfo, there are concerns 
that an attacker could perform a downgrade attack by removing the 
SignerInfo(s) with the 'strong' algorithm(s). This document defines 

 the multiple-signatures attribute, its generation rules, and its 
processing rules to allow signers to convey multiple SignerInfo while 
protecting against downgrade attacks. Additionally, this attribute 
may assist during periods of algorithm migration. 

Conventions used in this document 

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 

Discussion 

This draft is being discussed on the 'ietf-smime' mailing list. To 
subscribe, send a message to [email-masked] with the 
single word subscribe in the body of the message. There is a Web site 
for the mailing list at <http://www.imc.org/ietf-smime/>.

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

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

Content-Type: text/plain
Content-ID:     <2007-11-16155945.I-D\@ietf.org>

--OtherAccess--

--NextPart--

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-cades-07.txt 
Date: Wed, 14 Nov 2007 16:15:01 -0500
Sender: [email-masked]

--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-07.txt
	Pages		: 132
	Date		: 2007-11-14
	
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.7.4 (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-07.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-07.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-07.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-07.txt

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

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

--OtherAccess--

--NextPart--

Date: Tue, 13 Nov 2007 10:11:14 -0800
To: <[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: Adding modules to draft-hoffman-cms-new-asn1
Sender: [email-masked]

At 10:55 AM -0500 11/13/07, Turner, Sean P. wrote:
>We should add ASN.1 from RFC3274 - id-compressed-data.

Probably true, and there are a pile of others that might be 
appropriate as well.

One thought is to make this eventual RFC a repository of all 
standards-track CMS and S/MIME modules, even those that don't need to 
be updated for the 2002 syntax. That gives developers a single place 
to go for all ASN.1 modules, and maybe remind them of standards-track 
RFCs that they have forgotten but should pay attention to.

A different thought would be to make it a repository of just the ones 
that need to be updated. In this scenario, we could still have a list 
of CMS and S/MIME modules not included because they didn't need to 
be; that could serve as an equivalent reminder.

How do people here feel about these alternatives?

--Paul Hoffman, Director
--VPN Consortium

From: "Turner, Sean P." <[email-masked]>
To: "'Paul Hoffman'" <[email-masked]>, <[email-masked]>
Subject: RE: I-D Action:draft-hoffman-cms-new-asn1-00.txt
Date: Tue, 13 Nov 2007 10:55:35 -0500
Organization: IECA, Inc.
Sender: [email-masked]

We should add ASN.1 from RFC3274 - id-compressed-data. 

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Paul Hoffman
>Sent: Thursday, November 08, 2007 3:59 PM
>To: [email-masked]
>Subject: Fwd: I-D Action:draft-hoffman-cms-new-asn1-00.txt
>
>
>Greetings again. Jim Schaad and I have created a draft that 
>contains revised ASN.1 modules for some of the standards-track 
>RFCs for S/MIME. These modules conform to ASN.1 2002. We want 
>to see if people are interested in bringing the S/MIME specs 
>up to the new ASN.1 now that there is an open source, freeware 
>ASN.1 compiler for ASN.1 2002, a2c (see 
><http://code.google.com/p/a2c/>).
>
>This is definitely a first draft. There is a list of issues 
>that we want to address, and we expect more issues to come up 
>in the WG. 
>Please review the draft and let us know what you think. FWIW, 
>there is a parallel draft for PKIX.
>
>>A New Internet-Draft is available from the on-line Internet-Drafts 
>>directories.
>>
>>	Title           : New ASN.1 Modules for CMS and S/MIME
>>	Author(s)       : P. Hoffman, J. Schaad
>>	Filename        : draft-hoffman-cms-new-asn1-00.txt
>>	Pages           : 32
>>	Date            : 2007-11-08
>>
>>The Cryptographic Message Syntax (CMS) format, and many associated 
>>formats, are expressed using ASN.1.  The current ASN.1 
>modules conform 
>>to the 1988 version of ASN.1.  This document updates those
>>ASN.1 modules to conform to the 2002 version of ASN.1.  There are no 
>>bits-on-the-wire changes to any of the formats; this is 
>simply a change 
>>to the syntax.
>>
>>A URL for this Internet-Draft is:
>>http://www.ietf.org/internet-drafts/draft-hoffman-cms-new-asn1-00.txt
>
>--Paul Hoffman, Director
>--VPN Consortium
>

Date: Fri, 9 Nov 2007 06:41:16 -0800
To: "Kemp, David P." <[email-masked]>, "Simon Josefsson" <[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: RE: Fwd: I-D Action:draft-hoffman-cms-new-asn1-00.txt
Cc: <[email-masked]>
Sender: [email-masked]

Wait wait wait!

The S/MIME WG mailing list is *not* the place for the discussion of 
how the IETF and/or GNU process should work; the IPR WG mailing list 
is.

Simon made a request (that we modify the drafts to make him believe 
that he can use the contents there). We are considering doing so. 
However, the "how" part is not for this mailing list.

--Paul Hoffman, Director
--VPN Consortium

Content-class: urn:content-classes:message
Subject: RE: Fwd: I-D Action:draft-hoffman-cms-new-asn1-00.txt
Date: Fri, 9 Nov 2007 09:22:47 -0500
From: "Kemp, David P." <[email-masked]>
To: "Simon Josefsson" <[email-masked]>, "Paul Hoffman" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Simon,

Perhaps I misunderstand the meaning of [1]:

"Dear Author,

The Debian GNU/Linux distribution wishes to incorporate the
IETF RFC xxxx as part of its distribution, and to allow
users to develop, modify and evolve the document."

but it sounds like a request to keep the name "IETF RFC xxxx"
while modifying the content.  This is, of course, completely
contrary to the IETF configuration management process where
RFCs are an archival document series, and no changes are
permitted once an RFC is issued.

Perhaps Debian should align its process with that of the
IETF, requesting permission to create derivative documents
provided that attribution is maintained, and requiring
that any derivative works DO NOT claim to be IETF RFCs.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Simon Josefsson
Sent: Friday, November 09, 2007 6:07 AM
To: Paul Hoffman
Cc: [email-masked]
Subject: Re: Fwd: I-D Action:draft-hoffman-cms-new-asn1-00.txt

The initiative seems to be a good idea.

To be able to use these ASN.1 modules in free software, a license to
grant the necessary rights is needed.  (As far as I understand, RFC 3978
is not sufficient, see [1].)  After verifying that the ownership of the
contribution allows it, please consider adding a note (possibly the one
discussed in section 3 of [2]) or somehow release the modules under a
liberal license outside of the IETF process.

Thanks,
Simon

[1] http://wiki.debian.org/NonFreeIETFDocuments

[2] http://tools.ietf.org/html/draft-josefsson-free-standards-howto-01

Paul Hoffman <[email-masked]> writes:

> Greetings again. Jim Schaad and I have created a draft that contains
> revised ASN.1 modules for some of the standards-track RFCs for
> S/MIME. These modules conform to ASN.1 2002. We want to see if people
> are interested in bringing the S/MIME specs up to the new ASN.1 now
> that there is an open source, freeware ASN.1 compiler for ASN.1 2002,
> a2c (see <http://code.google.com/p/a2c/>).
>
> This is definitely a first draft. There is a list of issues that we
> want to address, and we expect more issues to come up in the
> WG. Please review the draft and let us know what you think. FWIW,
> there is a parallel draft for PKIX.
>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>
>>	Title           : New ASN.1 Modules for CMS and S/MIME
>>	Author(s)       : P. Hoffman, J. Schaad
>>	Filename        : draft-hoffman-cms-new-asn1-00.txt
>>	Pages           : 32
>>	Date            : 2007-11-08
>>
>>The Cryptographic Message Syntax (CMS) format, and many associated
>>formats, are expressed using ASN.1.  The current ASN.1 modules
>>conform to the 1988 version of ASN.1.  This document updates those
>>ASN.1 modules to conform to the 2002 version of ASN.1.  There are no
>>bits-on-the-wire changes to any of the formats; this is simply a
>>change to the syntax.
>>
>>A URL for this Internet-Draft is:
>>http://www.ietf.org/internet-drafts/draft-hoffman-cms-new-asn1-00.txt
>
> --Paul Hoffman, Director
> --VPN Consortium

From: Simon Josefsson <[email-masked]>
To: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: Fwd: I-D Action:draft-hoffman-cms-new-asn1-00.txt
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Fri, 09 Nov 2007 12:07:16 +0100
Sender: [email-masked]

The initiative seems to be a good idea.

To be able to use these ASN.1 modules in free software, a license to
grant the necessary rights is needed.  (As far as I understand, RFC 3978
is not sufficient, see [1].)  After verifying that the ownership of the
contribution allows it, please consider adding a note (possibly the one
discussed in section 3 of [2]) or somehow release the modules under a
liberal license outside of the IETF process.

Thanks,
Simon

[1] http://wiki.debian.org/NonFreeIETFDocuments

[2] http://tools.ietf.org/html/draft-josefsson-free-standards-howto-01

Paul Hoffman <[email-masked]> writes:

> Greetings again. Jim Schaad and I have created a draft that contains
> revised ASN.1 modules for some of the standards-track RFCs for
> S/MIME. These modules conform to ASN.1 2002. We want to see if people
> are interested in bringing the S/MIME specs up to the new ASN.1 now
> that there is an open source, freeware ASN.1 compiler for ASN.1 2002,
> a2c (see <http://code.google.com/p/a2c/>).
>
> This is definitely a first draft. There is a list of issues that we
> want to address, and we expect more issues to come up in the
> WG. Please review the draft and let us know what you think. FWIW,
> there is a parallel draft for PKIX.
>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>
>>	Title           : New ASN.1 Modules for CMS and S/MIME
>>	Author(s)       : P. Hoffman, J. Schaad
>>	Filename        : draft-hoffman-cms-new-asn1-00.txt
>>	Pages           : 32
>>	Date            : 2007-11-08
>>
>>The Cryptographic Message Syntax (CMS) format, and many associated
>>formats, are expressed using ASN.1.  The current ASN.1 modules
>>conform to the 1988 version of ASN.1.  This document updates those
>>ASN.1 modules to conform to the 2002 version of ASN.1.  There are no
>>bits-on-the-wire changes to any of the formats; this is simply a
>>change to the syntax.
>>
>>A URL for this Internet-Draft is:
>>http://www.ietf.org/internet-drafts/draft-hoffman-cms-new-asn1-00.txt
>
> --Paul Hoffman, Director
> --VPN Consortium

From: "Turner, Sean P." <[email-masked]>
To: "'Paul Hoffman'" <[email-masked]>, <[email-masked]>
Subject: RE: I-D Action:draft-hoffman-cms-new-asn1-00.txt
Date: Thu, 8 Nov 2007 21:13:33 -0500
Organization: IECA, Inc.
Sender: [email-masked]

I am interested in moving the specs up to the later ASN.1 version.

spt  

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Paul Hoffman
>Sent: Thursday, November 08, 2007 3:59 PM
>To: [email-masked]
>Subject: Fwd: I-D Action:draft-hoffman-cms-new-asn1-00.txt
>
>
>Greetings again. Jim Schaad and I have created a draft that 
>contains revised ASN.1 modules for some of the standards-track 
>RFCs for S/MIME. These modules conform to ASN.1 2002. We want 
>to see if people are interested in bringing the S/MIME specs 
>up to the new ASN.1 now that there is an open source, freeware 
>ASN.1 compiler for ASN.1 2002, a2c (see 
><http://code.google.com/p/a2c/>).
>
>This is definitely a first draft. There is a list of issues 
>that we want to address, and we expect more issues to come up 
>in the WG. 
>Please review the draft and let us know what you think. FWIW, 
>there is a parallel draft for PKIX.
>
>>A New Internet-Draft is available from the on-line Internet-Drafts 
>>directories.
>>
>>	Title           : New ASN.1 Modules for CMS and S/MIME
>>	Author(s)       : P. Hoffman, J. Schaad
>>	Filename        : draft-hoffman-cms-new-asn1-00.txt
>>	Pages           : 32
>>	Date            : 2007-11-08
>>
>>The Cryptographic Message Syntax (CMS) format, and many associated 
>>formats, are expressed using ASN.1.  The current ASN.1 
>modules conform 
>>to the 1988 version of ASN.1.  This document updates those
>>ASN.1 modules to conform to the 2002 version of ASN.1.  There are no 
>>bits-on-the-wire changes to any of the formats; this is 
>simply a change 
>>to the syntax.
>>
>>A URL for this Internet-Draft is:
>>http://www.ietf.org/internet-drafts/draft-hoffman-cms-new-asn1-00.txt
>
>--Paul Hoffman, Director
>--VPN Consortium
>

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-bfibecms-08.txt 
Date: Thu, 08 Nov 2007 17:15:01 -0500
Sender: [email-masked]

--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-08.txt
	Pages		: 16
	Date		: 2007-11-8
	
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-08.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-08.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-08.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-08.txt

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

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

--OtherAccess--

--NextPart--

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-3850bis-00.txt 
Date: Thu, 08 Nov 2007 17:15:01 -0500
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the S/MIME Mail Security Working Group of the IETF.

	Title		: Secure/Multipurpose Internet Mail Extensions 
                          (S/MIME) Version 3.2 Certificate Handling 
	Author(s)	: S. Turner, B. Ramsdell
	Filename	: draft-ietf-smime-3850bis-00.txt
	Pages		: 18
	Date		: 2007-11-8
	
   This document specifies conventions for X.509 certificate usage by 
   Secure/Multipurpose Internet Mail Extensions (S/MIME) agents.  S/MIME 
   provides a method to send and receive secure MIME messages, and 
   certificates are an integral part of S/MIME agent processing.  S/MIME 
   agents validate certificates as described in RFC 3280bis, the 
   Internet X.509 Public Key Infrastructure Certificate and CRL Profile.  
   S/MIME agents must meet the certificate processing requirements in 
   this document as well as those in RFC 3280bis. This document 
   obsoletes RFC 3850. 

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

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

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

--OtherAccess--

--NextPart--

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-ibearch-06.txt 
Date: Thu, 08 Nov 2007 17:15:01 -0500
Sender: [email-masked]

--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		: Identity-based Encryption Architecture
	Author(s)	: M. Schertler, et al.
	Filename	: draft-ietf-smime-ibearch-06.txt
	Pages		: 28
	Date		: 2007-11-8
	
This document describes the security architecture required 
     to implement identity-based encryption, a public-key 
     encryption technology that uses a user's identity as a 
     public key.

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

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

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

--OtherAccess--

--NextPart--

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-3851bis-00.txt 
Date: Thu, 08 Nov 2007 17:15:01 -0500
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the S/MIME Mail Security Working Group of the IETF.

	Title		: Secure/Multipurpose Internet Mail Extensions 
                          (S/MIME) Version 3.2 Message Specification 
	Author(s)	: B. Ramsdell, S. Turner
	Filename	: draft-ietf-smime-3851bis-00.txt
	Pages		: 39
	Date		: 2007-11-8
	
   This document defines Secure/Multipurpose Internet Mail Extensions 
   (S/MIME) version 3.2.  S/MIME provides a consistent way to send and 
   receive secure MIME data.  Digital signatures provide authentication, 
   message integrity, and non-repudiation with proof of origin. 
   Encryption provides data confidentiality.  Compression can be used to 
   reduce data size.  This document obsoletes RFC 3851.

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

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

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

--OtherAccess--

--NextPart--

Date: Thu, 8 Nov 2007 12:59:11 -0800
To: [email-masked]
From: Paul Hoffman <[email-masked]>
Subject: Fwd: I-D Action:draft-hoffman-cms-new-asn1-00.txt
Sender: [email-masked]

Greetings again. Jim Schaad and I have created a draft that contains 
revised ASN.1 modules for some of the standards-track RFCs for 
S/MIME. These modules conform to ASN.1 2002. We want to see if people 
are interested in bringing the S/MIME specs up to the new ASN.1 now 
that there is an open source, freeware ASN.1 compiler for ASN.1 2002, 
a2c (see <http://code.google.com/p/a2c/>).

This is definitely a first draft. There is a list of issues that we 
want to address, and we expect more issues to come up in the WG. 
Please review the draft and let us know what you think. FWIW, there 
is a parallel draft for PKIX.

>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>
>	Title           : New ASN.1 Modules for CMS and S/MIME
>	Author(s)       : P. Hoffman, J. Schaad
>	Filename        : draft-hoffman-cms-new-asn1-00.txt
>	Pages           : 32
>	Date            : 2007-11-08
>
>The Cryptographic Message Syntax (CMS) format, and many associated
>formats, are expressed using ASN.1.  The current ASN.1 modules
>conform to the 1988 version of ASN.1.  This document updates those
>ASN.1 modules to conform to the 2002 version of ASN.1.  There are no
>bits-on-the-wire changes to any of the formats; this is simply a
>change to the syntax.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-hoffman-cms-new-asn1-00.txt

--Paul Hoffman, Director
--VPN Consortium

From: "Turner, Sean P." <[email-masked]>
To: <[email-masked]>
Subject: Agenda Topics
Date: Mon, 5 Nov 2007 13:10:01 -0500
Organization: IECA, Inc.
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_00E3_01C81FAD.2C6EA0B0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

If anyone is interested in getting some time on the agenda please send Blake
or myself a note.

Cheers,

spt

------=_NextPart_000_00E3_01C81FAD.2C6EA0B0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7036.0">
<TITLE>Agenda Topics</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P><FONT SIZE=3D2 FACE=3D"Arial">If anyone is interested in getting some =
time on the agenda please send Blake or myself a note.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Cheers,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">spt</FONT>
</P>

</BODY>
</HTML>
------=_NextPart_000_00E3_01C81FAD.2C6EA0B0--