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

[Jim Schaad <[e-mail]>]

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

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!

[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)

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

[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