|
RE: Certs-only Mechanism for X.400 Transport
2001-02-22 10:03:16
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.
|
|