Thanks both of you for the feedback.
I've revised the PR: https://github.com/tlswg/tls-subcerts/pull/9 There's now a "strict" flag that, if set, requires the server to offer a DC.. In Sec. 6.1, I describe why I think this is sufficient. Let me know what you think! Best, Chris ________________________________ From: Santosh Chokhani <santosh.chokh...@gmail.com> Sent: Wednesday, July 18, 2018 6:00 PM To: Patton,Christopher J; 'Ilari Liusvaara' Cc: tls@ietf.org Subject: RE: [TLS] Proposed changes to draft-ietf-tls-subcerts 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-2Dsubcerts_pull_8&d=DwIBaQ&c=pZJPUDQ3SB9JplYbifm4nt2lEVG5pWx2KikqINpWlZM&r=VKs6yUchJieNTSwm3Abwfg&m=RriZv_awLgJt5QVpMsfl0UuiFCDoqBxniQnDZR8n5dA&s=Jkn0aWEFHUhGyKTRFXHGPt7fdDUvxeXGJQkwmPR2HdU&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-2Dsubcerts_pull_9&d=DwIBaQ&c=pZJPUDQ3SB9JplYbifm4nt2lEVG5pWx2KikqINpWlZM&r=VKs6yUchJieNTSwm3Abwfg&m=RriZv_awLgJt5QVpMsfl0UuiFCDoqBxniQnDZR8n5dA&s=lsmtgnR-B-sA-BU_CcpbAtB7UC4Q0zyFqOLOGB3-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-2Dsubcerts_pull_10&d=DwIBaQ&c=pZJPUDQ3SB9JplYbifm4nt2lEVG5pWx2KikqINpWlZM&r=VKs6yUchJieNTSwm3Abwfg&m=RriZv_awLgJt5QVpMsfl0UuiFCDoqBxniQnDZR8n5dA&s=Q1-PUQoj_LL4tFA4UPxTUiiUNRYfsdAf9nhNCaAItZY&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
