Name Redaction

[Ryan Sleevi]

Thanks to everyone who offered feedback on Name Redaction during the policy discussion at https://groups.google.com/a/chromium.org/d/topic/ct-policy/vsTzv8oNcws/discussion . 

It is clear that, under RFC 6962, name redaction is not a supported behaviour. As such, certificates that adopt a non-standard form of redaction, such as some have proposed [1], will not be recognized as conforming to the Chrome CT Policy, as they do not conform to RFC 6962's definition of PreCertificates. CAs that choose to log such certificates to the set of CT Logs trusted by Chrome will, in effect, be logging public commitments to issue certificates which violate RFC 5280 and violate the CA/Browser Forum's Baseline Requirements. As with any other violation of RFC 5280 or the Baseline Requirements, such certificates will be seen as misissued, and thus may result in further action. CAs which choose to log such redacted certificates to CT Logs not trusted by Chrome will behave no differently than CAs which choose to log unredacted certificates to CT Logs not trusted by Chrome - that is, the SCTs will not be trusted because the log is not trusted.

While the IETF TRANS WG continues to work on RFC6962-bis as a work item, and the current draft version (draft-14) details possible technical means for redaction of certificate names, unless and until the concerns raised in [2] are meaningfully addressed, the Chrome CT Policy is unlikely to recognize such certificates as being sufficiently disclosed. That is, the expectation will be that any certificate that wishes to be recognized as complying with the Chrome CT Policy will need to be disclosed in its full form, even if RFC6962-bis provides a technical algorithm for how redaction may work, due to the many concerns raised in the aforementioned thread.

Until the concerns in [2] have been addressed, such SCTs will not comply with the Chrome CT Policy, and as such, may result in the failure to recognize the certificate as sufficiently disclosed for Extended Validation or, in some cases, as sufficiently disclosed to be recognized as trustworthy.

While it should be clear to all participants that RFC 6962 does not accommodate redaction, nor does Chrome's CT Policy presently recognize RFC 6962-bis, this should not be seen as a rejection of redaction outright. As stated in [2], and in the broader thread in which it was part of [3], there are a number of concerns with redaction and ensuring the proper balance between the CAs, domain holders, and users. If a solution can be found that balances the needs of the ecosystem, the public, and domain holders concerned about misissuance by CAs, name redaction can be revisited, although only if the concerns raised in that thread have been meaningfully addressed. Certificates which are logged in a redacted form prior to the development and adoption of such policies, however, will not be recognized as conforming to the Chrome CT Policy.

[1] http://www.symantec.com/connect/blogs/privacy-redaction-and-certificate-transparency

[2] https://groups.google.com/a/chromium.org/d/msg/ct-policy/vsTzv8oNcws/imuC3iloBwAJ

[3] https://groups.google.com/a/chromium.org/d/topic/ct-policy/vsTzv8oNcws/discussion

[Vinayak Raghuvamshi]

I have a query regarding your statement "Until the concerns in [2] have been addressed, such SCTs will not comply with the Chrome CT Policy, and as such, may result in the failure to recognize the certificate as sufficiently disclosed for Extended Validation or, in some cases, as sufficiently disclosed to be recognized as trustworthy."

Does it mean that redacted certificates would be considered non compliant only for EV certificates? OR is it saying that 'in some cases' even non-EV certificates would be considered non-compliant if using redacted logging?

[Ryan Sleevi]

On Mon, May 23, 2016 at 11:08 PM, Vinayak Raghuvamshi <vraghu...@gmail.com> wrote:

I have a query regarding your statement "Until the concerns in [2] have been addressed, such SCTs will not comply with the Chrome CT Policy, and as such, may result in the failure to recognize the certificate as sufficiently disclosed for Extended Validation or, in some cases, as sufficiently disclosed to be recognized as trustworthy."

Does it mean that redacted certificates would be considered non compliant only for EV certificates? OR is it saying that 'in some cases' even non-EV certificates would be considered non-compliant if using redacted logging?

This is addressed at https://www.chromium.org/Home/chromium-security/certificate-transparency

See the "Certificate Transparency in Chrome" policy. There is only one notion of a "CT Qualified" certificate. In all cases, to be recognized as Extended Validated, a certificate needs to be CT Qualified. In addition, certificates may be required to be CT Qualified - either on the basis of the issuing CA, or on the basis of site operator decision.

An SCT from an unrecognized CT Log will not contribute towards CT Qualification. Similarly, a redacted SCT in a future, RFC 6962-bis supporting world (which is not supported by the CT Policy), will not count towards CT Qualification.

[Richard Salz]

Perhaps I am too cynical, but it seemed clear to me from the outset that this conclusion was pre-ordained.

[Ryan Sleevi]

On Tue, May 24, 2016 at 6:01 AM, Richard Salz <rich...@gmail.com> wrote:

Perhaps I am too cynical, but it seemed clear to me from the outset that this conclusion was pre-ordained.

That does sound too cynical.

Perhaps the way to address that cynicism is to look at ways to address those concerns? Or is this just an expression of cynicism, rather than support for redaction?

[Richard Salz]

I support redaction.

If only to avoid offending or hurting the feelings of colleagues that I hope to continue working with, I will say no more.

[Matt Palmer]

On Tue, May 24, 2016 at 09:01:59AM -0400, Richard Salz wrote:
> Perhaps I am too cynical, but it seemed clear to me from the outset that
> this conclusion was pre-ordained.

That's because redaction is an idea with giant flaws which completely
undermines the concept of transparency in the real-world threat model in
which the web PKI operates.

- Matt

--
[M]ost of the other people here [...] drive cars that they have personally
built (starting with iron ore, charcoal, and a Malaysian turn-signal tree)
[...] but I wimp out on all of those points. Sometimes there are advantages
to paying somebody else to do it for you. -- Matt Roberds, in the Monastery

[Andrew Ayer]

On Mon, 23 May 2016 22:34:01 -0700 (PDT)
Ryan Sleevi <rsl...@chromium.org> wrote:

> As such, certificates that adopt a non-standard form of
> redaction, such as some have proposed [1], will not be recognized as
> conforming to the Chrome CT Policy, as they do not conform to RFC
> 6962's definition of PreCertificates. CAs that choose to log such
> certificates to the set of CT Logs trusted by Chrome will, in effect,
> be logging public commitments to issue certificates which violate RFC
> 5280 and violate the CA/Browser Forum's Baseline Requirements.

Hi Ryan,

This policy doesn't make sense to me, since anyone can submit
(pre-)certs to any log and logs do not track whether a (pre-)cert was
submitted by a CA or by someone else. It seems to me that the
signature ought to indicate the CA's commitment to issue the
certificate, as specified by Section 3.1 of RFC6962:

"The signature on the TBSCertificate indicates the
certificate authority's intent to issue a certificate.
This intent is considered binding (i.e., misissuance
of the Precertificate is considered equal to misissuance
of the final certificate)."

For instance, see this non-compliant pre-cert which has been logged to
two logs trusted by Chrome:

https://crt.sh/?id=20919705

Symantec will probably claim they didn't submit this pre-cert to these
logs. But how would one verify this claim? Even if Symantec didn't
submit this pre-cert themselves, was their choice to log implied by the
fact that the pre-cert chains to a trusted root, and thus *could* be
logged?

Regards,
Andrew

[Sanjay Modi]

To be clear Symantec is logging redacted pre-certificates only to deneb
log server. We want to provide our customers ability to monitor
certificates issued to their domains with an option to protect privacy of
their information.
This separate log sever is specifically setup for logging redacted
pre-certificates based on the feedback we received that broader CT
ecosystem is still reviewing redaction. While we encourage anyone to
monitor this log server, what anyone does with pre-certificates found in
this log server is beyond our control.


- Sanjay

>--
>You received this message because you are subscribed to the Google Groups
>"Certificate Transparency Policy" group.
>To unsubscribe from this group and stop receiving emails from it, send an
>email to ct-policy+...@chromium.org.
>To post to this group, send email to ct-p...@chromium.org.
>To view this discussion on the web visit
>https://groups.google.com/a/chromium.org/d/msgid/ct-policy/20160603102859.
>c26158e2ed4379635648213c%40andrewayer.name.

[Vinayak Raghuvamshi]

I guess Andrew's question was more for Google, regarding what it seems like logs do not track whether a (pre-)cert was
submitted by a CA or by someone else. I am interested in knowing if this was indeed the case. Can 'anyone' submit a (pre-)cert to the log?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/ct-policy/D3772B02.90383%25sanjay_modi%40symantec.com.

--

================================================
"God grant me the serenity to accept the things I cannot change,
the courage to change the things I can,
and the wisdom to know the difference."

 -Reinhold Niebuhr
================================================

[Ben Laurie]

On 4 June 2016 at 03:27, Vinayak Raghuvamshi <vraghu...@gmail.com> wrote:

I guess Andrew's question was more for Google, regarding what it seems like logs do not track whether a (pre-)cert was
submitted by a CA or by someone else. I am interested in knowing if this was indeed the case. Can 'anyone' submit a (pre-)cert to the log?

Anyone can, but that's a little misleading: first of all you have to have the (pre-)cert in order to submit it. In the case of certs, that's easy, they're found all over the web. But normally pre-certs are only ever found inside CAs.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/ct-policy/CALewoZOrt%2BzVm%2BVsY9s2Ycx0AvRJ_3RU6L83YJzsdsnhcut%2BVw%40mail.gmail.com.

[Peter Bowen]

On Sat, Jun 4, 2016 at 2:19 AM, 'Ben Laurie' via Certificate
Transparency Policy <ct-p...@chromium.org> wrote:
> On 4 June 2016 at 03:27, Vinayak Raghuvamshi <vraghu...@gmail.com> wrote:
>>
>> I guess Andrew's question was more for Google, regarding what it seems
>> like logs do not track whether a (pre-)cert was
>> submitted by a CA or by someone else. I am interested in knowing if this
>> was indeed the case. Can 'anyone' submit a (pre-)cert to the log?
>
>
> Anyone can, but that's a little misleading: first of all you have to have
> the (pre-)cert in order to submit it. In the case of certs, that's easy,
> they're found all over the web. But normally pre-certs are only ever found
> inside CAs.

They are also found inside CT logs. There is nothing that prevents
someone from downloading content from one log and submitting it to
another log. I've done this with certificates issued by my CA several
times.

Thanks,
Peter

[Sanjay Modi]

That¹s correct. CT Log server provides API to query entries inside it.
Once a certificate or pre-certifiate is logged to a log server anyone can
access that entry using API and post it to other log server(s).

Thanks,
- Sanjay

[Ryan Sleevi]

Andrew,

Thanks for highlighting the ambiguity between the intent that was communicated privately and how it was worded publicly.

You're absolutely correct that if a (pre-)certificate is issued, has a valid signature, and if that (pre-)certificate is made available (such as via a public log), then anyone can replay that certificate to any log that accepts that root as well. That is, it doesn't matter where the issuer themselves logs, if the log is public, the very act of issuance of a pre-certificate is equivalent to a public commitment to issue a (potentially violating) certificate - but only based on the chain of trust.

My hope, desire, and intent had been that this would have resulted in invalidating the signature on that (pre-)certificate prior to logging, such that no other log would accept it. A log server - since it'd be effectively exempt from any Chromium policy - could do any sort of filtering it wanted, such as, say, IP filtering who can submit such (invalidly signed) certificates or, alternatively, mangling the signature before making it publicly available, on the basis that its presence within the log was itself an apriori demonstration that the CA had issued it. Further yet, using an alternative PKI chain with separate keys would also have worked.

Am I wrong in thinking all of these were viable technical solutions to the concerns I'd originally outlined? I'd be curious for your review (and more broadly)

[Ryan Sleevi]

On Mon, Jun 6, 2016 at 6:03 PM, Ryan Sleevi <rsl...@chromium.org> wrote:

My hope, desire, and intent had been that this would have resulted in invalidating the signature on that (pre-)certificate prior to logging, such that no other log would accept it. A log server - since it'd be effectively exempt from any Chromium policy - could do any sort of filtering it wanted, such as, say, IP filtering who can submit such (invalidly signed) certificates or, alternatively, mangling the signature before making it publicly available, on the basis that its presence within the log was itself an apriori demonstration that the CA had issued it. Further yet, using an alternative PKI chain with separate keys would also have worked.

Am I wrong in thinking all of these were viable technical solutions to the concerns I'd originally outlined? I'd be curious for your review (and more broadly)

From other conversations, it seems there was some confusion about what I meant here by mangling the signature with an alternative PKI.

One option is rather simple, but comes with tradeoffs: A log, on receiving a submission (of redacted precert, since no such redacted certs should exist), could replace the signature BITSTRING of the certificate with random data, and sign that for the SCT. The logged entry would not be the submitted precert, but the 'mangled' precert - that's what would be made publicly available. The upside to this is that, because the original signature was mangled, no other party would be able to accept that precert unless they got the original (unmodified) precert, which no one but the original log will have seen, and the original log won't have stored it (because they logged the mangled version). The SCT itself will validate on clients, because SCTs for a precertificate are over the TBSCertificate (with the poison extension removed). The downside, however, is that there's no longer a cryptographic proof that the CA themselves authorized that precertificate (because the original signature on the precertificate proving it was intentionally destroyed).

For a case like a CA run log, whose log only accepts their certificates (and from their systems), the fact that the log itself signed it can be argued as cryptographic proof of intent to issue for those who care. That is, however, a weaker claim, and may not be desirable.

The alternative PKI solution is more complex, but allows such claims to be made more fully. Imagine a system - whether it's a proxy between the CA and the Log or a property of the log itself - which, when it encounters a PreCertificate signed by the CAs "real" key, replaces the signature on the PreCert with a different signature. We might call this the "Redaction Key". It's a key the CA can publish as what it uses for redacted certificates (or, for that matter, any certificates it issues). Again, the same pattern applies - rather than replace the original signature BITSTRING of the precertificate with random data, the CA signs it with their "Redaction Key". The logged entry is based on the "Redaction Key" - and as such, if anyone tries to submit it to other logs, those other logs will reject it - unless they know and recognize the "Redaction Key" (which, presumably, only the CAs' systems would). Relying parties would be unaffected, while monitors and auditors could use the fact that it was signed with the "Redaction Key" as cryptographic proof of the CA's intent to issue. This 'could' be done entirely between the submission step (e.g. without any changes to the precert code on the CA's side), either via a filtering proxy or via the CA's log itself. This has the upside that no other logs will accept such precerts, thus avoiding the ecosystem issues of non-standard issuance practices, but the downside of being even moreso a deviation from RFC 6962 than CAs engaging in this are already doing.

There's a final option, which involves zero further RFC 6962 violations, and that is to create a full shadow "Redaction PKI" - where a "Redaction Root" is created (with a unique SPKI unrelated to the publicly trusted PKI). The "Redaction Root" issues variations of all the intermediates the CA uses - again, with alternative keys (a very important step; reusing the key results in signatures that could allow submission to other logs). When a redacted precert is logged, rather than issuing from the 'real' system, it's issued from the "Redaction PKI". That is, the signature on the EE certificate to be logged comes from the "Redaction Intermediate", which has the same name and details as the 'real' intermediate, but with a different public/private key pair. The "Redaction Intermediate" is then signed by the "Redaction Root" - which is 'just' another root in the set of /get-roots. The CA can still attach the SCTs from the "Redaction PKI" to the 'real' cert, and clients will still validate, because a PreCert's SCT is over the TBSCertificate (which would be, for leaves, identical), but the logs entries returned - and their signature - all point to "Redaction Root" as the issuer (even though the final cert is issued by the *real* PKI).

The above solution can also be implemented as a filtering step between the CA systems and the logs, but in either event, it's more complex, and somewhat 'gross' in that it's exploiting a known security weakness of CT - which is how intermediates are logged. (For those who care, this is being debated in the TRANS WG, with some members thinking the above scenario is impossible, even though I just described how it can be in the real world).

Anyways, there's the much, MUCH longer write-up of the thinking about several different ways to accomplish redaction in a way that doesn't result in such certificates being logged to logs trusted by Chromium, and in ways that don't impact the ecosystem as profoundly as the current path does.

[Graham Edgecombe]

Hi Sanjay,

On Fri, Jun 03, 2016 at 12:43:07PM -0700, Sanjay Modi wrote:
> To be clear Symantec is logging redacted pre-certificates only to deneb
> log server. We want to provide our customers ability to monitor
> certificates issued to their domains with an option to protect privacy of
> their information.

Is the public key for Deneb published anywhere? It's required for people
to monitor the log (e.g. to verify the STHs it produces) but I haven't
been able to find it.

Thanks,

Graham

[Peter Bowen]

One could also just create a new toBeSigned structure that is used for
a RedactedPreCertificate (a new type). It could be as simple as:

RedactedPreCertificate ::= SIGNED{TBSRPCertificate}

TBSPRCertificate ::= SEQUENCE {
magic PRINTABLESTRING, -- always "RedactedPreCertificate"
tbsCertificate TBSCertificate
}

This would still have a verifiable signature but be clearly
NotACertificate. It also uses the standard SIGNED structure, so it
should work with most signing systems.

Thanks,
Peter

[Sanjay Modi]

Graham,
We will publish this info shortly.

Thanks,
- Sanjay

[Sanjay Modi]

Graham,
Public key for Deneb is published here -
https://knowledge.symantec.com/support/ssl-certificates-support/index?page=
content&id=AR2177

- Sanjay

On 6/7/16, 11:25 AM, "Graham Edgecombe" <gra...@grahamedgecombe.com> wrote:

[Rob Stradling]

Sanjay, I don't see the public key on that page.

I can see the Log ID, but that's the SHA-256 hash of the public key
rather than the public key itself.

--
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.

[Sanjay Modi]

It wasn¹t listed on the previous version of KB. It is listed now.

- Sanjay