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

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

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