Subject: Re: [Trans] [trans] #54 (rfc6962-bis): Simplify name redaction

From: Rob Stradling <[email-masked]>
Date: Mon, 02 Feb 2015 09:53:38 +0000

On 31/01/15 01:58, Peter Bowen wrote:
> On Fri, Jan 30, 2015 at 2:16 PM, Jeremy Rowley
> <[email-masked]> wrote:
>> My idea isn't fully formed yet, but...
>>
>> Wildcard certs are more risky than normal certs since the CA doesn't know exactly what they are securing.  All they know is the secured base level domain.  Therefore, I think the public has a strong interest in knowing when a wildcard cert was issued v. a standard FQDN cert.  However, I'm not sure there's much more risk to end certificate requester - they still know everything that's been issued for their domain.  It certainly doesn't make life easier for the CT operator or CA, but it gives important information to the relying parties looking at certs.  If they look up a cert in the CT log, they'll be able to easily identify if the entire domain is secured by the same, logged cert.
>
> I was thinking similarly.  I propose that labels containing a "*" may
> not be redacted, as the "*" effectively is redaction.

http://trac.tools.ietf.org/wg/trans/trac/ticket/56

> Additionally,
> if the left most label is exactly "*", then it is considered redacted
> for the purposes of determining if the label to the right may be
> redacted. That would allow *.?.?.example.com to be an allowable
> redaction.

Good idea.  I've noted this suggestion on ticket #56.  Thanks Peter.

> I would also recommend that the right most two labels AND any labels
> making up a "public suffix" not be allowed to be redacted.  I'm not
> sure if this should go into 6962bis or the policy of clients,
> auditors, and monitors, but the redacting these effectively nullifies
> the reason for CT as far as I'm concerned.

That's what this section of the I-D attempts to address:

7.3.  Redaction of Public Domain Name Labels

    CAs SHOULD NOT redact domain name labels in Precertificates to the
    extent that domain name ownership becomes unclear (e.g.
    "(PRIVATE).com" and "(PRIVATE).co.uk" would both be problematic).
    Logs MUST NOT reject any Precertificate that is overly redacted but
    which is otherwise considered compliant.  It is expected that
    monitors will treat overly redacted Precertificates as potentially
    misissued.  TLS clients MAY reject a certificate whose corresponding
    Precertificate would be overly redacted.

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

---

From: Gervase Markham <[email-masked]>
Date: Mon, 02 Feb 2015 08:28:33 +0000

On 31/01/15 02:18, Peter Bowen wrote:
> Nor do I think we want a ?.mil  or ?.pvt.k12.ma.us logged.  The former
> is technically valid, as mil is not a public suffix, rather it is a
> registered name

Er, .mil is a public suffix. Check the public suffix list. :-)

Gerv

---

From: Peter Bowen <[email-masked]>
Date: Mon, 2 Feb 2015 06:37:23 -0800

> Er, .mil is a public suffix. Check the public suffix list. :-)

I know what the list says.  This is not rally a core topic for this
WG/list.  Is there a list for PSL discussion?

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 02 Feb 2015 14:44:29 +0000

> WG/list.  Is there a list for PSL discussion?

Not exactly, but the currently-being-chartered dbound wg [1]
list [2] is probably the closest IETF list. I'd expect there's a
better list elsewhere specifically for the PSL

S.

[1] https://datatracker.ietf.org/doc/charter-ietf-dbound/
[2] https://www.ietf.org/mailman/listinfo/dbound

> 
> 
> 
> _______________________________________________
> Trans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans
>

---

From: Gervase Markham <[email-masked]>
Date: Mon, 02 Feb 2015 19:02:28 +0000

> WG/list.  Is there a list for PSL discussion?

No; if you want to propose the removal or reclassification of .mil,
email [email-masked]. We would open a bug in
bugzilla.mozilla.org.

Gerv

---

From: Peter Bowen <[email-masked]>
Date: Mon, 2 Feb 2015 12:49:44 -0800

> email [email-masked]. We would open a bug in

https://bugzilla.mozilla.org/show_bug.cgi?id=1128673

---

From: "trans issue tracker" <[email-masked]>
Date: Tue, 17 Feb 2015 14:56:48 -0000

#54: Simplify name redaction

Changes (by [email-masked]):

 * status:  new => closed
 * resolution:   => invalid

Comment:

 FWIW, the last line in that example should be ".top-secret.com" rather
 than "top-secret.com".

 I've discussed my comment:3 proposal with Ben and Eran.  We've decided to
 not use it.  We'll stick with the SEQUENCE OF INTEGERs extension in the
 current draft.  So, since the idea of simplifying name redaction seems to
 have reached a dead end, I'm marking this ticket as INVALID.

 I've just created ticket #60 to salvage the idea of revealing the number
 of redacted labels.  In a recent discussion on the list, there was clear
 support for this, albeit for security reasons rather than for
 simplification reasons.

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |       Owner:
  [email-masked]           |  [email-masked]
     Type:  enhancement              |      Status:  closed
 Priority:  major                    |   Milestone:
Component:  rfc6962-bis              |     Version:
 Severity:  -                        |  Resolution:  invalid
 Keywords:                           |
-------------------------------------+-------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ticket/54#comment:4>
trans <http://tools.ietf.org/trans/>