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

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

On Sun 2019-11-24 20:46:42 -0800, Jim Schaad wrote:
> 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