Hi, It is unclear to me if the current version is expected to address the comments received during the WGLCs or if further versions are expected. Just to clarify the current version does not address my comments concerning the related work section [1].
Yours, Daniel [1] https://mailarchive.ietf.org/arch/msg/tls/B7qc2sPH_d9Tfr-W7vnf24jiGds/ On Sun, Jan 31, 2021 at 11:59 PM Sean Turner <s...@sn3rd.com> wrote: > Do you think this would be clearer: > > The maximum validity period is set to 7 days unless > an application profile standard specifies a shorter > period. > > spt > > > On Jan 25, 2021, at 11:14, Russ Housley <hous...@vigilsec.com> wrote: > > > > I have reviewed the recent update, and I notice one inconsistency. > > > > Section 2 says: > > > > In the absence of an application profile standard > > specifying otherwise, the maximum validity period is set to 7 days. > > > > Section 4.1.3 says: > > > > 1. Validate that DelegatedCredential.cred.valid_time is no more than > > 7 days. > > > > I think that Section 2 is trying to say that an application profile can > make it even shorter than 7 days, but on my first reading I got the > opposite. > > > > Russ > > > > > >> On Jan 24, 2021, at 6:03 PM, internet-dra...@ietf.org wrote: > >> > >> > >> A New Internet-Draft is available from the on-line Internet-Drafts > directories. > >> This draft is a work item of the Transport Layer Security WG of the > IETF. > >> > >> Title : Delegated Credentials for TLS > >> Authors : Richard Barnes > >> Subodh Iyengar > >> Nick Sullivan > >> Eric Rescorla > >> Filename : draft-ietf-tls-subcerts-10.txt > >> Pages : 19 > >> Date : 2021-01-24 > >> > >> Abstract: > >> The organizational separation between the operator of a TLS endpoint > >> and the certification authority can create limitations. For example, > >> the lifetime of certificates, how they may be used, and the > >> algorithms they support are ultimately determined by the > >> certification authority. This document describes a mechanism by > >> which operators may delegate their own credentials for use in TLS, > >> without breaking compatibility with peers that do not support this > >> specification. > >> > >> > >> The IETF datatracker status page for this draft is: > >> https://datatracker.ietf.org/doc/draft-ietf-tls-subcerts/ > >> > >> There are also htmlized versions available at: > >> https://tools.ietf.org/html/draft-ietf-tls-subcerts-10 > >> https://datatracker.ietf.org/doc/html/draft-ietf-tls-subcerts-10 > >> > >> A diff from the previous version is available at: > >> https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-subcerts-10 > >> > >> > >> Please note that it may take a couple of minutes from the time of > submission > >> until the htmlized version and diff are available at tools.ietf.org. > >> > >> Internet-Drafts are also available by anonymous FTP at: > >> ftp://ftp.ietf.org/internet-drafts/ > >> > >> > >> _______________________________________________ > >> TLS mailing list > >> TLS@ietf.org > >> https://www.ietf.org/mailman/listinfo/tls > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- Daniel Migault Ericsson
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
