I do not think you can change an extension syntax or semantic. It is three tuple: extn ID, criticality flag, and value.
You can add the syntax and semantics within the extension value as to what it means. That may not help those who do not understand the extension and cannot process the value. From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Patton,Christopher J Sent: Wednesday, July 18, 2018 1:33 PM To: Ilari Liusvaara <ilariliusva...@welho.com> Cc: tls@ietf.org Subject: Re: [TLS] Proposed changes to draft-ietf-tls-subcerts Hi Ilari, I suppose you mean that this condition violates the critical bit semantics: "If the extension is marked critical, then the server MUST NOT offer the certificate unless it offers a delegated credential as well." Your suggesting adding a "must-use-DC" flag to the extension body? The condition would be: "If the <must-use-DC> flag of the extension is set, then the server MUST NOT offer the certificate unless ..." _____ From: ilariliusva...@welho.com <mailto:ilariliusva...@welho.com> <ilariliusva...@welho.com <mailto:ilariliusva...@welho.com> > on behalf of Ilari Liusvaara <ilariliusva...@welho.com <mailto:ilariliusva...@welho.com> > Sent: Wednesday, July 18, 2018 2:56 AM To: Patton,Christopher J Cc: tls@ietf.org <mailto:tls@ietf.org> Subject: Re: [TLS] Proposed changes to draft-ietf-tls-subcerts On Wed, Jul 18, 2018 at 01:17:44AM +0000, Patton,Christopher J wrote: > Hi all, > > > I've added a few pull requests to the draft "Delegated credentials for TLS" that address the proposals discussed at IETF. > > Specifically: > > * https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_tlswg_tls-2D subcerts_pull_8 <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_tlswg_tls-2 Dsubcerts_pull_8&d=DwIBaQ&c=pZJPUDQ3SB9JplYbifm4nt2lEVG5pWx2KikqINpWlZM&r=VK s6yUchJieNTSwm3Abwfg&m=RriZv_awLgJt5QVpMsfl0UuiFCDoqBxniQnDZR8n5dA&s=Jkn0aWE FHUhGyKTRFXHGPt7fdDUvxeXGJQkwmPR2HdU&e=> &d=DwIBaQ&c=pZJPUDQ3SB9JplYbifm4nt2lEVG5pWx2KikqINpWlZM&r=VKs6yUchJieNTSwm3A bwfg&m=RriZv_awLgJt5QVpMsfl0UuiFCDoqBxniQnDZR8n5dA&s=Jkn0aWEFHUhGyKTRFXHGPt7 fdDUvxeXGJQkwmPR2HdU&e= -- Creates a tighter binding of the DC to the handshake parameters; > * https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_tlswg_tls-2D subcerts_pull_9 <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_tlswg_tls-2 Dsubcerts_pull_9&d=DwIBaQ&c=pZJPUDQ3SB9JplYbifm4nt2lEVG5pWx2KikqINpWlZM&r=VK s6yUchJieNTSwm3Abwfg&m=RriZv_awLgJt5QVpMsfl0UuiFCDoqBxniQnDZR8n5dA&s=lsmtgnR -B-sA-BU_CcpbAtB7UC4Q0zyFqOLOGB3-FZM&e=> &d=DwIBaQ&c=pZJPUDQ3SB9JplYbifm4nt2lEVG5pWx2KikqINpWlZM&r=VKs6yUchJieNTSwm3A bwfg&m=RriZv_awLgJt5QVpMsfl0UuiFCDoqBxniQnDZR8n5dA&s=lsmtgnR-B-sA-BU_CcpbAtB 7UC4Q0zyFqOLOGB3-FZM&e= -- Permits mandatory delegation-key isolation, addresses the proposed"must-use-DC" TLS feature extension; > * https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_tlswg_tls-2D subcerts_pull_10 <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_tlswg_tls-2 Dsubcerts_pull_10&d=DwIBaQ&c=pZJPUDQ3SB9JplYbifm4nt2lEVG5pWx2KikqINpWlZM&r=V Ks6yUchJieNTSwm3Abwfg&m=RriZv_awLgJt5QVpMsfl0UuiFCDoqBxniQnDZR8n5dA&s=Q1-PUQ oj_LL4tFA4UPxTUiiUNRYfsdAf9nhNCaAItZY&e=> &d=DwIBaQ&c=pZJPUDQ3SB9JplYbifm4nt2lEVG5pWx2KikqINpWlZM&r=VKs6yUchJieNTSwm3A bwfg&m=RriZv_awLgJt5QVpMsfl0UuiFCDoqBxniQnDZR8n5dA&s=Q1-PUQoj_LL4tFA4UPxTUii UNRYfsdAf9nhNCaAItZY&e= -- drops support for TLS 1.2. > > Comments on these changes are welcome; feel free to chime in on GitHub.. The way mandatory delegation-key usage is specified seems to violate how X.509 critical bit is supposed to work. The bit is not supposed to alter processing of recogized extensions, it is only supposed to alter processing of unrecognized extensions from ignore to reject. If you want to actually alter the processing to require such certificate to always only be used for DC, you need a flag somewhere else, which might be payload of the extension (and that extension should _also_ be marked critical to ensure that clients that do not understand DC do not accept it). -Ilari
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
