Issue 83200047: Draft text for http://trac.tools.ietf.org/wg/trans/trac/ticket/1 (Closed)
|
Created:
10 years, 11 months ago by Rob Stradling Modified:
10 years, 9 months ago Visibility:
Public. |
DescriptionDraft text for http://trac.tools.ietf.org/wg/trans/trac/ticket/1
Patch Set 1 #
Total comments: 14
Patch Set 2 : Address comments from Ben #
Total comments: 7
Patch Set 3 : Address more comments from Ben #Patch Set 4 : CN-IDs MUST remain unredacted #Patch Set 5 : Include all edits #MessagesTotal messages: 9
Sign in to reply to this message.
https://codereview.appspot.com/83200047/diff/1/doc/rfc6962-bis.xml File doc/rfc6962-bis.xml (right): https://codereview.appspot.com/83200047/diff/1/doc/rfc6962-bis.xml#newcode419 doc/rfc6962-bis.xml:419: them to be secured using publicly-trusted TLS server certificates. Enterprises s/publicly-trusted/publicly trusted https://codereview.appspot.com/83200047/diff/1/doc/rfc6962-bis.xml#newcode441 doc/rfc6962-bis.xml:441: the complete left-most labels in each DNS-ID and CN-ID with the literal string leftmost is a word :-) CN-ID? Not explained. https://codereview.appspot.com/83200047/diff/1/doc/rfc6962-bis.xml#newcode449 doc/rfc6962-bis.xml:449: Precertificate. I totally don't understand this sentence. https://codereview.appspot.com/83200047/diff/1/doc/rfc6962-bis.xml#newcode457 doc/rfc6962-bis.xml:457: rule. Hmm. Not sure we could mandate this behaviour. For example, uk.com confuses the whole issue. It is surely up to those who monitor the log to complain about certs with overly broad (PRIVATE) parts. Also, TLS clients don't see Precertificates per se, only auditors do, which may or may not be TLS clients. At which time it is too late to do rejecting anyway. Probably better as a note in Security Considerations? https://codereview.appspot.com/83200047/diff/1/doc/rfc6962-bis.xml#newcode485 doc/rfc6962-bis.xml:485: ranges. Since this is fixed data, say how? Also, how do we allow for IPv7? (Rhetorical question :-). Is it actually necessary to exclude IP spaces? Do clients accept IP-based certs? We could just say a CT-compliant client doesn't accept IP-based certs, maybe? https://codereview.appspot.com/83200047/diff/1/doc/rfc6962-bis.xml#newcode489 doc/rfc6962-bis.xml:489: whose extnValue OCTET STRING contains ASN.1 NULL data (0x05 0x00)). Say what this extension means (i.e. "OK to not log certificates below this name constraint"). https://codereview.appspot.com/83200047/diff/1/doc/rfc6962-bis.xml#newcode496 doc/rfc6962-bis.xml:496: included. Redundant, surely?
Sign in to reply to this message.
https://codereview.appspot.com/83200047/diff/1/doc/rfc6962-bis.xml File doc/rfc6962-bis.xml (right): https://codereview.appspot.com/83200047/diff/1/doc/rfc6962-bis.xml#newcode419 doc/rfc6962-bis.xml:419: them to be secured using publicly-trusted TLS server certificates. Enterprises On 2014/04/02 12:52:00, Ben Laurie (Google) wrote: > s/publicly-trusted/publicly trusted Changed. https://codereview.appspot.com/83200047/diff/1/doc/rfc6962-bis.xml#newcode441 doc/rfc6962-bis.xml:441: the complete left-most labels in each DNS-ID and CN-ID with the literal string On 2014/04/02 12:52:00, Ben Laurie (Google) wrote: > leftmost is a word :-) "leftmost" it is then. (FWIW, RFC6125 uses "left-most" more often than "leftmost"). > CN-ID? Not explained. Fixed by referencing RFC6125 again. https://codereview.appspot.com/83200047/diff/1/doc/rfc6962-bis.xml#newcode449 doc/rfc6962-bis.xml:449: Precertificate. On 2014/04/02 12:52:00, Ben Laurie (Google) wrote: > I totally don't understand this sentence. It's a complicated sentence, I agree. I'm trying to avoid having to explicitly list the number of redacted labels in each CN-ID in the "SEQUENCE OF INTEGERs" extension. (That extension covers just the DNS-ID(s) ). The idea is that if a cert contains Subject:CN=top.secret.example.com, then it MUST also contains SubjectAltName:dNSName=top.secret.example.com. Then, if the corresponding Precertificate contains Subject:CN=(PRIVATE).example.com, then that dNSName MUST be redacted to (PRIVATE).example.com too. A TLS Client can then reconstruct the Precertificate's Subject:CN(s) even though the "SEQUENCE OF INTEGERs" extension doesn't explicitly state the number of labels that are redacted in each CN. https://codereview.appspot.com/83200047/diff/1/doc/rfc6962-bis.xml#newcode457 doc/rfc6962-bis.xml:457: rule. On 2014/04/02 12:52:00, Ben Laurie (Google) wrote: > Hmm. Not sure we could mandate this behaviour. For example, http://uk.com confuses the > whole issue. It is surely up to those who monitor the log to complain about > certs with overly broad (PRIVATE) parts. OK. > Also, TLS clients don't see Precertificates per se, only auditors do, which may > or may not be TLS clients. At which time it is too late to do rejecting anyway. Huh? A TLS client, even one that does not audit the Precertificate SCT(s), can reconstruct the Precertificate and verify its signature without performing any side-channel lookups. Having reconstructed the Precertificate, it could look at the (PRIVATE) parts. So surely a TLS client could reject a cert with overly broad (PRIVATE) parts during the TLS handshake? > Probably better as a note in Security Considerations? Yeah, OK. Moved. https://codereview.appspot.com/83200047/diff/1/doc/rfc6962-bis.xml#newcode485 doc/rfc6962-bis.xml:485: ranges. On 2014/04/02 12:52:00, Ben Laurie (Google) wrote: > Since this is fixed data, say how? Example added. > Also, how do we allow for IPv7? (Rhetorical question :-). > > Is it actually necessary to exclude IP spaces? Do clients accept IP-based certs? Yes, the CABForum BRs permit IP-based certs and clients accept them. > We could just say a CT-compliant client doesn't accept IP-based certs, maybe? I think banning them would be unpopular. What I'm suggesting is that all IP-based certs MUST be logged, since IP Addresses don't contain security-sensitive the private subdomain names that we're trying to avoid logging. https://codereview.appspot.com/83200047/diff/1/doc/rfc6962-bis.xml#newcode489 doc/rfc6962-bis.xml:489: whose extnValue OCTET STRING contains ASN.1 NULL data (0x05 0x00)). On 2014/04/02 12:52:00, Ben Laurie (Google) wrote: > Say what this extension means (i.e. "OK to not log certificates below this name > constraint"). Done. https://codereview.appspot.com/83200047/diff/1/doc/rfc6962-bis.xml#newcode496 doc/rfc6962-bis.xml:496: included. On 2014/04/02 12:52:00, Ben Laurie (Google) wrote: > Redundant, surely? OK. Removed.
Sign in to reply to this message.
https://codereview.appspot.com/83200047/diff/20001/doc/rfc6962-bis.xml File doc/rfc6962-bis.xml (right): https://codereview.appspot.com/83200047/diff/20001/doc/rfc6962-bis.xml#newcod... doc/rfc6962-bis.xml:450: Precertificate. Do we say anything about the CN-ID in the certificate? Must it also be unredacted? https://codereview.appspot.com/83200047/diff/20001/doc/rfc6962-bis.xml#newcod... doc/rfc6962-bis.xml:1221: CAs SHOULD NOT redact too many domain name labels in Precertificates "too many" is rather vague. Something like "CAs SHOULD NOT redact domain names to the extent that ownership becomes unclear"? https://codereview.appspot.com/83200047/diff/20001/doc/rfc6962-bis.xml#newcod... doc/rfc6962-bis.xml:1227: Precertificates. TLS clients don't see Precertificates, so can't reject them. Maybe "TLS clients MAY reject certificates whose corresponding Precertificate would be overly redacted"?
Sign in to reply to this message.
https://codereview.appspot.com/83200047/diff/20001/doc/rfc6962-bis.xml File doc/rfc6962-bis.xml (right): https://codereview.appspot.com/83200047/diff/20001/doc/rfc6962-bis.xml#newcod... doc/rfc6962-bis.xml:450: Precertificate. On 2014/04/07 10:22:51, Ben Laurie (Google) wrote: > Do we say anything about the CN-ID in the certificate? Must it also be > unredacted? Labels may only be redacted in a Precertificate, as the section title says. So I think it's obvious that all of the (zero or more) CN-IDs and all of the (zero or more) DNS-IDs in each certificate MUST be unredacted. An idea to simplify this section: Specify that it's not possible to redact CN-IDs. CN-ID is a legacy, non-required field. Folks that want to use redaction should be able to use _just_ DNS-IDs instead. What do you think? https://codereview.appspot.com/83200047/diff/20001/doc/rfc6962-bis.xml#newcod... doc/rfc6962-bis.xml:1221: CAs SHOULD NOT redact too many domain name labels in Precertificates On 2014/04/07 10:22:51, Ben Laurie (Google) wrote: > "too many" is rather vague. I agree. I was struggling to think of a better way to express it. > Something like "CAs SHOULD NOT redact domain names > to the extent that ownership becomes unclear"? Thanks. Changed. https://codereview.appspot.com/83200047/diff/20001/doc/rfc6962-bis.xml#newcod... doc/rfc6962-bis.xml:1227: Precertificates. On 2014/04/07 10:22:51, Ben Laurie (Google) wrote: > TLS clients don't see Precertificates, so can't reject them. Maybe "TLS clients > MAY reject certificates whose corresponding Precertificate would be overly > redacted"? Done.
Sign in to reply to this message.
LGTM, but if you want to do the CN-ID thing, happy to review again. https://codereview.appspot.com/83200047/diff/20001/doc/rfc6962-bis.xml File doc/rfc6962-bis.xml (right): https://codereview.appspot.com/83200047/diff/20001/doc/rfc6962-bis.xml#newcod... doc/rfc6962-bis.xml:450: Precertificate. On 2014/04/07 13:50:26, Rob Stradling wrote: > On 2014/04/07 10:22:51, Ben Laurie (Google) wrote: > > Do we say anything about the CN-ID in the certificate? Must it also be > > unredacted? > > Labels may only be redacted in a Precertificate, as the section title says. So > I think it's obvious that all of the (zero or more) CN-IDs and all of the (zero > or more) DNS-IDs in each certificate MUST be unredacted. > > An idea to simplify this section: Specify that it's not possible to redact > CN-IDs. CN-ID is a legacy, non-required field. Folks that want to use > redaction should be able to use _just_ DNS-IDs instead. > What do you think? Sounds like a good idea - CN-IDs are supposed to go away anyway, we should encourage that.
Sign in to reply to this message.
On 2014/04/07 14:43:11, Ben Laurie (Google) wrote: > LGTM, but if you want to do the CN-ID thing, happy to review again. Done.
Sign in to reply to this message.
LGTM
Sign in to reply to this message.
|
