[Trans] Murray Kucherawy's No Objection on draft-ietf-trans-rfc6962-bis-38: (with COMMENT)

Murray Kucherawy has entered the following ballot position for draft-ietf-trans-rfc6962-bis-38: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please

[Trans] I-D Action: draft-ietf-trans-rfc6962-bis-38.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public Notary Transparency WG of the IETF. Title : Certificate Transparency Version 2.0 Authors : Ben Laurie Adam Langley

Re: [Trans] Murray Kucherawy's Discuss on draft-ietf-trans-rfc6962-bis-36: (with DISCUSS)

* So I would prefer to name the new, main registry "Public Notary Transparency" (the full name of this WG - see https://datatracker.ietf.org/wg/trans),

Re: [Trans] Murray Kucherawy's Discuss on draft-ietf-trans-rfc6962-bis-36: (with DISCUSS)

On Fri, 14 May 2021, Rob Stradling wrote: Although TRANS is set to wind down without really looking beyond 6962-bis, the original Charter also envisaged exploring "mechanisms and techniques that allow cryptographically verifiable logs to be deployed to improve the security of protocols other

Re: [Trans] Murray Kucherawy's Discuss on draft-ietf-trans-rfc6962-bis-36: (with DISCUSS)

Although TRANS is set to wind down without really looking beyond 6962-bis, the original Charter also envisaged exploring "mechanisms and techniques that allow cryptographically verifiable logs to be deployed to improve the security of protocols other than HTTP over TLS, for example SMTP/TLS or

Re: [Trans] Murray Kucherawy's Discuss on draft-ietf-trans-rfc6962-bis-36: (with DISCUSS)

* It looks like you're making six related registries in Sections 10.2.1 through 10.2.6. Would it make sense to create a main registry called "Certificate Transparency Parameters" that contains these six sub-registries? >> I was not familiar with that distinction until now. Sure, I’ll do

Re: [Trans] Murray Kucherawy's Discuss on draft-ietf-trans-rfc6962-bis-36: (with DISCUSS)

* It looks like you're making six related registries in Sections 10.2.1 through 10.2.6. Would it make sense to create a main registry called "Certificate Transparency Parameters" that contains these six sub-registries? I was not familiar with that distinction until now. Sure, I’ll do

Re: [Trans] Murray Kucherawy's Discuss on draft-ietf-trans-rfc6962-bis-36: (with DISCUSS)

On Fri, 14 May 2021, Salz, Rich wrote: * I suppose an algorithm could be added to the TLS SignatureScheme registry even if it did have one, two, or three hundred KB public keys and so was unlikely to ever be used for TLS. However, I just wanted to raise a potential issue with limiting

Re: [Trans] Murray Kucherawy's Discuss on draft-ietf-trans-rfc6962-bis-36: (with DISCUSS)

* I suppose an algorithm could be added to the TLS SignatureScheme registry even if it did have one, two, or three hundred KB public keys and so was unlikely to ever be used for TLS. However, I just wanted to raise a potential issue with limiting Certificate Transparency to only using

Re: [Trans] Murray Kucherawy's Discuss on draft-ietf-trans-rfc6962-bis-36: (with DISCUSS)

IANA is asked to establish a registry of signature algorithm values, named "CT Signature Algorithms". The following notes should be added: *  This is a subset of the TLS SignatureScheme Registry, limited to    those algorithms that are appropriate for CT.  A major advantage    of this is