> Because it means that if the client does not understand DC, then it must > reject the certificate, ...
This is the desired behavior, as far as I understand. > ... but if client understands DC, it can accept it even in non-DC contexts. I don't see why this is nonsensical. One way to understand this is that the server is presenting a certificate that it only wants to use with DC-capable clients. Perhaps noone would want to actually use this configuration, but I don't see why it should be deemed invalid. > The other mismatch case also has well-defined technical meaning, it > means that client that does not understand DC can use the certificate, > but client that understands DC can only use it in DC context. I don't quite understand. The issue I believe you pointed out is that when the extension is non-critical, but the strict flag is set, the server will be compelled to serve a DC even if the client doesn't support it. The relevant text (you'll have to look at the source on GitHub) is: "The extension MAY be marked crititcal. (See Section 4.2 of [RFC5280].) If the strict boolean is set to true, then the server MUST use delegated credential in the handshake; if no delegated credential is offered, then the client MUST abort the handshake with an “illegal_parameter” alert." A client who doesn't speak DC will either abort with an "unexpected_message" alert, or if it ignores the extension, then verification of the handshake will fail, since it's using the end-entity certificate public key, and not the DC public key. Thus, I believe the only valid configurations are: * strict=true, crit=true; * strict=false, crit=true; and * strict=false, crit=false. The revised text should be: "If the strict boolean is set to true, then the extension MUST be marked critical; otherwise it MAY be marked non-crititcal. If the strict boolean is set to true, then the server MUST use delegated credential in the handshake; if no delegated credential is offered, then the client MUST abort the handshake with an “illegal_parameter” alert. -Chris
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
