RE: Certs-only Mechanism for X.400 Transport

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.

> -----Original Message-----
> From: Jim Schaad [mailto:jimsch5(_at_)home(_dot_)com]
> Sent: 23 February 2001 15:44
> To: 'William Ottaway'; 'Bonatti, Chris'
> Cc: ietf-smime(_at_)imc(_dot_)org
> Subject: RE: Certs-only Mechanism for X.400 Transport
>
>
> Bill,
>
> I think you are over infering what is done.  While it would be possible to
> define a CRLs only message nobody has done so todate.  At this
> point in time
> CRLs are distributed (for S/MIME) either in a signed/encrypted
> message (with
> content) or the client is responsable to finding the CRL by following CDPs
> and the like.
>
> jim
>
> -----Original Message-----
> From: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
> [mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org]On Behalf Of William 
> Ottaway
> Sent: Thursday, February 22, 2001 9:08 AM
> To: Bonatti, Chris
> Cc: ietf-smime(_at_)imc(_dot_)org
> Subject: RE: Certs-only Mechanism for X.400 Transport
>
>
> Chris,
>
> RFC 2633 hints that CRLs can be sent in a similar format to a cert only
> message. It then states that for a cert only message the smime type is
> "certs-only".
>
> I interpret the text in 3.6 of RFC 2633 as telling me that a CRL only
> message could be sent in a similar way as the cert only message but would
> have a "crl-only" smime type.
>
> I can't comment on how CRLs are commonly sent.
>
> If you don't believe that you will use the same mechanism to
> transport CRLs
> as certs I would suggest removing the text "This format can also
> be used to
> convey CRLs".
>
> Bill.
>
> > -----Original Message-----
> > From: Bonatti, Chris [mailto:BonattiC(_at_)ieca(_dot_)com]
> > Sent: 21 February 2001 17:26
> > To: William Ottaway
> > Cc: ietf-smime(_at_)imc(_dot_)org
> > Subject: Re: Certs-only Mechanism for X.400 Transport
> >
> >
> > Bill,
> >
> >     I would not object to this myself, but it differs from the
> > treatment in
> > RFC 2633.  Also, I don't think CRLs are commonly sent using this
> > mechanism, so
> > I wonder about whether it's a scenario worth optimizing for.
> >
> > Chris
> >
> >
> > ____________________
> >
> > William Ottaway wrote:
> >
> > > Chris,
> > >
> > > Rather than state "This format can also be used to convey CRLs
> > " how about
> > > specifying an OID for CRLs and describing how a CRL is
> transported, this
> > > could be in a separate section or you could describe CRL and
> certificate
> > > transport in the same section, as the only difference will be the OID.
> > >
> > > Bill.
> > >
> > > > -----Original Message-----
> > > > From: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
> > > > [mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org]On Behalf Of 
> > > > Bonatti, Chris
> > > > Sent: 20 February 2001 15:22
> > > > To: ietf-smime(_at_)imc(_dot_)org
> > > > Subject: Certs-only Mechanism for X.400 Transport
> > > >
> > > >
> > > >     Some discussion after the December meeting, suggested that we
> > > > revise the specification for transporting S/MIME objects in X.400
> > > > (draft-ietf-smime-x400trans) to enable certs-only messages to be
> > > > readily identified.  This responds to the assumption that the
> > > > PKCS #10 certificate request may be adapted to and used in the
> > > > X.400 environment.  I admittedly didn't go down this road in my
> > > > thinking, but it seems plausible enough.
> > > >
> > > >     After elaborating all the options (and doing some significant
> > > > consultation with X.400 wonks) I recommend that we use the
> > > > Encoded Information Types (EITs) facility of X.400 to distinguish
> > > > the certs-only messages.  This mechanism is non-invasive to the
> > > > security function, well-suited to the job at hand, and well
> > > > supported in the X.400 community.  The main impact to x400trans
> > > > spec is that we define a new OID value to represent the new
> > > > "certs-only" EIT.  To that end, I propose that the following new
> > > > section (see below) be inserted in the spec.
> > > >
> > > >     Discussion on this point is, of course, welcome.
> > > >
> > > > Chris
> > > >
> > > >
> > > > ____________________
> > > >
> > > > 2.5 Certificates-only Message
> > > >
> > > > The certificates-only message is used to transport certificates,
> > > > such as in response to a registration request.  This format can
> > > > also be used to convey CRLs.  The certificates-only message
> > > > consists of a single instance of CMS content of type
> > > > Signed-data.  The encapContentInfo eContent field MUST be absent
> > > > and signerInfos field MUST be empty.
> > > >
> > > > The resulting certificates-only CMS content is conveyed in
> > > > accordance with section 2.2.  The following OID value is defined
> > > > to identify certificates-only messages in the X.400 transport
> > > > environment.
> > > >
> > > >     id-eit-certsOnly  OBJECT IDENTIFIER ::=
> > > >         { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
> > > >         pkcs-9(9) smime(16) eits(***) certsOnly(1) }
> > > >
> > > > Sending agents SHOULD include this OID in the
> > > > original-encoded-information-types (EITs) field of the X.400
> > > > message envelope.  Receiving agents SHOULD recognize the this OID
> > > > value in the EITs field, and process the certificates-only
> > > > appropriately according to local procedures.