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

[Daniel Kahn Gillmor <[e-mail]>]

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