RE: Certs-only Mechanism for X.400 Transport
"William Ottaway" <w.ottaway@eris.dera.gov.uk> Thu, 01 March 2001 09:31 UTC
Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA28751 for <smime-archive@odin.ietf.org>; Thu, 1 Mar 2001 04:31:50 -0500 (EST)
Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id BAA19193 for ietf-smime-bks; Thu, 1 Mar 2001 01:05:41 -0800 (PST)
Received: from mail.eris.dera.gov.uk (ns0.eris.dera.gov.uk [128.98.1.1]) by above.proper.com (8.9.3/8.9.3) with SMTP id BAA19180 for <ietf-smime@imc.org>; Thu, 1 Mar 2001 01:05:38 -0800 (PST)
Received: (qmail 14450 invoked from network); 1 Mar 2001 09:05:35 -0000
Received: from cray.eris.dera.gov.uk (HELO mailhost.eris.dera.gov.uk) (128.98.2.7) by ens0.eris.dera.gov.uk with SMTP; 1 Mar 2001 09:05:35 -0000
Received: (qmail 6496 invoked from network); 1 Mar 2001 09:05:34 -0000
Received: from wottaway.eris.dera.gov.uk (HELO wottaway) (128.98.10.192) by mailhost.eris.dera.gov.uk with SMTP; 1 Mar 2001 09:05:33 -0000
From: William Ottaway <w.ottaway@eris.dera.gov.uk>
To: Blake Ramsdell <blaker@tumbleweed.com>, 'Russ Housley' <housley@spyrus.com>
Cc: "Bonatti, Chris" <BonattiC@ieca.com>, jimsch@exmsft.com, ietf-smime@imc.org
Subject: RE: Certs-only Mechanism for X.400 Transport
Date: Thu, 01 Mar 2001 09:10:33 -0000
Message-ID: <NABBJNEAKNOGJBHIOCBHIEMIDMAA.w.ottaway@eris.dera.gov.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <01FF24001403D011AD7B00A024BC53C5A77AAA@cane.deming.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit
Blake, I have no problem with pushing CRLs through a CMS message. I have a problem with the text "certificates-only Message" because it is misleading. I believe the text in 3.6 should refer to a certificate management message. 3.6 Creating a Certificate Management Message The certificate management message or MIME entity is used to transport certificates and/or CRLs, such as in response to a registration request. Step 1. The certificates and/or CRLs are made available to the CMS generating process which creates a CMS object of type signedData. The signedData encapContentInfo eContent field MUST be absent and signerInfos field MUST be empty. Step 2. The CMS signedData object is enclosed in an application/pkcs7-mime MIME entity The smime-type parameter for a certificate management message is "cert-management". The file extension for this type of message is ".p7c". Bill. > -----Original Message----- > From: owner-ietf-smime@mail.imc.org > [mailto:owner-ietf-smime@mail.imc.org]On Behalf Of Blake Ramsdell > Sent: 28 February 2001 20:36 > To: 'Russ Housley'; William Ottaway > Cc: Bonatti, Chris; jimsch@exmsft.com; ietf-smime@imc.org > Subject: RE: Certs-only Mechanism for X.400 Transport > > > Section 3.6 currently reads (sorry if it wraps) > > > 3.6 Creating a Certificates-only Message > > > > The certificates only message or MIME entity is used to transport > > certificates, such as in response to a registration request. This > > format can also be used to convey CRLs. > > > > Step 1. The certificates are made available to the CMS generating > > process which creates a CMS object of type signedData. The signedData > > encapContentInfo eContent field MUST be absent and signerInfos field > > MUST be empty. > > > > Step 2. The CMS signedData object is enclosed in an > > application/pkcs7-mime MIME entity > > > > The smime-type parameter for a certs-only message is "certs-only". > > The file extension for this type of message is ".p7c". > > These steps are valid for sending CRLs also, if that is ambiguous. Step 1 > can be modified to read "The certificates and/or CRLs". Pushing CRLs > through a CMS message is a valid idea (at least I think so), and > in fact we > do it for our own product (we chase down CRLs and package thm in CMS > messages). > > Blake > > -----Original Message----- > From: Russ Housley [mailto:housley@spyrus.com] > Sent: Wednesday, February 28, 2001 5:57 AM > To: William Ottaway > Cc: Bonatti, Chris; jimsch@exmsft.com; ietf-smime@imc.org > Subject: RE: Certs-only Mechanism for X.400 Transport > > > I was not part of the S/MIME v2 discussions that lead to the current > format. I have asked Blake to chime in, and I hope that he does. The > scenario of interest is a CA returning a certificate in response to the > PKCS#10 request. Here, the CA could choose to include the > current CRLs in > the "cert-only" message. This would seed the newly-enrolled user's CRL > cache. > > I am not aware of any CA pushing CRLs to their subscribers in an S/MIME > message. It could certainly be done.... > > Russ > > At 04:30 PM 2/26/2001 +0000, William Ottaway wrote: > >Chris, > > > >I'm happy for the text to indicate that the format described for a certs > >only message could be used to transport CRLs or both, as long as the text > >also states that if CRLs or both are being transported the OID for certs > >only MUST not be used. > > > >Do we have consensus :-) > > > >Bill. > > > > > -----Original Message----- > > > From: Bonatti, Chris [mailto:BonattiC@ieca.com] > > > Sent: 26 February 2001 16:10 > > > To: William Ottaway > > > Cc: jimsch@exmsft.com; ietf-smime@imc.org > > > Subject: Re: Certs-only Mechanism for X.400 Transport > > > > > > > > > Bill, > > > > > > Okay, how about option (3) ;-) > > > > > > (3) would be we clarify the text, but describe more clearly > > > what I think was > > > the intent of RFC 2633. Namely, that the format described and > > > identified as > > > "certs-only" can be used to convey either certs, CRLs or both. > > > > > > Btw, I would happily go along with either (1) or (2) if the > > > corresponding > > > change were made to the MSG spec. I guess I still favor (3) > > > however, because I > > > perceive it to be the status quo, and because allowing CRLs to be > > > included here > > > doesn't seem to break anything for the PKCS #10 scenario. I'd be > > > hard pressed > > > to cite the benefits, though. Does anybody remember the logic > > > for why this was > > > done? > > > > > > Chris > > > > > > > > > _______________________ > > > > > > William Ottaway wrote: > > > > > > > Jim, > > > > > > > > I think I'm inferring what is done. :-) > > > > > > > > My only gripe is I don't like the statement "This format can > > > also be used to > > > > convey CRLs." followed by a description of how to carry > > > certificates but no > > > > description of how to carry CRLs in a similar format. > > > > > > > > Its too late to change RFC 2633 but draft-ietf-smime-x400trans could > say > > > > something different. > > > > > > > > 1) Don't mention that CRLs can be carried in a similar way to a > > > certs only > > > > message > > > > > > > > or > > > > > > > > 2) Specify an OID for a CRL only message. > > > > > > > > Bill. > > > > > > > > >
- Certs-only Mechanism for X.400 Transport Bonatti, Chris
- RE: Certs-only Mechanism for X.400 Transport William Ottaway
- Re: Certs-only Mechanism for X.400 Transport Bonatti, Chris
- RE: Certs-only Mechanism for X.400 Transport William Ottaway
- Re: Certs-only Mechanism for X.400 Transport Bonatti, Chris
- RE: Certs-only Mechanism for X.400 Transport Jim Schaad
- RE: Certs-only Mechanism for X.400 Transport William Ottaway
- Re: Certs-only Mechanism for X.400 Transport Bonatti, Chris
- RE: Certs-only Mechanism for X.400 Transport William Ottaway
- RE: Certs-only Mechanism for X.400 Transport Russ Housley
- RE: Certs-only Mechanism for X.400 Transport Blake Ramsdell
- RE: Certs-only Mechanism for X.400 Transport William Ottaway
- RE: Certs-only Mechanism for X.400 Transport Blake Ramsdell