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(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org]On Behalf Of Blake
Ramsdell
Sent: 28 February 2001 20:36
To: 'Russ Housley'; William Ottaway
Cc: Bonatti, Chris; jimsch(_at_)exmsft(_dot_)com;
ietf-smime(_at_)imc(_dot_)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(_at_)spyrus(_dot_)com]
Sent: Wednesday, February 28, 2001 5:57 AM
To: William Ottaway
Cc: Bonatti, Chris; jimsch(_at_)exmsft(_dot_)com;
ietf-smime(_at_)imc(_dot_)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(_at_)ieca(_dot_)com]
Sent: 26 February 2001 16:10
To: William Ottaway
Cc: jimsch(_at_)exmsft(_dot_)com; ietf-smime(_at_)imc(_dot_)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.