Subject: [Trans] Reviving Redaction

From: Peter Bowen <[email-masked]>
Date: Sun, 5 Mar 2017 22:06:31 -0800

I started to review the redaction draft to determine current state,
but realized that it isn't clear we have a common baseline from which
to start any review.  I've put together a few statements that I think
are true, but would like to see if others agree.

1) A registered domain is a label plus a registration suffix, which is
frequently the TLD.  The existence (or non-existence) of a registered
domain is public information.

Rationale: The zone files for all ICANN gTLDs, are available for
download.  While some ccTLDs don't offer similar service, the basic
registered/registerable domain should not be considered private
information.

2) Logging certificates to a CT log is optional.  An unlogged
certificate may not be accepted by some clients or relying parties,
but is not a mis-issued certificate.

Rationale: While some might want to see 100% logging, it is clear
there is not currently support for making it mandatory.

3) Split horizon DNS exists as does delegation to private name
servers.  This means that names that are unique in the global
namespace might not be resolvable from the public Internet.

Rationale: Many TLDs allow DNS name servers to have addresses in
reserved IP ranges that are not designated as globally unique (e.g. in
10.0.0.0/8).  Even if the TLD does not, subordinate domain of
registered domains may have such.  Even if using public IP addresses,
network ACLs may prevent access.

4) Given a full certificate, it must be possible to deterministically
reconstruct the precertificate.

Rationale: Without this, it becomes impossible to determine if a
signature of a precertificate matches the final certificate.

5) Given a precertificate and full certificate, it should be possible
to confirm the full certificate is the only viable match for the
precertificate.

Rationale: If multiple different full certificates could reasonably
match a single precertificate, then it becomes trivial to issue
"hidden" certificates.

6) Given a precertificate and full certificate, it should not be
possible to (re)construct other full certificates given only their
precertificates.

Rationale: Leak/discovery of a single full certificate should not
cause a system collapse.

7) The only entity that knows if a certificate for their domain was
not supposed to be issued is entity who was the domain registrant at
the time of issuance.

Rationale: While others can guess based on heuristics, only the
registrant can say with authority "I think this was unauthorized"

8) The only way to get the content of a full certificate is to have a
full certificate.

Rationale: An alternative option is to have some sort of escrow key
that can "unlock" a precertificate.  This quickly turns into 'where do
we keep the escrow key?' and 'who gets to access the escrow key?'.  If
there is no such thing, then these questions don't exist.

Do others agree that these are true and can be used as givens for
reviewing any proposed designs?

Thanks,
Peter

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 6 Mar 2017 14:48:44 +0000

Looks great, but what does viable mean in "is the only viable match" ?

---

From: Peter Bowen <[email-masked]>
Date: Mon, 6 Mar 2017 07:05:55 -0800

> Looks great, but what does viable mean in "is the only viable match" ?

For example, if a redacted name looks like '??.example.com' and the
definition of '??' is "matches one or more labels", then a precert
with:

  "dNSName:??.example.com, dNSName:??.example.com, dNSName:??.example.com"

could match infinite names.

On the other hand, a redacted name is "??ab347e5e.example.com" and the
value after the "??" is a truncated hash, then the number of matches
is much lower.  Once you consider that these are dNSName, so the only
valid characters are a-z, A-Z, 0-9, '-', '.', and maybe '_', the
chance of two strings colliding is very low, even with a severely
truncated hash.

If the '??' rule is used, then a malicious CA could issue two
different certificates with the same serial number, one that is
"innocent" and one that has the real target name.

Thanks,
Peter

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 6 Mar 2017 15:12:46 +0000

> For example ...

Got it, thanks.

---

From: Andrew Ayer <[email-masked]>
Date: Mon, 6 Mar 2017 08:27:01 -0800

Hi Peter,

I generally agree with your list of statements, but #7 is imprecise:

On Sun, 5 Mar 2017 22:06:31 -0800

> not supposed to be issued is entity who was the domain registrant at

To be more precise, the only entity that knows if a certificate for
their domain *did not undergo proper domain validation* is the entity
who was the domain registrant at the time of issuance[1].  Many other
types of misissuances can be detected by anyone, such as SHA-1,
encoding errors, illegal characters in dnsName SANs, overly-long
validity, etc.

Regards,
Andrew

[1] technically, at the time the CA is required to check, but that's
beside the point

---

From: Eric Mill <[email-masked]>
Date: Mon, 6 Mar 2017 14:34:53 -0500

> there is not currently support for making it mandatory.

Just to be clear, I think you're saying there is not currently support by
*any* client or relying party for making non-logging equivalent to
misissuance. That is different than saying that there is not currently
broad support across the client/RP ecosystem for refusing to accept
non-logged certificates.

> registrant can say with authority "I think this was unauthorized"

While this is true, including Andrew's caveats, this does risk
unintentionally implying that the only benefit to CT that must be
considered when discussing redaction proposals is that of detecting
certificates issued without proper domain validation control.

CT provides broader benefits than that, some of which are implied by
Andrew's notes about automatable detections of BR Violations. Some benefits
can also be seen in the identification of undisclosed cross-signatures that
create gaps in the audited PKI that can range from small to tremendously
large.

-- Eric

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

-- 
konklone.com | @konklone <https://twitter.com/konklone>

---

From: Rob Stradling <[email-masked]>
Date: Mon, 6 Mar 2017 21:16:27 +0000

On 06/03/17 06:06, Peter Bowen wrote:
<snip>
> that can "unlock" a precertificate.

In previous iterations of 6962-bis, we proposed a redaction mechanism 
that envisaged replacing domains labels with ?s in precertificates. 
That mechanism was deemed problematic by the Chrome team precisely 
because "The only way to get the content of a full certificate is to 
have a full certificate".
What recourse does a domain owner have when they discover a 
precertificate for their domain space that they don't recognize?  How do 
they figure out whether the (pre)cert was misissued or whether it was 
legitimately requested by a different team within their organization?

The redaction mechanism that's documented in 
https://tools.ietf.org/html/draft-strad-trans-redaction-01#section-3.3 
attempted to find a solution to this problem of recourse by swapping ?s 
for a hash of the unredacted domain.  However, this mechanism has also 
been deemed problematic, because it could be trivial to determine 
unredacted labels via dictionary attacks.

I think a "sort of escrow key" may be the only viable way to construct a 
redaction mechanism that is deemed non-problematic by everyone.

> This quickly turns into 'where do we keep the escrow key?' and 'who gets
> to access the escrow key?'.  If there is no such thing, then these
> questions don't exist.

I think these questions will need to be both asked and answered, 
although I'd be delighted to be proved wrong.

> reviewing any proposed designs?

Your other points all LGTM.

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

---

From: Ben Laurie <[email-masked]>
Date: Mon, 6 Mar 2017 21:22:30 +0000

I think you can waste a lot of brainpower on redaction, but really the
answer is: if you don't want to publish your names, then don't use a
mechanism that requires you to. There are alternatives: name-constrained
sub-CAs. Private CAs. You can even have private CT to go along with them.
Why mess up a protocol whose intent is to show everything?

On 6 March 2017 at 21:16, Rob Stradling <[email-masked]> wrote:

> In previous iterations of 6962-bis, we proposed a redaction mechanism that
> envisaged replacing domains labels with ?s in precertificates. That
> mechanism was deemed problematic by the Chrome team precisely because "The
> only way to get the content of a full certificate is to have a full
> certificate".
> What recourse does a domain owner have when they discover a precertificate
> for their domain space that they don't recognize?  How do they figure out
> whether the (pre)cert was misissued or whether it was legitimately
> requested by a different team within their organization?
>
> attempted to find a solution to this problem of recourse by swapping ?s for
> a hash of the unredacted domain.  However, this mechanism has also been
> deemed problematic, because it could be trivial to determine unredacted
> labels via dictionary attacks.
>
> I think these questions will need to be both asked and answered, although
> I'd be delighted to be proved wrong.
>

---

From: Ryan Sleevi <[email-masked]>
Date: Mon, 6 Mar 2017 16:36:40 -0500

> Why mess up a protocol whose intent is to show everything?

Ben:

Name-constrained sub-CAs have not been accepted by Chrome as a redaction
mechanism. They were moved to the redaction spec precisely because they are
a variation of redaction.

---

From: Rob Stradling <[email-masked]>
Date: Mon, 6 Mar 2017 21:39:26 +0000

On 06/03/17 21:22, Ben Laurie wrote:
> mechanism that requires you to.

I agree that that's the ideal answer, but as we've seen, there is 
resistance to that answer from various participants in the CT ecosystem.

> There are alternatives: name-constrained sub-CAs.

We removed that option from 6962-bis.  It's now in 
draft-strad-trans-redaction, but IIRC the Chrome team hinted that 
they're unlikely to ever support it (at least in its current form).

> Private CAs. You can even have private CT to go along with them.

Private CAs don't suit every use case, AFAIK.

> Why mess up a protocol whose intent is to show everything?

Because Security and Useability aren't always in perfect harmony?

Much as I'd love to stop wasting brainpower on redaction, I think it's a 
conversation that needs to continue for now (although not indefinitely!)

> On 6 March 2017 at 21:16, Rob Stradling wrote:
>
>     In previous iterations of 6962-bis, we proposed a redaction
>     mechanism that envisaged replacing domains labels with ?s in
>     precertificates. That mechanism was deemed problematic by the Chrome
>     team precisely because "The only way to get the content of a full
>     certificate is to have a full certificate".
>     precertificate for their domain space that they don't recognize?
>     How do they figure out whether the (pre)cert was misissued or
>     whether it was legitimately requested by a different team within
>     their organization?
>
>     <https://tools.ietf.org/html/draft-strad-trans-redaction-01#section-3.3>
>     attempted to find a solution to this problem of recourse by swapping
>     ?s for a hash of the unredacted domain.  However, this mechanism has
>     also been deemed problematic, because it could be trivial to
>     determine unredacted labels via dictionary attacks.
>
>     I think a "sort of escrow key" may be the only viable way to
>     construct a redaction mechanism that is deemed non-problematic by
>     everyone.
>
>     [email-masked] <mailto:[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: Jeremy Rowley <[email-masked]>
Date: Mon, 6 Mar 2017 22:26:37 +0000

On the CT days, there was an emphasis on a distinction between white washing
a cert (removing it from CT) and redaction. Is the white washing in scope
for the Trans list and this discussion or should it be separate? 

I ask because two of the main arguments cited for redaction tend to be:
1) Network/New project mapping reveals
2) Inclusion if PII in logged certs

If white washing address the second concern, a specification around that
process could eliminate a good deal of the push for redaction.

-----Original Message-----
From: Trans [mailto:[email-masked]] On Behalf Of Rob Stradling
Sent: Monday, March 6, 2017 2:39 PM
To: Ben Laurie <[email-masked]>
Cc: [email-masked]; Peter Bowen <[email-masked]>
Subject: Re: [Trans] Reviving Redaction

> mechanism that requires you to.

I agree that that's the ideal answer, but as we've seen, there is resistance
to that answer from various participants in the CT ecosystem.

We removed that option from 6962-bis.  It's now in
draft-strad-trans-redaction, but IIRC the Chrome team hinted that they're
unlikely to ever support it (at least in its current form).

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: Peter Bowen <[email-masked]>
Date: Mon, 6 Mar 2017 14:50:34 -0800

> a variation of redaction.

Yes, Ryan hit the nail on the head.  I'm trying to waste brainpower on
coming up with a plan Chrome will accept that allows named-constrained
sub-CAs not log the full details of all the certs they issue.

If Chrome had accepted logging the named-constrained CA certificate in
lieu of logging the end-entity certificate, we would be done.

Thanks,
Peter

---

From: Rob Stradling <[email-masked]>
Date: Mon, 6 Mar 2017 23:30:32 +0000

I think the "white out" proposal that was discussed at the CT Policy 
Days is likely to be far more controversial than the various redaction 
proposals.

"White out" proposes a mechanism for removing or omitting entire 
certificates from logs whilst still "proving" that those certificates 
are "included".  Relying parties have to trust the log to only "white 
out" certs for good reasons.  ISTM that this defeats most of the purpose 
of CT!

 From https://tools.ietf.org/html/rfc6962#section-1...
   "Certificate transparency aims to mitigate the problem of misissued
    certificates by providing publicly auditable, append-only, untrusted
    logs of all issued certificates."

ISTM that supporting "white out" would turn that sentence into this...
   "Certificate transparency aims to mitigate the problem of misissued
    certificates by providing publicly auditable, modifiable, trusted
    logs of some issued certificates."

That sounds not too dissimilar to the WebPKI minus CT!

---

From: Ryan Sleevi <[email-masked]>
Date: Mon, 6 Mar 2017 18:46:15 -0500

On Mon, Mar 6, 2017 at 6:30 PM, Rob Stradling <[email-masked]>
wrote:

> I think the "white out" proposal that was discussed at the CT Policy Days
> is likely to be far more controversial than the various redaction proposals.
>
> certificates from logs whilst still "proving" that those certificates are
> "included".  Relying parties have to trust the log to only "white out"
> certs for good reasons.  ISTM that this defeats most of the purpose of CT!
>

Indeed.

I think the takeaway from the proposed solution is that it undermines the
goals of CT to provide the ability to later 'remove' certificates (by
effectively inserting a later node in the tree that includes sufficient
data to recreate the Merkle Tree, by providing its hash, while refusing to
provide that entry to clients).

This is the question of whether to solve this problem technologically - if
it is even possible (and full disclosure, like Rob states, I believe this
seriously undermines the security guarantees) - or whether through policy.
The policy approach is simply to shut the log down, should it ever need to
violate the append-only property, thereby avoiding any particular notion of
additional trustworthiness.

This then becomes an 'implementation guidance' aspect, as clients,
monitor/auditors, and CAs must all be prepared to adjust to changes in
trusted logs commiserate to their belief such a mechanism is
necessary/appropriate. That is, if implementations do not believe there
exists a need to 'remove' certificates, or are willing and able to tolerate
the disappearance of a log, then no further action is necessary.

---

From: Jeremy Rowley <[email-masked]>
Date: Tue, 7 Mar 2017 00:00:55 +0000

Agreed, it’s more controversial, but whether a white out mechanism undermines CT depends on whether a whited-out entry still serves as a SCT.  If a whited-out entry does not count towards a the log requirements, then it’s the same as not logging the cert in the first place. I’m not sure how that would work yet, but that was a suggestion at the CT days.

Currently, the Chrome policy doesn’t permit quickly spinning up new logs with omitted certificates.  

From: Ryan Sleevi [mailto:[email-masked]] 
Sent: Monday, March 6, 2017 4:46 PM
To: Rob Stradling <[email-masked]>
Cc: Jeremy Rowley <[email-masked]>; Ben Laurie <[email-masked]>; [email-masked]; Peter Bowen <[email-masked]>
Subject: Re: [Trans] White out (was Re: Reviving Redaction)

On Mon, Mar 6, 2017 at 6:30 PM, Rob Stradling <[email-masked] <mailto:[email-masked]> > wrote:

I think the "white out" proposal that was discussed at the CT Policy Days is likely to be far more controversial than the various redaction proposals.

"White out" proposes a mechanism for removing or omitting entire certificates from logs whilst still "proving" that those certificates are "included".  Relying parties have to trust the log to only "white out" certs for good reasons.  ISTM that this defeats most of the purpose of CT!

Indeed.

I think the takeaway from the proposed solution is that it undermines the goals of CT to provide the ability to later 'remove' certificates (by effectively inserting a later node in the tree that includes sufficient data to recreate the Merkle Tree, by providing its hash, while refusing to provide that entry to clients).

This is the question of whether to solve this problem technologically - if it is even possible (and full disclosure, like Rob states, I believe this seriously undermines the security guarantees) - or whether through policy. The policy approach is simply to shut the log down, should it ever need to violate the append-only property, thereby avoiding any particular notion of additional trustworthiness.

This then becomes an 'implementation guidance' aspect, as clients, monitor/auditors, and CAs must all be prepared to adjust to changes in trusted logs commiserate to their belief such a mechanism is necessary/appropriate. That is, if implementations do not believe there exists a need to 'remove' certificates, or are willing and able to tolerate the disappearance of a log, then no further action is necessary.

---

From: Ryan Sleevi <[email-masked]>
Date: Mon, 6 Mar 2017 21:16:27 -0500

> with omitted certificates.

That's correct, and as discussed, that's open to change to address various
implementation concerns.

Which is my point - that this isn't necessarily one which requires a
technical solution or engineering, and is more an aspect of implementation
and implementation guidance. Everything provided by RFC 6962 or RFC
6962-bis supports addressing this concern without any changes to either
spec - provided that implementations (which believe such concerns are
valid) can appropriately address them via other, provided-for means.

I don't think we should expend energy on specifying that unless we have
reason to believe that it's impossible to implement agility for logs IF
such a scenario were to happen and be seen as valid. But there's no reason
to overly complicate and undermine the security properties to do so.

---

From: Rob Stradling <[email-masked]>
Date: Tue, 7 Mar 2017 09:50:42 +0000

On 07/03/17 00:00, Jeremy Rowley wrote:
> Agreed, it’s more controversial, but whether a white out mechanism
> undermines CT depends on whether a whited-out entry still serves as a
> SCT.  If a whited-out entry does not count towards a the log
> requirements, then it’s the same as not logging the cert in the first
> place. I’m not sure how that would work yet, but that was a suggestion
> at the CT days.

I think the only way it could conceivably work (without undermining CT) 
is by introducing a revocation mechanism for SCTs and a revocation 
mechanism for inclusion proofs, both of which would need to be 100% 
reliable.

Let's not go there.

> *From:*Ryan Sleevi [mailto:[email-masked]]
> *Sent:* Monday, March 6, 2017 4:46 PM
> *To:* Rob Stradling <[email-masked]>
> *Cc:* Jeremy Rowley <[email-masked]>; Ben Laurie
> <[email-masked]>; [email-masked]; Peter Bowen <[email-masked]>
> *Subject:* Re: [Trans] White out (was Re: Reviving Redaction)
>
>
>
>
>
>
>
> On Mon, Mar 6, 2017 at 6:30 PM, Rob Stradling <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Days is likely to be far more controversial than the various
>     redaction proposals.
>
>     certificates from logs whilst still "proving" that those
>     certificates are "included".  Relying parties have to trust the log
>     to only "white out" certs for good reasons.  ISTM that this defeats
>     most of the purpose of CT!
>
> I think the takeaway from the proposed solution is that it undermines
> the goals of CT to provide the ability to later 'remove' certificates
> (by effectively inserting a later node in the tree that includes
> sufficient data to recreate the Merkle Tree, by providing its hash,
> while refusing to provide that entry to clients).
>
>
>
> This is the question of whether to solve this problem technologically -
> if it is even possible (and full disclosure, like Rob states, I believe
> this seriously undermines the security guarantees) - or whether through
> policy. The policy approach is simply to shut the log down, should it
> ever need to violate the append-only property, thereby avoiding any
> particular notion of additional trustworthiness.
>
>
>
> exists a need to 'remove' certificates, or are willing and able to
> tolerate the disappearance of a log, then no further action is necessary.
>

---

From: Ben Laurie <[email-masked]>
Date: Tue, 7 Mar 2017 17:43:39 +0000

> That sounds not too dissimilar to the WebPKI minus CT!

I think if this kind of thing is going to work, you have to also log the
reason for removing the cert (e.g. link to court order :-).

>> resistance
>>>         Rationale: An alternative option is to have some sort of escrow
>>>
>> key
>>

---

From: Ben Laurie <[email-masked]>
Date: Tue, 7 Mar 2017 17:44:33 +0000

> a variation of redaction.

Ah, good point. They're probably a good idea for private CAs, though. :-)

---

From: Jeremy Rowley <[email-masked]>
Date: Tue, 7 Mar 2017 17:46:38 +0000

I highly doubt there would be a court order. However, I think linking to the 
applicable cease and desist, take down request, privacy issue, etc. is 
reasonable.

From: Ben Laurie [mailto:[email-masked]]
Sent: Tuesday, March 7, 2017 10:44 AM
To: Rob Stradling <[email-masked]>
Cc: Jeremy Rowley <[email-masked]>; [email-masked]; Peter Bowen 
<[email-masked]>
Subject: Re: White out (was Re: [Trans] Reviving Redaction)

On 6 March 2017 at 23:30, Rob Stradling <[email-masked] 
<mailto:[email-masked]> > wrote:

I think the "white out" proposal that was discussed at the CT Policy Days is 
likely to be far more controversial than the various redaction proposals.

"White out" proposes a mechanism for removing or omitting entire certificates 
from logs whilst still "proving" that those certificates are "included". 
Relying parties have to trust the log to only "white out" certs for good 
reasons.  ISTM that this defeats most of the purpose of CT!

-----Original Message-----
From: Trans [mailto:[email-masked] <mailto:[email-masked]> ] 
On Behalf Of Rob Stradling
Sent: Monday, March 6, 2017 2:39 PM
To: Ben Laurie <[email-masked] <mailto:[email-masked]> >
Cc: [email-masked] <mailto:[email-masked]> ; Peter Bowen <[email-masked] 
<mailto:[email-masked]> >
Subject: Re: [Trans] Reviving Redaction

        8) The only way to get the content of a full certificate is to
        have a
        full certificate.

key

        This quickly turns into 'where do we keep the escrow key?' and
        'who gets
        to access the escrow key?'.  If there is no such thing, then these
        questions don't exist.

---

From: Ryan Sleevi <[email-masked]>
Date: Tue, 7 Mar 2017 22:13:48 -0500

> there is no such thing, then these questions don't exist.

Can you elaborate on how you derived this principle?

I think Rob captured well, which is there's a tension here - particularly
in the case when the domain holder signals that the CA misissued - as to
how to assess the impact and/or take corrective measure. There's a blurry
line here between what's technically required versus what is addressed by
policy external to the technology. So I think it'd be useful to understand
how this one was derived.

---

From: Peter Bowen <[email-masked]>
Date: Tue, 7 Mar 2017 19:36:31 -0800

On Tue, Mar 7, 2017 at 7:13 PM, Ryan Sleevi <[email-masked]> wrote:
> I think Rob captured well, which is there's a tension here - particularly in
> the case when the domain holder signals that the CA misissued - as to how to
> assess the impact and/or take corrective measure. There's a blurry line here
> between what's technically required versus what is addressed by policy
> external to the technology. So I think it'd be useful to understand how this
> one was derived.

I think I might have phrased it poorly.  It was not meant to be a
policy principal, rather a technical one.  What I was trying to say is
that I don't think having an encrypted blob in the precertificate
(i.e. publicly escrowed) that has unredacted names is a good path.

I am not intending to rule out a policy that says the holder of the
full certificate (i.e. the CA) must provide it to X upon Y.  My focus
was on the "reversibility" of the precertificate in cases where the
precertificate does not contain all the data in the final certificate.

Thanks,
Peter

---

From: Ryan Sleevi <[email-masked]>
Date: Wed, 8 Mar 2017 00:13:12 -0500

> precertificate does not contain all the data in the final certificate.

I think the question of whether or not a precertificate should be able to
produce a full certificate is, in some ways, related to the policy
discussions. That is, a technical solution is a means to circumvent the
policy discussion, and a policy discussion is a means to circumvent a
technical solution. I don't know that I can agree a priori that we should
rule this out, if only because it implies a policy solution is viable, but
we don't know that.

As far as statements go, while there's an intuitive appeal about the first
statement, it does seem to conflict with some degree of RFC 7719 - namely,
it seems to introduce additional terms that may conflict with or overlap
with the terminology there. In particular, the claim that the
existence/non-existence of a registered domain as public information sits
within that space of uncertainty as to whether you're describing something
akin/similar to "public suffix", or something akin to the
registry/registrant relationship.

I highlight this because I think Statement 1 is similar to Statement 8. If
we're describing the technical capabilities, and ignoring any policy
concerns, then I think 7719 and Statement 1 are in some degree of conflict.
If we're describing possible and/or desired outcomes, then I think
Statement 1 is a reasonable statement. Put differently, I'm unclear if
Statement 1 is "This is a thing that currently exists" or whether it's
"This is a thing that (for policy reasons related to CT and its deployment
in common browser clients for purposes of the WebPKI) should exist". If the
former, it's hard to support. If the latter, I agree that it represents at
least a minimum, both of goal and of what is, as you note, effectively
practiced at the TLD zone level. But it's a policy statement :)

---

From: Peter Bowen <[email-masked]>
Date: Tue, 7 Mar 2017 21:38:07 -0800

On Tue, Mar 7, 2017 at 9:13 PM, Ryan Sleevi <[email-masked]> wrote:
> If we're describing possible and/or desired outcomes, then I think Statement
> 1 is a reasonable statement. Put differently, I'm unclear if Statement 1 is
> "This is a thing that currently exists" or whether it's "This is a thing
> that (for policy reasons related to CT and its deployment in common browser
> clients for purposes of the WebPKI) should exist". If the former, it's hard
> to support. If the latter, I agree that it represents at least a minimum,
> both of goal and of what is, as you note, effectively practiced at the TLD
> zone level. But it's a policy statement :)

OK, rephrasing in RFC 7719 terms and focusing on the reality:

For all TLDs which consist of three or more letters, except for mil,
gov, and int, and for certain two letter TLDs, the existence of a
domain name consisting of the label immediately below plus the label
that is the TLD is public information.

This is ICANN policy as it exists today.  It is a fact independent of
browsers or CT.  Additionally certain two letter TLDs, such as us and
se, have the same policy.  I'm just asking for stipulation that due to
the policies enforced by ICANN, it is not valid to say "the existence
of companycorporationpromocode.com. is not public information".