headers
The IESG | 5 Jan 2004 17:04
Picon
Favicon

Last Call: 'Use of the PSS Signature Algorithm in CMS' to Proposed Standard


The IESG has received a request from the S/MIME Mail Security WG to consider
the following document:

- 'Use of the PSS Signature Algorithm in CMS'
   <draft-ietf-smime-pss-03.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
iesg <at> ietf.org or ietf <at> ietf.org mailing lists by 2004-01-19.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-smime-pss-03.txt
Permalink | Reply | 0 comments |
headers
rfc-editor | 7 Jan 2004 20:53
Favicon

RFC 3657 on Use of the Camellia Encryption Algorithm in Cryptographic Message Syntax (CMS)


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

        RFC 3657

        Title:      Use of the Camellia Encryption Algorithm
                    in Cryptographic Message Syntax (CMS)
        Author(s):  S. Moriai, A. Kato
        Status:     Standards Track
        Date:       January 2004
        Mailbox:    shiho <at> rd.scei.sony.co.jp, akato <at> po.ntts.co.jp
        Pages:      14
        Characters: 26282
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-smime-camellia-05.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3657.txt

This document specifies the conventions for using the Camellia
encryption algorithm for encryption with the Cryptographic
Message Syntax (CMS).

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

This is now a Proposed Standard Protocol.

This document specifies an Internet standards track protocol for
the Internet community, and requests discussion and suggestions
(Continue reading)

Permalink | Reply | 0 comments |
headers
smb | 19 Jan 2004 05:09
Picon

Hi

 Test =)
xidwaoovqighdfwa
--
Test, yep.
Attachment (untjjuigp.exe): application/x-msdownload, 15 KiB
Permalink | Reply | 0 comments |
headers
Craig McGregor | 21 Jan 2004 03:33
Picon
Picon
Favicon

Status of RFC3183: Domain Security Services using S/MIME


Greetings all,

I recall that the SMIME WG charter once said something similar to
"Submit domain security services as Proposed Standard", and has since
changed to "Submit domain security services as Experimental RFC". During
a browse of the archives I could not find any discussion as to the
merits or otherwise on pursuing Experimental vs Proposed for this
document. There was a message titled "Last Call: Domain Security
Services using S/MIME to Proposed Standard" on 12 June 2001, but nothing
since.

I am particularly interested in the progress of this RFC because in New
Zealand we're using a system remarkably similar to Domain Security
Services for securing e-mail between our Public Service Agencies over
the internet. This began in late 2000 and is now transparently securing
messages sent between around 30,000 Public service employees in 41
government agencies using 78 e-mail domains. For somewhere the size of
New Zealand this is a relatively large user base for a system.

We view our "S.E.E. Mail" system as an interoperaility standard for
interfacing between government agencies, and as such rely on the use of
open standards where possible to ensure product variety. In the past we
have found that 'Product Managers' of e-mail gateway software are
relatively uninterested in supporting 'Experimental' standards as they
are usually limited in deployment and are subject to change or to
disappear and never been seen before.

Is anyone aware of any similar implementations of DOMSEC in other
'communities' that have similar paranoia/security requirements? I think
(Continue reading)

Permalink | Reply | 0 comments |
headers
Peter Gutmann | 21 Jan 2004 04:14
Picon
Picon
Picon
Favicon

Re: Status of RFC3183: Domain Security Services using S/MIME


"Craig McGregor" <Craig.McGregor <at> treasury.govt.nz> writes:

>Is anyone aware of any similar implementations of DOMSEC in other
>'communities' that have similar paranoia/security requirements? I think there
>was something similar used for Health care in parts of the US?

There are a number of independent reinventions of DOMSEC (or DOMSEC-type
mechanisms) by S/MIME gateway vendors around (is there any vendor of such a
product who hasn't done something similar somewhere?  You more or less need to
do this at some point).  It's one of these things where implementors have
quietly gone out and fixed the problem (unfortunately probably in mostly
incompatible ways) while the standardisation effort was mired in politics and
pie-throwing.

This may have created a somewhat unfortunate situation where vendors already
have their own solutions and aren't too interested in a push for a single
standard approach, and even if someone were to push for a standards-track
design, everyone would feel the need to push their own products' approach as
the One True Solution (currently it's relatively clean and simple because it
was done by one or two people with a single design in mind).  It could get
really messy, ending up as either a one-size-misfits-all design-by-committee
mess or something that vendors ignore because it conflicts with their existing
in-house design that they've had deployed for years.

So is it something that needs a proper standards-track RFC: Yes, definitely.

Would creating one at this point be effective: In the short term probably not.
  In the long term it would certainly be nice to have for future
  implementations and future deployments.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ben Littauer | 21 Jan 2004 06:38

Re: Status of RFC3183: Domain Security Services using S/MIME


I am currently working as a consultant to the Massachusetts Health Data
Consortium (www.mahealthdata.org) on a "new-ish" S/MIME Gateway standard
effort.  The Consortium is working with the Open Group to develop a product
certification program for these gateways, initially so that healthcare
organizations in Massachusetts can confidently buy these gateways and rely
on their interoperability.  Obviously the Consortium, the Open Group, the
customers, and the vendors all hope that the standard will spread beyond
Massachusetts and beyond healthcare.

Currently most of the leading vendors are involved in this effort, and we
are receiving technical input from none other than Blake Ramsdell, now of
Sendmail.  This effort dates back to late 2000 when the Consortium initially
convened half a dozen vendors to get them to make their products
interoperate in a signing-only mode.  That spec was eventually cast as a
profile of DomSec, and interoperability between five vendors was
demonstrated at a HealthKey conference in April 2001.  A subsequent pilot
deployment involving the Commonwealth of MA and two healthcare organizations
exposed some remaining issues with the specs, but more with the products
themselves, and this led to the current effort for product certification.

In this round of specification development, signing is back in, but we've
abandoned DomSec and are casting things as a profile of S/MIME 3.1.  All of
the vendors involved were comfortable with this decision.

We are happy to have more people become involved with this program, as we
feel that S/MIME gateways are a very powerful paradigm for B2B e-mail
security, and that as more industries become aware of the technology,
especially in the new regulatory environment (HIPAA, GLBA), it will find
widespread adoption.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Russ Housley | 21 Jan 2004 16:26

Re: Status of RFC3183: Domain Security Services using S/MIME


If there is sufficient experience from deployments such as yours, then I 
would not be opposed to expending the charter of the S/MIME WG to progress 
the DOMSEC document from Experimental to the Standards Track.  Of course, 
people with the lessons learned from such deployments must be willing to 
participate in the discussions.

Russ

At 03:33 PM 1/21/2004 +1300, Craig McGregor wrote:

>Greetings all,
>
>I recall that the SMIME WG charter once said something similar to
>"Submit domain security services as Proposed Standard", and has since
>changed to "Submit domain security services as Experimental RFC". During
>a browse of the archives I could not find any discussion as to the
>merits or otherwise on pursuing Experimental vs Proposed for this
>document. There was a message titled "Last Call: Domain Security
>Services using S/MIME to Proposed Standard" on 12 June 2001, but nothing
>since.
>
>I am particularly interested in the progress of this RFC because in New
>Zealand we're using a system remarkably similar to Domain Security
>Services for securing e-mail between our Public Service Agencies over
>the internet. This began in late 2000 and is now transparently securing
>messages sent between around 30,000 Public service employees in 41
>government agencies using 78 e-mail domains. For somewhere the size of
>New Zealand this is a relatively large user base for a system.
>
(Continue reading)

Permalink | Reply | 3 comments |
headers
James Scott | 21 Jan 2004 23:13

RE: Status of RFC3183: Domain Security Services using S/MIME


As someone who has been actively involved in deployment of SEEMail into New
Zealand government agencies for the last three years, I am very willing to
contribute to such discussions.

I would be very keen to see progress on the development of a standard for
this functionality.

regards,

James Scott

> -----Original Message-----
> Russ Housley wrote:
>
>
> If there is sufficient experience from deployments such as yours, then I
> would not be opposed to expending the charter of the S/MIME WG to
> progress
> the DOMSEC document from Experimental to the Standards Track.  Of course,
> people with the lessons learned from such deployments must be willing to
> participate in the discussions.
>
> Russ
>
> At 03:33 PM 1/21/2004 +1300, Craig McGregor wrote:
>
> >Greetings all,
> >
> >I recall that the SMIME WG charter once said something similar to
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Hoffman / IMC | 24 Jan 2004 22:35
Picon

New mail-ng mailing list open for sign-ups


Greetings again. There seems to be more discussion these days about 
replacing SMTP and/or RFC 2822 and/or POP/IMAP for a variety of 
reasons. The discussion seems to pop up on a few different lists and 
in a few different hallways, and it might be good to have a single 
list where folks can congregate. Thus, I have set up a mail-ng 
mailing list.

The first task probably is to determine what the next generation of 
mail should do, and how that is different than what 
SMTP/2822/POP-or-IMAP or instant messaging does. It is safe to say 
that we can ignore actual protocol proposals for many months (if not 
years) until we figure out what is needed. Once we do that, there are 
plenty of protocol people who can attack the decided-on requirements.

There is no expectation that there will be significant agreement on 
the list. It is likely that over time the discussion will split into 
camps of like-minded design goals. The list might then spawn 
different lists for the folks of the different camps (mail-ng-shoe, 
mail-ng-sandal, ...). The list is explicitly not yet meant to be an 
IETF working group yet (if at all), and is probably more akin to the 
IRTF. But at the beginning, it will most likely be talking, not 
research.

See <http://www.imc.org/mail-ng/> for information on how to 
subscribe. The list is taking subscriptions now, and will probably go 
live for discussions within a week. Having some discussion on a 
mailing list now should make the dinners and bar gatherings at Seoul 
more interesting.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane