Subject: [lamps] Advertising S/MIME capabilities in a certificate?

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 22 Nov 2019 19:07:53 +0800

Hi folks--

It occurs to me that i'd like at least one of the certificates in
https://www.ietf.org/id/draft-dkg-lamps-samples-01.html to announce some
SMIMECapabilities.  For example, maybe it could advertise that it is
capable of handling a PKCS#7 Compression layer?  Or that it is capable
of processing authEnveloped-data?

However, reading RFC 8551 and related specs i realize how rusty my ASN.1
is (and my knowledge of CMS is so paltry that there was never even
enough of it to rust).

It looks to me like S/MIME capabilities are never advertised in the cert
itself, but rather expected to be included as a signedAttribute in a
signedData object.  Is that right?  Is there no way that the
advertisement can be included in the certificate?

I suppose if the advertisement could be included in both the signedData
object *and* the certificate itself then the algorithm in §2.7.1 of RFC
8551 would need to be much more complicated.

Any pointers or examples would be welcome,

              --dkg

---

From: Dmitry Belyavsky <[email-masked]>
Date: Sat, 23 Nov 2019 17:34:03 +0300

Dear Daniel,

> advertisement can be included in the certificate?

OpenSSL adds a fixed list of ciphers and digests as S/MIME capabilities not
looking at the certificate.

-- 
SY, Dmitry Belyavsky

---

From: Jim Schaad <[email-masked]>
Date: Sun, 24 Nov 2019 20:46:42 -0800

You are looking for RFC 4262

-----Original Message-----
From: Spasm <[email-masked]> On Behalf Of Daniel Kahn Gillmor
Sent: Friday, November 22, 2019 3:08 AM
To: LAMPS WG <[email-masked]>
Subject: [lamps] Advertising S/MIME capabilities in a certificate?

Hi folks--

It occurs to me that i'd like at least one of the certificates in https://www.ietf.org/id/draft-dkg-lamps-samples-01.html to announce some SMIMECapabilities.  For example, maybe it could advertise that it is capable of handling a PKCS#7 Compression layer?  Or that it is capable of processing authEnveloped-data?

However, reading RFC 8551 and related specs i realize how rusty my ASN.1 is (and my knowledge of CMS is so paltry that there was never even enough of it to rust).

It looks to me like S/MIME capabilities are never advertised in the cert itself, but rather expected to be included as a signedAttribute in a signedData object.  Is that right?  Is there no way that the advertisement can be included in the certificate?

I suppose if the advertisement could be included in both the signedData object *and* the certificate itself then the algorithm in §2.7.1 of RFC
8551 would need to be much more complicated.

              --dkg

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 26 Nov 2019 01:18:01 -0500

> You are looking for RFC 4262

Thanks, Jim.

I see that the X.509v3 extension OID in RFC 4262 has been subsumed in
RFC 8551 (though it isn't clear to me from reading RFC 8551 that this is
the purpose of the OID).

Do you have an example X.509 certificate that contains an indicator that
the certificate holder can handle (some form of) S/MIME compression?
I'm trying to make sense of how that would be structured.

i'm not sure why the extension itself appears to contain a SEQUENCE of
SMIMECapability objects, and yet each SMIMECapability object itself
contains a sequence of capabilityID and parameters.

Why two layers of indirection there?

also, it's not clear to me how the SMIMECapability objects that are
present in the X.509 certificate are supposed to be merged with the most
recently-seen set of capabilities in a signed message.  That is, §2.7.1
of RFC 8551 presents an algorithm for selecting an encryption
ciphersuite (and presumably can also be used for things like deciding
whether to compress any objects).  But the algorithm doesn't take into
account any capability objects seen on the certificate itself.

Does the presence of a capability in a certificate supercede the most
recent in-message advertisement?  does the *absence* of a capability in
a certificate supercede the most recent in-message advertisement?

How are implementers supposed to handle this?  It's possible i'm just
not reading these document well -- i'd appreciate pointers to any text
or references that clear up any of the above confusions.

Regards,

        --dkg

---

From: Jim Schaad <[email-masked]>
Date: Tue, 26 Nov 2019 11:59:13 -0800

-----Original Message-----
From: Spasm <[email-masked]> On Behalf Of Daniel Kahn Gillmor
Sent: Monday, November 25, 2019 10:18 PM
To: Jim Schaad <[email-masked]>; 'LAMPS WG' <[email-masked]>
Subject: Re: [lamps] Advertising S/MIME capabilities in a certificate?

Thanks, Jim.

I see that the X.509v3 extension OID in RFC 4262 has been subsumed in RFC 8551 (though it isn't clear to me from reading RFC 8551 that this is the purpose of the OID).

[JLS] Aaah - no,  The OID was defined for the message format first and was kept as the identifier for RFC 4262.  If it had been consumed into a new S/MIME draft it would have been RFC 8550.  It was defined way back in the days of RFC 2633 because we needed to solve the problems with export control and RC2 so that a common version could be agreed on.  It was also setup to deal with the RC2 only export versions and domestic 3DES agreement.

Do you have an example X.509 certificate that contains an indicator that the certificate holder can handle (some form of) S/MIME compression?
I'm trying to make sense of how that would be structured.

i'm not sure why the extension itself appears to contain a SEQUENCE of SMIMECapability objects, and yet each SMIMECapability object itself contains a sequence of capabilityID and parameters.

[JLS] Welcome the structure of a Signed Attribute.  There are two different things that are causing the wrapping.  The signed attribute definition and the SMIMECapabilities definition.  In section 2.5.2 it stays that there can only be one item in the outer sequence so there are not multiple sequences defined.  If this was not done then a merge method of trying to figure out priorities would have had to be defined.  Making it be a single sequence makes prioritization easier to defined.

also, it's not clear to me how the SMIMECapability objects that are present in the X.509 certificate are supposed to be merged with the most recently-seen set of capabilities in a signed message.  That is, §2.7.1 of RFC 8551 presents an algorithm for selecting an encryption ciphersuite (and presumably can also be used for things like deciding whether to compress any objects).  But the algorithm doesn't take into account any capability objects seen on the certificate itself.

[JLS] That should potentially have been thought about in RFC 4262.  The algorithm for RFC 8551 is always replace.  If I was implementing this I would either define it as the message replaces the certificate or the certificate replaces the message.  At this point I would not know which way I would go as I have not thought it through.  First guess is that the certificate always wins.  This was defined some 6 years after I stopped working on mail at Microsoft.

Jim

Does the presence of a capability in a certificate supercede the most recent in-message advertisement?  does the *absence* of a capability in a certificate supercede the most recent in-message advertisement?

How are implementers supposed to handle this?  It's possible i'm just not reading these document well -- i'd appreciate pointers to any text or references that clear up any of the above confusions.

Regards,

        --dkg

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 26 Nov 2019 18:00:52 -0500

On Tue 2019-11-26 11:59:13 -0800, Jim Schaad wrote:
>  [ re: multiple layers of sequences ]
> Welcome the structure of a Signed Attribute.  There are two different
> things that are causing the wrapping.  The signed attribute definition
> and the SMIMECapabilities definition.  In section 2.5.2 it stays that
> there can only be one item in the outer sequence so there are not
> multiple sequences defined.  If this was not done then a merge method
> of trying to figure out priorities would have had to be defined.
> Making it be a single sequence makes prioritization easier to defined.

OK, thanks for the pointer and the hint, i hadn't really understood that
from reading §2.5.2 the first time, but i see how it can be read that
way now :)

Are there any examples?  An example certificate would be really nice to
have as a demonstration!

draft-dkg-lamps-samples uses certtool (from GnuTLS) to create its
example certificates, but it looks like certtool can't currently
generate the right extensions in the certificate.  I've opened
https://gitlab.com/gnutls/gnutls/issues/863 to ask for such an
extension.

If anyone knows of another implementation that supports these capability
extensions, please let me know so that i can record it in that feature
request, as GnuTLS upstream likes to know what other implementations
provide it (presumably for interop testing)

> [ re: juggling capabilities discovered in certificates and messages ]
> That should potentially have been thought about in RFC 4262.  The
> algorithm for RFC 8551 is always replace.  If I was implementing this
> I would either define it as the message replaces the certificate or
> the certificate replaces the message.  At this point I would not know
> which way I would go as I have not thought it through.  First guess is
> that the certificate always wins.

Hm, that's interesting -- if certificate always wins, then it becomes
impossible for a client with any capabilities in the cert to announce
new capabilities based on a software upgrade.  right?

I was thinking that a union of the capabilities between the certificate
and the most-recently-received signed message would make the most sense
from a deployment perspective, but i agree that it would be good to have
that documented.

     --dkg

---

From: Jim Schaad <[email-masked]>
Date: Tue, 26 Nov 2019 19:17:34 -0800

-----Original Message-----
From: Daniel Kahn Gillmor <[email-masked]> 
Sent: Tuesday, November 26, 2019 3:01 PM
To: Jim Schaad <[email-masked]>; 'LAMPS WG' <[email-masked]>
Subject: RE: [lamps] Advertising S/MIME capabilities in a certificate?

> Making it be a single sequence makes prioritization easier to defined.

OK, thanks for the pointer and the hint, i hadn't really understood that from reading §2.5.2 the first time, but i see how it can be read that way now :)

Are there any examples?  An example certificate would be really nice to have as a demonstration!

[JLS] I am not aware of one.  As Stefan was at Microsoft at the time, I assume that they may have issued some, but it would be easy to just create a template with the extension in it so that no special work would be needed on the client side to generate or for the server to decide if to include it.

draft-dkg-lamps-samples uses certtool (from GnuTLS) to create its example certificates, but it looks like certtool can't currently generate the right extensions in the certificate.  I've opened
https://gitlab.com/gnutls/gnutls/issues/863 to ask for such an extension.

If anyone knows of another implementation that supports these capability extensions, please let me know so that i can record it in that feature request, as GnuTLS upstream likes to know what other implementations provide it (presumably for interop testing)

> that the certificate always wins.

Hm, that's interesting -- if certificate always wins, then it becomes impossible for a client with any capabilities in the cert to announce new capabilities based on a software upgrade.  right?

I was thinking that a union of the capabilities between the certificate and the most-recently-received signed message would make the most sense from a deployment perspective, but i agree that it would be good to have that documented.

[JLS] I think that this depends on who you believe should be able to control things.   A company will want to restrict what is to be used even if the client is advertising that it can do additional things.  The company would be more than willing to re-issue new certificates as needed if the set of algorithms is changing.  On the other hand an individual is much more likely to just use messages to send capabilities and not assume that people are going to be able to find certificates from some type of "global" repository in order to find out what capabilities exist.

Jim

     --dkg

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 27 Nov 2019 10:25:32 -0500

On Tue 2019-11-26 19:17:34 -0800, Jim Schaad wrote:
> I am not aware of one.  As Stefan was at Microsoft at the time, I
> assume that they may have issued some, but it would be easy to just
> create a template with the extension in it so that no special work
> would be needed on the client side to generate or for the server to
> decide if to include it.

Right, but this is contingent on agreeing on what the actual byte
sequence is that would represent such a certificate.  While we have the
spec, a concrete test vector goes a long way toward ensuring that
different implementers actually agree on how to interpret the spec.

> I think that this depends on who you believe should be able to control
> things.  A company will want to restrict what is to be used even if
> the client is advertising that it can do additional things.  The
> company would be more than willing to re-issue new certificates as
> needed if the set of algorithms is changing.

I imagine that a company's willingness to re-issue might depend on how
expensive it is (in terms of $$, and in terms of employee time and
expertise, and in terms of management overhead) to issue a new
certificate.  Consider also that certificate re-issuance opens the
question of expiration dates, etc (i.e. should the new certificate
expire at the same time as the old one?  or should it expire the same
duration *from issuance* as the old one?).  None of these are super
challenging decisions, but they are operational decisions to make, and
they require input/time from different staff, which increases the
management overhead.

> On the other hand an individual is much more likely to just use
> messages to send capabilities and not assume that people are going to
> be able to find certificates from some type of "global" repository in
> order to find out what capabilities exist.

sure, but "find certificates from a global repo" only matters for
sending mail having never received anything from the peer.  Once the
sender has received at least one message from the peer, they have this
potential capability conflict to resolve.

I suppose when an individual is sending messages, the sent message will
include the certificate as well, so the sender can always just copy the
capability set from the certificate into the message if they want to
absolve the peer from grappling with this issue.

But if the capability set in the message *differs* from the capability
set in the certificate, the fact that no well-defined policy exists for
the recipient to disambiguate seems like a problem for the ecosystem.

So far, in this thread, three possible disambiguation policies have been
mentioned, all with different results for the recipient:

Given the most-recently received message that announces S/MIME
capabilities and a certificate which also advertises S/MIME
capabilities:

  - use S/MIME capabilities from certificate
  - use S/MIME capabilities from the message
  - use the union of S/MIME capabilities from the certificate and the message

(of course, there might be others).

Is there some reason that we shouldn't try to specify one of these as
the expected canonical disambiguation?  Should we provide guidance to
MUAs about what capabilities to announce in messages that they send with
a given certificate that also contains capabilities?

    --dkg