Subject: Certs-only Mechanism for X.400 Transport

From: "Bonatti, Chris" <[email-masked]>
Date: Tue, 20 Feb 2001 10:21:55 -0500

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.

---

From: "William Ottaway" <[email-masked]>
Date: Tue, 20 Feb 2001 16:19:25 -0000

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: [email-masked]
> [mailto:[email-masked]]On Behalf Of Bonatti, Chris
> Sent: 20 February 2001 15:22
> To: [email-masked]
> Subject: Certs-only Mechanism for X.400 Transport
>
>

---

From: "Bonatti, Chris" <[email-masked]>
Date: Wed, 21 Feb 2001 12:26:07 -0500

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

____________________

---

From: "William Ottaway" <[email-masked]>
Date: Thu, 22 Feb 2001 17:07:43 -0000

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.

> From: Bonatti, Chris [mailto:[email-masked]]
> Sent: 21 February 2001 17:26
> To: William Ottaway
> Cc: [email-masked]
> Subject: Re: Certs-only Mechanism for X.400 Transport
>
>
> Bill,
>

---

From: "Bonatti, Chris" <[email-masked]>
Date: Thu, 22 Feb 2001 13:25:42 -0500

Bill,

What 3.6 says seems pretty clear.  It says:

> 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.
>

This seems pretty clear that they are the same format.  It then goes on to say
that the certs-only format is an empty 'SignedData' structure.  So if this were
to be used for CRLs, I would make the inference that the 'certificates' and
'crls' fields of the 'signedData' should be used.

Chris

_____________________

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 23 Feb 2001 07:43:50 -0800

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: [email-masked]
[mailto:[email-masked]]On Behalf Of William Ottaway
Sent: Thursday, February 22, 2001 9:08 AM
To: Bonatti, Chris
Cc: [email-masked]
Subject: RE: Certs-only Mechanism for X.400 Transport

Chris,

Bill.

---

From: "William Ottaway" <[email-masked]>
Date: Fri, 23 Feb 2001 16:03:26 -0000

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.

> From: Jim Schaad [mailto:[email-masked]]
> Sent: 23 February 2001 15:44
> To: 'William Ottaway'; 'Bonatti, Chris'
> Cc: [email-masked]

---

From: "Bonatti, Chris" <[email-masked]>
Date: Mon, 26 Feb 2001 11:09:42 -0500

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

_______________________

---

From: "William Ottaway" <[email-masked]>
Date: Mon, 26 Feb 2001 16:30:19 -0000

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.

> Sent: 26 February 2001 16:10
> To: William Ottaway
> Cc: [email-masked]; [email-masked]

---

From: Russ Housley <[email-masked]>
Date: Wed, 28 Feb 2001 08:57:10 -0500

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