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 TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
