RE: Certs-only Mechanism for X.400 Transport

["Blake Ramsdell" <[e-mail]>]

Sounds good -- we'll rewrite it at some point.

Blake

-----Original Message-----
From: William Ottaway [mailto:[e-mail]]
Sent: Thursday, March 01, 2001 1:11 AM
To: Blake Ramsdell; 'Russ Housley'
Cc: Bonatti, Chris; [e-mail]; [e-mail]
Subject: RE: Certs-only Mechanism for X.400 Transport


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: [e-mail]
> [mailto:[e-mail]]On Behalf Of Blake Ramsdell
> Sent: 28 February 2001 20:36
> To: 'Russ Housley'; William Ottaway
> Cc: Bonatti, Chris; [e-mail]; [e-mail]
> 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:[e-mail]]
> Sent: Wednesday, February 28, 2001 5:57 AM
> To: William Ottaway
> Cc: Bonatti, Chris; [e-mail]; [e-mail]
> 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:[e-mail]]
> > > Sent: 26 February 2001 16:10
> > > To: William Ottaway
> > > Cc: [e-mail]; [e-mail]
> > > 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.
> > > >
> > >
>
>