Suppose that strict delegation usage is required (strict=true). Is it valid for the extension to be non-critical (crit=false)? No, because the server has to serve a DC, even if the client doesn't request one. Thus, strict=true implies that crit=true.
Now let's check the converse. Suppose that the crit=true. Is it valid for strict to be false? Yes, because the extension being critical only means that the client has to understand DC in order to accept the certificate. But this doesn't mean they must negotiate a DC. So I agree with one case you point out: If strict delegation usage is required, then the extension must be critical. However, if the extension is critical, both strict and non-strict delegation usage are valid. Do you agree? If so, I'll amend the draft accordingly. Chris ________________________________ From: ilariliusva...@welho.com <ilariliusva...@welho.com> on behalf of Ilari Liusvaara <ilariliusva...@welho.com> Sent: Thursday, July 19, 2018 4:18 PM To: Patton,Christopher J Cc: Santosh Chokhani; tls@ietf.org Subject: Re: [TLS] Proposed changes to draft-ietf-tls-subcerts On Thu, Jul 19, 2018 at 07:56:05PM +0000, Patton,Christopher J wrote: > So you think we need that the extension is marked critical if and > only if the strict flag is set? That wouldn't be ideal. Can you > explain your thinking? Which case presents a problem? There are two types of clients: 1) Clients that do not know about DC. - These clients never use DC. - These do not understand the DC extension. - If you want non-strict certificate, it has to have critical=false on DC extension. - If you want strict certificate, it has to have critical=true on DC extension. 2) Clients that support DC. - These clients may or may not use DC. - These understand the DC extension. - As consequence, criticality of DC extension is ignored by X.509 rules. - So to specify if certificate is strict, you need a flag inside the extension. And in the end, the two flags always end up mirroring each other, but signifying different things. -Ilari
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
