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

From: Stephen Kent <[email-masked]>
Date: Mon, 05 Jan 2015 10:42:36 -0500

Rob,

Happy New Year.

>
>
>>>     - stating that the literal string "(PRIVATE)" always covers 
>>> precisely
>>>   _one_ label.
>> Since DNS names are case insensitive, I suggest we not represent a 
>> reserved
>> label in uppercase. It may cause some readers to believe that the 
>> label is
>> special because of its case.
>
> The private label _is_ "special" though.  :-)
>
> It's intended to be a placeholder for a real label.
I'm not sure what you mean by these two sentences. I hope you don't mean 
that
you expect an RP to treat the uppercase representation as different from
lowercase. That would not be consistent with DNS canonicalization rules
(as per 1034) and thus not consistent with 5280. If you mean that you 
plan to
replace "PRIVATE" with some other word, which will treated in a 
case-insensitive
fashion, then NEVERMIND.

>
>>>   So for example, if you wanted to redact 3 components, you'd put
>>>   "SAN:dNSName=(PRIVATE).(PRIVATE).(PRIVATE).mydomain.com" in the
>>>   Precertificate.
>>>
>>>   To reduce bloat, I think we should also change "(PRIVATE)" to "?".
>>>   e.g. "SAN:dNSName=?.?.?.mydomain.com"
>>
>> Is "?" a legal DNS label character? It doesn't seem so as per RFC 1034,
>> and RFC 5280 cites 1034 as the normative spec for dNSName syntax in
>> the subjectAltName extension.
>
> I agree that "?" is not a valid DNS label character according to RFC 
> 1034, but that's actually a useful characteristic here.  If it was a 
> valid DNS label character, then it could be mistakenly interpreted as 
> a real label rather than as just a placeholder!
true.
>
> "*" isn't a valid DNS label character either, and yet it is commonly 
> used in SAN->dNSName fields as a placeholder.
yes, I'm sad to say. PKIX gave into this misuse of DNS syntax because so 
many
CAs adopted the convention. So we added an explicit exception in 5280. I 
don't think
it's a good idea to request another exception. Why not use "*" instead, 
since that
seems semantically appropriate?
>
> You're referring to this part of RFC5280 Section 4.2.1.6:
>   "When the subjectAltName extension contains a domain name system
>    label, the domain name MUST be stored in the dNSName (an IA5String).
>    The name MUST be in the "preferred name syntax", as specified by
>    Section 3.5 of [RFC1034] and as modified by Section 2.1 of
>    [RFC1123]."
>
> If one or more labels is a placeholder rather than a real label, then 
> IMHO the string is _not_ a "domain name system label".  And therefore, 
> the two MUST requirements quoted above don't apply.
I find this reasoning rather circular; it sounds like you're saying 
"since we violated
the syntax already, we can do a anything we want." I'd argue that if you 
use the dNSNAme
SAN type, the string that appears there MUST adhere to DNS name syntax. 
If you want to
use some other syntax, then create a new SAN type.
> Also, AFAICT RFC5280 doesn't prohibit putting strings that are _not_ 
> "domain name system labels" into SAN->dNSName fields.
>
> Towards the end of Section 4.2.1.6 it says:
>   "Finally, the semantics of subject alternative names that include
>    wildcard characters (e.g., as a placeholder for a set of names) are
>    not addressed by this specification.  Applications with specific
>    requirements MAY use such names, but they must define the semantics."
>
> So, as long as we "define the semantics" for our use of "?", I don't 
> think we're doing anything wrong.
>
> Do you agree?

No,I do not. As I noted above, PKIX made an explicit exception for "*" 
because it
was a widely adopted convention. If you want to use "*" then the 
above-cited
paragraph covers this use. If not, then you need to request an update to 
5280.

Steve

---

From: Rob Stradling <[email-masked]>
Date: Mon, 05 Jan 2015 23:00:53 +0000

> Happy New Year.

Happy New Year, Steve.

>>>> precisely   _one_ label.
>>> reserved label in uppercase. It may cause some readers to believe
>>> that the label is special because of its case.
>>
> that you expect an RP to treat the uppercase representation as different
> from lowercase. That would not be consistent with DNS canonicalization
> rules (as per 1034) and thus not consistent with 5280. If you mean that
> you plan to replace "PRIVATE" with some other word, which will treated
> in a case-insensitive fashion, then NEVERMIND.

My intention was that the literal, case-sensitive string "(PRIVATE)." 
would appear zero or more times at the start of each SAN:dNSName in each 
Precertificate.
In each real X.509 certificate, each instance of "(PRIVATE)" would be 
replaced by a real, case-insensitive label.

I don't object to saying that "(PRIVATE)" can be case-insensitive.  That 
said, my preference is still to ditch "(PRIVATE)" and use "?" instead.

Note that we've decided to change the Precertificate format in 6962-bis. 
  The format will no longer be the X.509 certificate format.  Therefore, 
RFC5280 does not apply, which means that a 6962-bis Precertificate and 
the associated X.509 certificate can have the same Issuer and Serial Number.

If RFC5280 does not apply to the serial number field of a (non-X.509) 
Precertificate, then why would RFC5280 apply to the SAN:dNSName field(s) 
of a (non-X.509) Precertificate?

<snip>
> many CAs adopted the convention. So we added an explicit exception in 5280.

The explicit exception is also present in RFC5280's predecessors: 
RFC3280 (published April 2002) and RFC2459 (published January 1999).

Were there really "many CAs" in existence in January 1999?

The exception in 5280/3280/2459 does _not_ say that "wildcard" has to 
mean the "*" character.

RFC2818 (HTTP Over TLS) is an example of "Applications with specific 
requirements MAY use such names, but they must define the semantics". 
It says that "Names may contain the wildcard character * which is 
considered to match any single domain name component or component fragment".

> I don't think it's a good idea to request another exception. Why not use
> "*" instead, since that seems semantically appropriate?

RFC6125 says that if "*" is used in a cert's CN or SAN:dNSName, it must 
appear only once per name and it must be the left-most label.  It would 
be useful to be able to audit compliance to this rule using CT logs. 
Such auditing would be impossible if we were to use "*" for name 
redaction too.

The semantics are different.  "*" means "matches any label", whereas "?" 
(or "(PRIVATE)", or "(private)", or even "(pRivATe)") means "matches one 
particular label, the value of which has been redacted".

> "since we violated the syntax already, we can do a anything we want."

Kinda.

> I'd argue that if you use the dNSNAme SAN type, the string that appears
> there MUST adhere to DNS name syntax.
> If you want to use some other syntax, then create a new SAN type.
>

All of the 43 "*" characters in rfc5280.txt are bullet point.  RFC5280 
never mentions "*" as a/the wildcard character.  The word "asterisk" 
doesn't appear in RFC5280 at all.

AFAICT, "*" is neither more nor less legal than "?", as far as RFC5280 
is concerned.

Where is this 'explicit exception for "*"' that you're talking about?

> because it was a widely adopted convention. If you want to use "*" then the
> above-cited paragraph covers this use. If not, then you need to request an
> update to 5280.

I can only go by what 5280 actually says.  And AFAICT, even if 5280 
applies to (non-X.509) Precertificates (which I don't think it does), 
5280 would not need to be updated to permit the use of "?" as a 
different sort of wildcard/placeholder label for (non-X.509) 
Precertificate CN and SAN:dNSName strings.

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

---

From: "trans issue tracker" <[email-masked]>
Date: Tue, 06 Jan 2015 16:55:36 -0000

#54: Simplify name redaction

Changes (by [email-masked]):

 * owner:  [email-masked] =>
     [email-masked]

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

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

---

From: Stephen Kent <[email-masked]>
Date: Wed, 14 Jan 2015 15:09:58 -0500

Rob,

You made several good points that address the concerns I raised. If the 
pre-cert format is NOT a cert
(or a TBScertificate), then the syntax specified in 5280 and its 
predecessors (and X.509)
don't strictly apply. I forgot, what is the source of the CMS object 
format we decided upon.

I also checked with one of the authors of 2459 and he agreed that we 
always thought in terms
of "*" as _the_ wildcard character, but that since we didn't say so 
explicitly, there is no
basis for rejecting "?" or another character. I do suggest that the WG 
coordinate with some
DNS experts to see what they think about our use of non-DNS characters 
in what is a DNS
name pattern matching context, and whether they have a preference for 
any specific character.

The distinction that you made between the semantics of "*" and the 
intended semantics
for "PRIVATE" was one I had not realized . Specifically, you noted that 
"*" matches
any labal whereas "?" is intended to match only one (redacted) label. 
That seems like
a good reason to us a different character, but it also raises the 
question of how
a Monitor or TLS client is supposed to enforce this requirement. Do you 
envision these clients
remembering every cert that they encounter that matches a redacted 
pre-cert, and check to
see if a CA has issue two certs with different values for a redacted DNS 
label? if not, why
state this as a requirement?

Steve

---

From: Rob Stradling <[email-masked]>
Date: Wed, 14 Jan 2015 22:00:00 +0000

On 14/01/15 20:09, Stephen Kent wrote:
> Rob,
>
> You made several good points that address the concerns I raised.

Thanks Steve.  :-)

> If the pre-cert format is NOT a cert (or a TBScertificate),
> then the syntax specified in 5280 and its predecessors (and X.509)

The new precert format will be documented in the -05 version of the 
6962-bis I-D (which we intend to publish real soon now).  For a preview 
of the text, look here...
https://github.com/google/certificate-transparency-rfcs/blob/master/rfc6962-bis.xml#L332

It's not (just) a TBSCertificate, but it does incorporate a 
TBSCertificate (wrapped inside a CMS signed-data object).

> always thought in terms of "*" as _the_ wildcard character, but that
> since we didn't say so explicitly, there is no  basis for rejecting
> "?" or another character.  I do suggest that the WG coordinate with some
> in what is a DNS name pattern matching context, and whether they have a
> preference for any specific character.

That seems like a good idea.  Did you have any particular DNS experts in 
mind?

> intended semantics for "PRIVATE" was one I had not realized.
> Specifically, you noted that "*" matches any labal whereas "?" is
> intended to match only one (redacted) label.
> That seems like a good reason to us a different character, but it also
> raises the question of how a Monitor or TLS client is supposed to
> enforce this requirement. Do you envision these clients remembering
> every cert that they encounter that matches a redacted pre-cert, and
> check to see if a CA has issue two certs with different values for a
> redacted DNS label?

No, I wasn't envisaging that Monitors and/or TLS clients would 
necessarily do that.

> if not, why state this as a requirement?

I don't think the current text does state this as a requirement.

If there are multiple certs (which may or may not contain different 
unredacted domain label(s)) that match one redacted precert, then those 
certs will all share the same Serial Number and be issued by the same CA.
RFC5280 already disallows this, so 6962-bis doesn't also need to 
disallow it.  :-)

Hmmm...
Should we specify that the redaction label (i.e. "(PRIVATE)" or "?" or 
whatever the DNS experts prefer) MUST NOT match "*" in the cert?
I can't think of a legitimate reason to hide wildcard certs from the log.

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

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
   3rd Floor, 26 Office Village, Exchange Quay,
   Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed.  If you have received this email in error please notify the 
sender by replying to the e-mail containing this attachment. Replies to 
this email may be monitored by COMODO for operational or business 
reasons. Whilst every endeavour is taken to ensure that e-mails are free 
from viruses, no liability can be accepted and the recipient is 
requested to use their own virus checking software.

---

From: "trans issue tracker" <[email-masked]>
Date: Mon, 19 Jan 2015 17:05:47 -0000

Comment (by [email-masked]):

 I've just spotted the glaring error in this proposal.  Without the
 "redactedLabels" extension in the Certificate, it would be rather hard to
 reconstruct the TBSCertificate and verify the SCT signature(s) because
 you'd have to guess which labels need to be changed to "?"s.

 Let's leave this ticket open for now, in the hope that we can find some
 other way to reduce the "risk of misalignment" that Eran mentioned.  If we
 can't, then I suppose this ticket will need to be resolved as invalid.

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

---

From: Stephen Kent <[email-masked]>
Date: Wed, 21 Jan 2015 13:49:38 -0500

Rob,

> That seems like a good idea.  Did you have any particular DNS experts 
> in mind?
I'd ask Joel Jaeggli <[email-masked]> for suggestions.
> I don't think the current text does state this as a requirement.
Your message to me cited this as a reason for not using "*" in this 
context. If the different
semantics for PRIVATE/? are not a requirement, that argument isn't 
applicable. Color me confused.
> unredacted domain label(s)) that match one redacted precert, then 
> those certs will all share the same Serial Number and be issued by the 
> same CA.
Can you cite the part of 5280 that you feel is applicable here? 4.1.2.2 
notes that a cert serial number
uniquely identifies a cert, which doesn't seem compatible with your comment.
> I can't think of a legitimate reason to hide wildcard certs from the log.
I agree that wildcard certs should be logged.

Steve

---

From: Rob Stradling <[email-masked]>
Date: Tue, 27 Jan 2015 10:51:46 +0000

> Rob,

Hi Steve.

> I'd ask Joel Jaeggli <[email-masked]> for suggestions.

Thanks.  I'll contact Joel.

> context. If the different semantics for PRIVATE/? are not a requirement,
> that argument isn't applicable. Color me confused.

IIUC, you're saying that since "*" and "PRIVATE/?" are intended to have 
different semantics, 6962-bis needs to specify the required semantics 
more explicitly than it currently does.  Have I got that right?

I think we could address this by adding text to 6962-bis to specify that 
CAs MUST NOT use "PRIVATE/?" in a Precertificate domain label if the 
corresponding domain label in the Certificate is "*".
If we want TLS Clients to enforce this rule, I think the appropriate 
place for that will be the envisaged client behaviour document (rather 
than 6962-bis).

I've just created these two tickets:
http://trac.tools.ietf.org/wg/trans/trac/ticket/56
http://trac.tools.ietf.org/wg/trans/trac/ticket/57

> notes that a cert serial number uniquely identifies a cert, which doesn't
> seem compatible with your comment.

I don't see any incompatibility.

Your question was...
"Do you envision these clients remembering every cert that they 
encounter that matches a redacted pre-cert, and check to see if a CA has 
issue two certs with different values for a redacted DNS label?"

Even issuing two certs with the same values for a redacted DNS label 
would be wrong.

If a client is checking for RFC5280 4.1.2.2 serial number uniqueness, 
then they are implicitly checking for multiple certs that match a single 
Precertificate.
A Precertificate contains Issuer Name and Serial Number.  Every 
Certificate that matches that particular Precertificate will, by 
definition, contain the same Issuer Name and Serial Number.  So, if 
there is >1 matching Certificate then RFC5280 Section 4.1.2.2 has been 
violated.

> I agree that wildcard certs should be logged.

Great.  I think the two new tickets I mentioned above are sufficient.

---

From: "trans issue tracker" <[email-masked]>
Date: Tue, 27 Jan 2015 11:54:06 -0000

Alternative "redactedLabels" extension proposal:

 Instead of the SEQUENCE OF INTEGERs extension in the current draft, I
 think we should define an extension that's more similar in syntax to the
 RFC5280 nameConstraints extension.  Instead of "permittedSubtrees" and/or
 "excludedSubtrees", we'd be listing "redactedSubtrees".  I think this
 approach would reduce the "risk of misalignment".

 Here's a rough example of how it could work...

 Precertificate:

 Subject:CN = ?.example.com

 SAN:dNSName = ?.example.com
 SAN:dNSName = ?.example.com
 SAN:dNSName = www.example.com
 SAN:dNSName = ?.top-secret.com
 SAN:dNSName = ?.top-secret.com
 SAN:dNSName = top-secret.com

 Certificate:

 Subject:CN = this-is-redacted-1.example.com

 SAN:dNSName = this-is-redacted-1.example.com
 SAN:dNSName = this-is-redacted-2.example.com
 SAN:dNSName = www.example.com
 SAN:dNSName = this-is-redacted-3.top-secret.com
 SAN:dNSName = this-is-redacted-4.top-secret.com
 SAN:dNSName = top-secret.com

 Extension:redactedSubtrees =
 this-is-redacted-1.example.com
 this-is-redacted-2.example.com
 top-secret.com

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

---

From: Rob Stradling <[email-masked]>
Date: Tue, 27 Jan 2015 12:58:14 +0000

> Thanks.  I'll contact Joel.

Actually, before I do that...

We've already thought of two possible ways to express redacted label(s) 
in a Precertificate:
   1. "(PRIVATE)." matching >=1 redacted labels.
   2. "?." matching =1 redacted label.

But it occurs to me that there's a third option:
   3. "" matching >=0 redacted labels.

Option 3 would hide the fact that redaction is even occurring.  We 
wouldn't need to use "(PRIVATE)" or "?" or seek any alternative 
redaction label proposals from the DNS experts.  :-)

Would folks be happy with option 3?

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 28 Jan 2015 17:56:03 -0500

> Would folks be happy with option 3?

The proposal is that "foo.example.com" could be registered with the CA
as "example.com" -- this seems problematic for operators of a sub-zone
who expect their parent zone to be fully-enumerated.

let's say the operator of example claims to be fully-publicly logged,
and lets me register dkg.example.net.  i want to know that the .example.net
operators won't be able to masquerade as dkg.example.net without issuing a
certificate that i can find in the public logs, tied to my name.

If under proposal (2), i need to scan the logs for anything that ends in
dkg.example.net, or ?.example.net that i didn't request.  if something like that
shows up, then i know something is fishy.

But the .example.net operators may have a legitimate reason for wanting to
issue a certificate for "example.net" -- now they have a way of
impersonating me that CT doesn't help me to detect.

I think option 3 defeats one of the main aims of CT.

              --dkg

---

From: Rob Stradling <[email-masked]>
Date: Wed, 28 Jan 2015 23:19:58 +0000

Thanks for explaining that, DKG.  Makes sense.

Is there ever such a thing as a "sub-sub-zone" whose operators expect 
their parent and grandparent zones to be fully-enumerated?
If so, that would suggest that option 1 is also insufficient, in which 
case we'd need to do option 2.

Or if not, is there any reason to prefer option 1 over option 2, or vice 
versa?

---

From: Jeremy Rowley <[email-masked]>
Date: Wed, 28 Jan 2015 23:50:43 +0000

I'd prefer option 2 for simplicity and because I think the CT log should reflect the number of levels redacted. Do you gain much advantage if topsecret.secret.example.com is redacted as (PRIVATE).example.com v. ?.?.example.com.  I think the second is more straight forward and gives more insight on what certs are out there.

-----Original Message-----
From: Trans [mailto:[email-masked]] On Behalf Of Rob Stradling
Sent: Wednesday, January 28, 2015 4:20 PM
To: Daniel Kahn Gillmor; [email-masked]
Subject: Re: [Trans] [trans] #54 (rfc6962-bis): Simplify name redaction

Is there ever such a thing as a "sub-sub-zone" whose operators expect their parent and grandparent zones to be fully-enumerated?
If so, that would suggest that option 1 is also insufficient, in which case we'd need to do option 2.

Or if not, is there any reason to prefer option 1 over option 2, or vice versa?

On 28/01/15 22:56, Daniel Kahn Gillmor wrote:
>>>>> That seems like a good idea.  Did you have any particular DNS 
>>>>> experts in mind?
>>>>
>> We've already thought of two possible ways to express redacted 
>> label(s) in a Precertificate:
> and lets me register dkg.example.net.  i want to know that the 
> .example.net operators won't be able to masquerade as dkg.example.net 
> without issuing a certificate that i can find in the public logs, tied to my name.
>
> If under proposal (2), i need to scan the logs for anything that ends 
> in dkg.example.net, or ?.example.net that i didn't request.  if 
> something like that shows up, then i know something is fishy.
>
> But the .example.net operators may have a legitimate reason for 
> wanting to issue a certificate for "example.net" -- now they have a 
> way of impersonating me that CT doesn't help me to detect.
>

COMODO CA Limited, Registered in England No. 04058690 Registered Office:
   3rd Floor, 26 Office Village, Exchange Quay,
   Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed.  If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 29 Jan 2015 16:41:25 -0500

> their parent and grandparent zones to be fully-enumerated?

Sure.  Consider any ISP that hands out sub-zones to any customer who
wants them.  Say i run Example WebHosting, and i control example.net,
which i use to hand out foo.example.net domains to those customers who
don't have their own names and don't want to register them.

i (and my customers) would certainly want .net to be fully-enumerated
(and we all want the root zone to be fully-enumerated).  And my
customers would want example.net to be fully-enumerated, because they
don't want me being able to impersonate them.

> case we'd need to do option 2.

I'm not sure that this proves that option 1 is actually insufficient --
your real question is whether it's possible to have a non-enumerated
zone sandwiched between two fully-enumerated zones.

for example, consider a hypothetical example.com, which specializes in
non-enumerability (hiding the public names of its child zones for those
that trust it) -- its parent (the root zone) should be fully-enumerable,
but it itself chooses to hide its list of immediate children.  It could
still delegate the foo.example.com zone to someone else, with the
proviso that it could impersonate foo.example.com, but not
x.foo.example.com.

then the customers/zone-children of example.com would have the option of
either:

 a) hiding in the anonymized/non-enumerable space, while risking
    undetectable compromise by their parent zone, or

 b) avoiding use of the apex of their zone, and exposing their
    delegation as (e.g.) whatever.foo.example.com, while being able to
    monitor for misuse by their parent.

if ?.?.example.com ever shows up in the logs, then customers in group
(b) know that they might have a problem.  if we go with option 1, then
customers in group (b) have no recourse.

> Or if not, is there any reason to prefer option 1 over option 2, or vice 

I think you're right, we should go for option 2 (also, it's the
simplest and easiest to explain, i think).

  --dkg

---

From: Rob Stradling <[email-masked]>
Date: Fri, 30 Jan 2015 16:09:10 +0000

> On Wed 2015-01-28 18:19:58 -0500, Rob Stradling wrote:
<Useful explanation snipped - thanks DKG>

On 28/01/15 23:50, Jeremy Rowley wrote:
> I'd prefer option 2 for simplicity and because I think the CT log
> should reflect the number of levels redacted. Do you gain much
> advantage if topsecret.secret.example.com is redacted as
> (PRIVATE).example.com v. ?.?.example.com.  I think the second is more
> straight forward and gives more insight on what certs are out there.

OK, let's discard option 1 and option 3.  Before we settle on option 2, 
here's an option 4 to consider...

4. "?" matching =1 character in a redacted label.

Examples:
"dkg.example.net" would be redacted as "???.example.net".
"???.example.net" cannot match "jeremy.example.net", because the label 
lengths are different (i.e. 3 != 6).
However, "???.example.net" might match "rob.example.net".

"topsecret.secret.example.com" would be redacted as 
"?????????.??????.example.com".

I don't think there's anything to gain from redacting the length of a 
label, so I prefer option 4.  Any thoughts?

AFAICT, matching =1 character seem marginally more consistent with other 
uses of "?" as a wildcard character:
http://en.wikipedia.org/wiki/Wildcard_character
"In Unix-like and DOS operating systems, the question mark ("?") matches 
exactly one character;"
"In Microsoft Access, wildcard characters can be used in "LIKE" 
expressions; the asterisk sign (*) matches zero or more characters, and 
the question mark (?) matches a single character."

---

From: Jeremy Rowley <[email-masked]>
Date: Fri, 30 Jan 2015 16:22:52 +0000

I agree that there isn't much to gain with matching "?" to each character.  (Would you ever want to do "t?psecret.exmaple.com"?)

Option 4 is preferable since it indicates a label exists. 

Plus, the document referenced (the Federal Glossary of Telecommunication Terms) indicates you can use "?" to reference an entire string as long as that is specified.  As long as the meaning of the "?" character is clear in the RFC, I don't think we're breaking established conventions.

-----Original Message-----
From: Rob Stradling [mailto:[email-masked]] 
Sent: Friday, January 30, 2015 9:09 AM
To: Daniel Kahn Gillmor; [email-masked]; Jeremy Rowley
Subject: Re: [Trans] [trans] #54 (rfc6962-bis): Simplify name redaction

> straight forward and gives more insight on what certs are out there.

OK, let's discard option 1 and option 3.  Before we settle on option 2, here's an option 4 to consider...

Examples:
"dkg.example.net" would be redacted as "???.example.net".
"???.example.net" cannot match "jeremy.example.net", because the label lengths are different (i.e. 3 != 6).
However, "???.example.net" might match "rob.example.net".

"topsecret.secret.example.com" would be redacted as "?????????.??????.example.com".

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 30 Jan 2015 11:32:19 -0500

> label, so I prefer option 4.  Any thoughts?

Say i've got a dozen machines in my domain, all using an obscure naming
scheme that you won't be able to guess.

with option 2, i request and log a single cert for all of them, but
someone monitoring the log can't tell whether i've got a dozen services
or a single service with 11 backup certs.

My naming scheme might scatter the lengths of the names between 6 and 15
characters, perhaps into 8 different lengths for the 12 services (there
is some random overlap, and some lengths happen to not get hit).

With option 4, you now know that i have at least 8 different services
certified.  furthermore, you know how many characters exactly to search
in.

Why would i want to leak this information if i'm interested in avoiding
enumeration?

I also think option 4 is currently ambiguous because of IDN:

Is the '?' one character in IDN?  or one byte in UTF-8 representation of
the IDN?  or one character in punycode?  We can clarify it, but it seems
likely to encourage a little bit of implementation confusion at least
(IDN is confusing enough).

The native unit of DNS is the label.  It's simplest to use one redaction
symbol for one label.

> the question mark (?) matches a single character."

If we follow this reasoning, then the better response is to choose a
different redaction mark, not to make the redaction mark be
per-character.  if we don't like ?, and we don't want to use * because
of the overlap with current wildcard practice, then we should choose
something else outside the range of the acceptable characters for DNS.

We could use '%' (thanks, SQL!) or '~' or '!' or '#' or '^' or '|' if
we're looking for single-character replacements.

I'm personally fine with '?' to mean "matches a single redacted label",
though.

I'd recommend against '_' because even though it is not a valid
character for a hostname, it is a valid DNS label that is used for
things like SRV records (e.g. _foo._tcp.example.net), and SRVName
SubjectAltName entries could include an '_'.

               --dkg

---

From: Rob Stradling <[email-masked]>
Date: Fri, 30 Jan 2015 16:54:15 +0000

Thanks again, DKG.  Option 2 it is then.

Do you think we should support redacting (for example) 
"public.secret.example.com" to "public.?.example.com" ?

Or, to keep it simple, shall we disallow unredacted labels to the left 
of a redacted label?

---

From: "Scott R. Corzine" <[email-masked]>
Date: Fri, 30 Jan 2015 13:21:15 -0500

On Fri, Jan 30, 2015 at 11:54 AM, Rob Stradling <[email-masked]>
wrote:

> Do you think we should support redacting (for example) "
> public.secret.example.com" to "public.?.example.com" ?
>
> Or, to keep it simple, shall we disallow unredacted labels to the left of
> a redacted label?
>

>From an operations viewpoint I would say to disallow them:

* It will at best be rarely used, with few, if any, non-contrived use cases.

* It is begging humans or software to miss seeing/correctly processing the
unusual "?" buried in the middle of what is easily mistaken for a normal
FQDN.

* Additional (if only slightly) code complexity and testing will be
required but rarely used and unimportant to most customers. Often such low
priority features get poorly implemented/tested.

* The preceding two points suggest some implementations and deployments
could end up with vulnerabilities from a little known feature..

* (Remembering non-contiguous subnet masks) It potentially could prevent
some sort of optimization for the other 99+% of cases.

* An attacker (or mistake) could exploit the increased chance of human
misreading. Detecting/fixing this mistake may be difficult for those who
made it in the first place.

Without a really strong use case it seems the negatives easily win over the
minor increase in flexibility.

-Scott-

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 30 Jan 2015 18:28:17 +0000

> Do you think we should support redacting (for example) "public.secret.example.com" to "public.?.example.com" ?

No.  Maybe later if there is a strong demand for this.  YAGNI, right?

--  
Principal Security Engineer, Akamai Technologies
IM: [email-masked] Twitter: RichSalz

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 30 Jan 2015 14:28:52 -0500

> No.  Maybe later if there is a strong demand for this.  YAGNI, right?

Barring anyone else speaking up with a clear use case, i'm convinced by
Scott and Rich that we don't need this -- so ? redactions are only
allowable at the front of the domain name.  No redacted labels can be
higher in the DNS hierarchy than any non-redacted label.

       --dkg

---

From: Peter Bowen <[email-masked]>
Date: Fri, 30 Jan 2015 12:13:21 -0800

> higher in the DNS hierarchy than any non-redacted label.

Is "?" allowed to substitute for "*".   I would prefer not, which
means that it might be reasonable to have "*.?.example.com" (assuming
?.example.com is reasonable).

Thanks,
Peter

---

From: Jeremy Rowley <[email-masked]>
Date: Fri, 30 Jan 2015 20:36:02 +0000

* isn't a redacted label so the example (*.?.example.com) wouldn't be allowed.  Also, the CAB Forum prohibits * characters except as the left most label in the cert.  Therefore, you would never have an instance with both a "?" and a "*' in the same cert.

-----Original Message-----
From: Trans [mailto:[email-masked]] On Behalf Of Peter Bowen
Sent: Friday, January 30, 2015 1:13 PM
To: Daniel Kahn Gillmor
Cc: Scott R. Corzine; Salz, Rich; Rob Stradling; trans
Subject: Re: [Trans] [trans] #54 (rfc6962-bis): Simplify name redaction

On Fri, Jan 30, 2015 at 11:28 AM, Daniel Kahn Gillmor <[email-masked]> wrote:
> Barring anyone else speaking up with a clear use case, i'm convinced 
> by Scott and Rich that we don't need this -- so ? redactions are only 

Is "?" allowed to substitute for "*".   I would prefer not, which
means that it might be reasonable to have "*.?.example.com" (assuming ?.example.com is reasonable).

Thanks,
Peter

---

From: Jeremy Rowley <[email-masked]>
Date: Fri, 30 Jan 2015 20:40:38 +0000

Although I just realized you're probably wondering if you can substitute "?" of "*" -  so *.example.com would become ?.example.com.  

It's a good question. I think there's real value in knowing whether a wildcard cert was issued over a non-wildcard.  I'd actually like the rfc to say you can't substitute ? for a wildcard character as you're essentially substituting ? for an unlimited number of based domain names. 

-----Original Message-----
From: Trans [mailto:[email-masked]] On Behalf Of Peter Bowen
Sent: Friday, January 30, 2015 1:13 PM
To: Daniel Kahn Gillmor
Cc: Scott R. Corzine; Salz, Rich; Rob Stradling; trans
Subject: Re: [Trans] [trans] #54 (rfc6962-bis): Simplify name redaction

Thanks,
Peter

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 30 Jan 2015 16:24:39 -0500

> ?.example.com is reasonable).

Thanks for raising this, Peter.  Can you explain why you think it
shouldn't be OK for "?" to substitute for "*"?

I'm trying to think through the different attack scenarios that CT is
intended to mitigate (or at least expose), and the rationales for label
redaction, and i'm not seeing why "?" shouldn't be able to stand in for
the wildcard.  

    --dkg

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 30 Jan 2015 17:07:07 -0500

On Fri 2015-01-30 15:40:38 -0500, Jeremy Rowley wrote:
> Although I just realized you're probably wondering if you can
> substitute "?" of "*" - so *.example.com would become ?.example.com.
>
> It's a good question. I think there's real value in knowing whether a
> wildcard cert was issued over a non-wildcard.  I'd actually like the
> rfc to say you can't substitute ? for a wildcard character as you're
> essentially substituting ? for an unlimited number of based domain
> names.

But isn't that kind of the point?  If i control foo.example, and i'm
monitoring the logs to make sure no one impersonates anything in my zone
(including the apex), then i'm looking for all of the following literal
matches as suffixes:

 foo.example
 ?.example
 *.example

In particular, of course, i'm looking for entries in the logs that are
associated with public keys not under my control (i can ignore my own
entries).

Note that the first entry there also covers literal strings like:

 ?.foo.example
 *.foo.example

If i find anything in the logs matching those suffixes, i know that my
domain name may have been hijacked, because a matching form could be
there.

It wouldn't matter to me whether it was being hijacked by someone with a
cert that says "foo.example" instead of "*.example", or "*.foo.example"
instead of "www.foo.example" -- either one is sufficient to raise an
alarm, and (because of the redaction) i wouldn't know if "?.foo.example"
was issued to "www.foo.example" or "bar.foo.example" anyway.

I still don't see why we shouldn't allow redaction of a wildcard label.
What does this restriction defend against?  how does it make life easier
or better for any of the players in the CT ecosystem?

        --dkg

---

From: Jeremy Rowley <[email-masked]>
Date: Fri, 30 Jan 2015 22:16:06 +0000

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.  

Jeremy

-----Original Message-----
From: Trans [mailto:[email-masked]] On Behalf Of Daniel Kahn Gillmor
Sent: Friday, January 30, 2015 3:07 PM
To: trans
Subject: Re: [Trans] [trans] #54 (rfc6962-bis): Simplify name redaction

> essentially substituting ? for an unlimited number of based domain 

But isn't that kind of the point?  If i control foo.example, and i'm monitoring the logs to make sure no one impersonates anything in my zone (including the apex), then i'm looking for all of the following literal matches as suffixes:

 foo.example
 ?.example
 *.example

In particular, of course, i'm looking for entries in the logs that are associated with public keys not under my control (i can ignore my own entries).

 ?.foo.example
 *.foo.example

If i find anything in the logs matching those suffixes, i know that my domain name may have been hijacked, because a matching form could be there.

It wouldn't matter to me whether it was being hijacked by someone with a cert that says "foo.example" instead of "*.example", or "*.foo.example"
instead of "www.foo.example" -- either one is sufficient to raise an alarm, and (because of the redaction) i wouldn't know if "?.foo.example"
was issued to "www.foo.example" or "bar.foo.example" anyway.

I still don't see why we shouldn't allow redaction of a wildcard label.
What does this restriction defend against?  how does it make life easier or better for any of the players in the CT ecosystem?

        --dkg

---

From: Peter Bowen <[email-masked]>
Date: Fri, 30 Jan 2015 17:58:50 -0800

> 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 stron…

I was thinking similarly.  I propose that labels containing a "*" may
not be redacted, as the "*" effectively is redaction.  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.

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.

Thanks,
Peter

---

From: Jeremy Rowley <[email-masked]>
Date: Sat, 31 Jan 2015 02:01:45 +0000

Yeah - good points.  We definitely don't want to see a ?.com cert logged.

-----Original Message-----
From: Peter Bowen [mailto:[email-masked]] 
Sent: Friday, January 30, 2015 6:59 PM
To: Jeremy Rowley
Cc: Daniel Kahn Gillmor; trans
Subject: Re: [Trans] [trans] #54 (rfc6962-bis): Simplify name redaction

> 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 stron…

I was thinking similarly.  I propose that labels containing a "*" may not be redacted, as the "*" effectively is redaction.  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.

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.

Thanks,
Peter

---

From: Peter Bowen <[email-masked]>
Date: Fri, 30 Jan 2015 18:18:13 -0800

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 and the latter has the longest public suffix I've
seen.

---

From: Matt Palmer <[email-masked]>
Date: Sat, 31 Jan 2015 13:35:48 +1100

> Yeah - good points.  We definitely don't want to see a ?.com cert logged.

Actually, I'd be quite happy to see a precert for ?.com logged.  It would
make it quite clear which CA is failing to play by the rules, which is,
after all, rather the point of CT.

- Matt

---

From: Watson Ladd <[email-masked]>
Date: Fri, 30 Jan 2015 19:03:28 -0800

> after all, rather the point of CT.

Backing up quite a bit: It's clear from the examples that the level at
which you can safely truncate a domain and know that you are
identifying a unique organization is extremely difficult to determine.
I'm sure there is a list out there, but it may change. And when it
changes, old software may suddenly either accept too many certs, or
too few.

I'm sure people have thought about this more than I have.

Sincerely,
Watson Ladd

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: Peter Bowen <[email-masked]>
Date: Fri, 30 Jan 2015 22:13:57 -0800

> I'm sure people have thought about this more than I have.

Take a look at http://www.publicsuffix.org/  It is a formatted list
that attempts to document the split between shared (e.g. public)
portions of a fully qualified domain name and the registered (private)
portion.

The new TLD rush is going to cause interesting issues, as there is a
concept of a ".brand" where the whole TLD represents one organization.
I think there is an argument these are not new (as .mil is effectively
a .brand for the US Department of Defense), but I'm sure that they
will be interesting from a processing perspective.  ? anyone?

---

From: Matt Palmer <[email-masked]>
Date: Sat, 31 Jan 2015 17:59:59 +1100

> will be interesting from a processing perspective.  ? anyone?

publicsuffix.org is what is recommended for CAs to use in determining
whether to allow registration of a name, I believe.

For the purposes of CT logs, specifically, though, I believe it's
irrelevant.  Logging a certificate shows what was issued, logging a precert
shows what was intended to be issued.  CT monitors should be watching for
signs of inappropriate behaviour.  Logging a precert such that the legitimate
owner of *any* FQDN cannot determine with confidence that the unredacted
precert could actually be for something in their namespace is an
inappropriate behaviour.  It's no different than logging a cert with an
overly-broad wildcard, such as a sAN of `dNSName:*.com`.

- Matt