Thank you for the review, Sofía. I'm looking forward to the PR. Once that lands we'll submit a version of the doc with WGLC#2 comments incorporated.
Nick On Thu, Aug 13, 2020 at 12:35 AM Sofía Celi <[email protected]> wrote: > Dear, list, > > Sorry for sending this past the last call. > > Few comments on the draft, which are: > > - On Section 1: > > "For clarity, we will refer to the certificate issued by the CA as a > "certificate", or "delegation certificate", and the one issued by the > operator as a "delegated credential" or "DC"." > > I think this sentence can be their own paragraph, so it does not get > lost with the rest of the text. It will be good to clarify as well the > usage of 'credential', 'delegation', 'delegator' terms used through out > the document. It will be really nice to clarify the term 'credential' as > it sometimes seems to be used to refer to 'delegated credential', and > sometimes to the 'Credential' struct. > > - On section 7.3 > > "Delegated credentials do not provide any additional form of early > revocation. Since it is short lived, the expiry of the delegated > credential would revoke the credential. Revocation of the long term > private key that signs the delegated credential also implicitly > revokes the delegated credential." > > Not sure how the implicit revocation will work. It is my understanding > that the sole way to check that a DC is revoked is by verifying its > valid time, and this is the way that renders it 'invalid'. > Maybe, the DC is valid until it expires regardless if the long-term > private key is revoked, as I don't see a way to mark the DC invalid when > the long-term private key revokes. But perhaps, I'm understanding this > incorrectly. > > In that case, how the DC signed by a revoked key will be treated? Should > it wait until they expire to render them completely explicitly invalid? > > > I have other minor editorial changes that I'll send as a PR. > > Thanks! > > > > > > -- > Sofía Celi > @claucece > http://claucece.github.io/ > Cryptographic research and implementation at many places, but mainly at > Cloudflare > FAB9 3EDC 7CDD 1198 DCFD 4558 91BB 6B45 6F44 2D02 > > _______________________________________________ > TLS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
