Eduardo Robles Elvira | 21 Sep 13:36 2014

pretty URIs whose integrity is associated to transparent certificates

Hi everyone,

I will start right away recognizing that I'm not an expert in this
field, and that I might be proposing something dumb because it's
already being taken care of in some new promising standard I don't
know of, that resolves the issue in a much better way. Or it might
well happen that this is not the correct mailing list (maybe it's more
related to X509 extensions, or maybe public-webappsec mailing-list? I
just thought that it might be of interest to discuss it here). Please,
forgive me if that's case, as I'm new here.

Investigating, I recently found out that rfc6920 [1] ("Naming Things
with Hashes") defines a scheme for naming URIs with hashes too, by
creating the ni URI scheme name for .well-known URIs (rfc5785) [2].
That allows to have URIs that define incontestably the data they point
to. In my opinion, that's a very powerful and important concept,
security-wise.

A problem with ni .well-known URIs is that they look like this:

   https://agoravoting.org/.well-known/ni/sha256/UyaQV-Ev4rdLoHyJJWCi11OHfrYv9E1aGQAlMO2X_-Q

That's not very user friendly, and reduces the scope of where this
kind of secure URIs can be used. Hopefully, we can find a reasonable
and secure way to solve that problem. That's the aim of this thread.
The idea is to convert that link into something like the following,
without loosing much security:

    https://agoravoting.org/user-friendly

(Continue reading)

Fabrice Gautier | 19 Sep 23:38 2014
Picon

List of servers implementing CT ?

Hi,

Does anyone has a list of servers that implement CT with any of the
current known Logs ?

I've found www.digicert.com and embed.ct.digicert.com do, but is there
anywhere else out there ?

Ideally, I'd love a list of server along with which Log their certs
are logged into, and which type of SCTs they use.

Thanks

-- Fabrice
Fabrice Gautier | 19 Sep 20:50 2014
Picon

RFC 6962 clarification: entry type vs SCTs origin

Hi,

Since in RFC6962, the entry type in an SCTs is not explicit, one has
to either guess or try both type in order to validate the SCTs.

Does it make sense to infer the entry type from the origin of the SCT?

If the SCT is embedded in a cert, it has to be a precert entry. In
case of an SCT in the TLS handshake, I would expect in most case it's
an x509 entry.

But are there any situations where having a SCT with precert entry in
the TLS extension or OCSP response would make sense ?

Thanks

-- Fabrice
Melinda Shore | 17 Sep 23:45 2014
Picon

Where do things stand with the precertificate format discussion?

It looks like we've got two closely-related discussions:

1) precertificate format (representation), and
2) precertificate contents

There've been a couple of proposals for alternative representation,
including TBS (alternatively, the CertTemplate format from 4211) and
CRMF, and there seems to be some agreement congealing around Erwann's
summary:

>IIUC, what you propose is that the PreCert is a CMS (RFC5652) with a
>signedData content-type, for which the data is the TBSCertificate
>(name-redacted or not, no necessary poison extension). The SignerInfo
>refers to the PreCert issuer (CA or dedicated issuer, same as now).

>It can only work if the log signs the content (=TBSCertificate) and not
>the whole CMS, thus ignoring the PreCert issuer signature. Leaving that
>signature aside isn't more risky than it is now because it's already
> the case (the log removes the poison extension before signing the
> resulting certificate, right?).

with an open question around serial numbers.

Related, there's a proposal on the table to walk through cert data and
justify SCT contents.

Does this sound about right?

Melinda
(Continue reading)

Stephen Kent | 11 Sep 20:37 2014
Picon

redacted names and my proposal

Rob,

My intent, perhaps not well articulated, was that the SCT* submission 
would use
the same name redaction mechanism you proposed, if they prove to be viable.

The step 4 submission would include that same data, the serial number, 
and the
previously-issued SCT*. This would enable a log (doing more work) to 
ensure that
the SCT it issues is consistent between the two submissions. It also 
ensures that
the serial number is available for revocation when needed (which arises 
in only
some of the attack scenarios).

Thus, whatever name redaction mechanism the WG ultimately deems suitable 
should
work in my suggested two-phase protocol.

As Ben noted, there is a residual vulnerability with my proposal since 
the SCT*
is not tied to the serial number. But, in the context of the attack 
analysis I just
submitted,  I'm not sure how serious this vulnerability is, relative to 
the other
ones that I identified in the current CT design. We should discuss that 
later,
once we have agreement on an attack analysis.

(Continue reading)

Stephen Kent | 11 Sep 20:08 2014
Picon

Threat model outline, attack model

Since there was a suggestion that the current (-04) CT text contained an adequate
threat model, and if a better one were needed, I should offer text, I have done so.

Here is an initial cut at the sort of text I expect to see in an RFC dealing with
security mechanisms.

Steve
--------

Threat Model

 

Certificate Transparency (CT) is intended to detect and mitigate problems arising from mis-issuance of certificates, in the Web PKI context. The Web PKI context refers to the use of a set of Certification Authorities (CAs) that issue X.509 certificates to web servers to enable TLS-protected access by clients [cite WPKOPS?].

 

A certificate is characterized as mis-issued if the certificate is issued to an entity that is not authorized to represent the host (web server) named in the certificate Subject field or Subject Alternative Name extension. <do we want to focus exclusively on SAN vs. Subject?)

 

 

<Discuss classes of adversaries, motivations, and capabilities>

 

1. Criminals

 

2. Hacktivists

 

3. Nation states (intelligence organizations)

 

4. Other?

 

 

 

Attack Model and CT Mitigation Mechanisms

 

Certificate mis-issuance may arise in one of several ways.  The ways that CT helps detect and remedy mis-issuance depends on the context of the mis-issuance.

 

1. A non-malicious Web PKI CA may mis-issue a certificate as a result of an error or because it was the victim of a social engineering attack. In this case the CA has a record of the certificate and it is prepared to revoke the bogus certificate once it has been convinced of its error. If the CA is submitting the certificates it issues to one or more logs, there will be records of the bogus certificate. If one of Monitors to which the certificate was submitted is tracking the targeted Subject, it will detect the mis-issuance, and will alert the Subject. Because the CA has a record of the mis-issuance, the only data needed to identify the bogus certificate is the Subject (SAN) and public key, both of which are available from the log. The presence of an embed SCT in the bogus certificate, or an SCT accompanying the bogus certificate does not appear to contribute to the mitigation. (See Note 1 below.)

 

2. A non-malicious Web PKI CA may be the victim of an undetected attack (c.f., DigiNotar) which results in mis-issuance of one or more certificates. In this case the CA is not aware of the mis-issuance and may have no record of the certificate content.

 

a. The bogus certificate(s) may have been submitted to one or more logs prior to issuance, to acquire an embedded SCT, or post-issuance to acquire a standalone SCT. In either case, a Monitor to which the certificates had been submitted (and which is tracking the targeted Subject), would detect a bogus certificate and alert the targeted Subject. The Subject, in turn, would request the CA to revoke the bogus certificate. In this case, the CA will depend on the certificate serial number provided via the log entry, to effect revocation. (See Notes 1 + 2 below.) If TLS clients rejects a certificate when no SCT is present, this might motivate the attacker to log the bogus certificates, thus justifying such client behavior. (However, such client behavior needs to be defined in a way that is compatible with incremental deployment.) 

b. A bogus certificate may not have been submitted to any logs. In this case, Monitors will not detect the bogus certificate. If clients reject a certificate that lacks (or is not accompanied by) an SCT, the attacker will be thwarted in this case. (See Note 3 below.)

 

3. A malicious Web PKI CA may mis-issue a certificate as a result of being bribed or compelled to do so. (A CA might be compelled to issue a bogus certificate my a government agency or a criminal organization.)  This CA might be one or more tiers below a trust anchor (aka root CA).

a. The bogus certificate(s) may have been submitted to one or more logs prior to issuance, to acquire an embedded SCT, or post-issuance, to acquire a standalone SCT. In either case, a Monitor tracking the targeted Subject would detect a bogus certificate and alert the targeted subject. The Subject, in turn, would request the CA to revoke the bogus certificate. In this case, the CA may refuse, or substantially delay, to revoke the bogus certificate. (It could make excuses about inadequate proof that the certificate is bogus, or argue that it cannot quickly revoke the certificate because of local, legal concerns, etc.) In this case, the CT mechanisms have detected mis-issuance, but are not able to remedy the problem. (See Note 4 below.)

b. A bogus certificate may not have been submitted to any logs. In this case, Monitors will not detect the bogus certificate. If clients reject a certificate that lacks (or is not accompanied by) an SCT, the attacker will be thwarted in this case. (See Note 3 below.)

 

Notes:

 

1. If a CA submits the bogus certificate to logs, but these logs are not watched by a Monitor that is tracking the targeted Subject, CT will not mitigate a mis-issuance attack. It is not clear whether every Monitor MUST offer to track every Subject that requests its certificates be monitored. Absent such a guarantee, how do TLS clients and CAs know which set of Monitors will provide “sufficient” coverage. Unless these details are addressed, use of CT does not mitigation mis-issuance even when certificates are logged.

 

2. A CA being presented with evidence of a bogus certificate probably will require more than the serial number of the bogus certificate. It will want to verify the Issuer and Subject (SAN) to ensure that the certificate being revoked is not one that it has knowingly issued (which would fall under case #1). Other certificate fields and extensions may be of interest for forensic purposes, but are not required to effect revocation nor to verify that the certificate to be revoked is bogus. The SCT itself, because it contains a timestamp from a third party, is probably valuable for forensic purposes.

 

3. If a TLS client is to reject a certificate that lacks an embedded SCT, or is not accompanied by a post-issuance SCT, this behavior needs to be defined in a way that is compatible with incremental deployment. Issuing a warning to a (human) user is probably insufficient, based on experience with warnings displayed for expired certificates, lack of certificate revocation status information, and similar errors that violate RFC 5280 path validation rules.

 

4. The targeted Subject might request the parent or the offending CA to revoke the certificate of the non-cooperative CA. However, a request of this sort may be rejected, e.g., because of the potential for significant collateral damage.

 

 

As the analysis above shows, logs play a critical role in enabling detection of certificate mis-issuance, although they do not, per se, perform such detection. Thus logs represent another target for adversaries who wish to effect certificate mis-issuance. If a log generates SCTs for an attacker, but does not provide the log entries for these SCTs to all, or some, Monitors, CT will not detect mis-issuance. Thus it is critical that Monitors be able to compare the results of log data acquisition to detect mis-behaving logs.

 

Absent a protocol (a so-called “gossip” protocol) that enables Monitors to verify that data from logs are consistent, CT does not provide protection against logs that may conspire with, or be victims of, attackers effecting certificate mis-issuance. Even when a gossip protocol is deployed, it is necessary to describe how the CT system will deal with a mis-behaving or compromised log. For example, will there be a mechanism to alert all TLS clients to reject SCTs issued by such a log. Absent a description of a mitigation strategy to deal with mis-behaving or compromised logs, CT cannot ensure detection, much less remediation, of mis-issuance.

 

Monitors also play a critical role in detecting certificate mis-issuance, for Subjects that have requested monitoring of their certificates. Thus Monitors represent another target for adversaries who wish to effect certificate mis-issuance. If a Monitor is compromised by, or is complicit with, an attacker, it will fail to alert a Subject to a mis-issued certificate targeting the Subject. This raises the question of whether a Subject needs to request certificate monitoring from multiple sources to guard against such failures.

<!-- /* Font Definitions */ <at> font-face {font-family:"&#65325;&#65331; &#26126;&#26397;"; panose-1:0 0 0 0 0 0 0 0 0 0; mso-font-alt:"Optima ExtraBlack"; mso-font-charset:128; mso-generic-font-family:roman; mso-font-format:other; mso-font-pitch:fixed; mso-font-signature:1 134676480 16 0 131072 0;} <at> font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4; mso-font-charset:0; mso-generic-font-family:auto; mso-font-pitch:variable; mso-font-signature:-536870145 1107305727 0 0 415 0;} <at> font-face {font-family:Cambria; panose-1:2 4 5 3 5 4 6 3 2 4; mso-font-charset:0; mso-generic-font-family:auto; mso-font-pitch:variable; mso-font-signature:-536870145 1073743103 0 0 415 0;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {mso-style-unhide:no; mso-style-qformat:yes; mso-style-parent:""; margin:0in; margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:12.0pt; mso-bidi-font-size:10.0pt; font-family:Cambria; mso-ascii-font-family:Cambria; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:"&#65325;&#65331; &#26126;&#26397;"; mso-fareast-theme-font:minor-fareast; mso-hansi-font-family:Cambria; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi; mso-fareast-language:JA;} p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph {mso-style-priority:34; mso-style-unhide:no; mso-style-qformat:yes; margin-top:0in; margin-right:0in; margin-bottom:0in; margin-left:.5in; margin-bottom:.0001pt; mso-add-space:auto; mso-pagination:widow-orphan; font-size:12.0pt; mso-bidi-font-size:10.0pt; font-family:Cambria; mso-ascii-font-family:Cambria; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:"&#65325;&#65331; &#26126;&#26397;"; mso-fareast-theme-font:minor-fareast; mso-hansi-font-family:Cambria; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi; mso-fareast-language:JA;} p.MsoListParagraphCxSpFirst, li.MsoListParagraphCxSpFirst, div.MsoListParagraphCxSpFirst {mso-style-priority:34; mso-style-unhide:no; mso-style-qformat:yes; mso-style-type:export-only; margin-top:0in; margin-right:0in; margin-bottom:0in; margin-left:.5in; margin-bottom:.0001pt; mso-add-space:auto; mso-pagination:widow-orphan; font-size:12.0pt; mso-bidi-font-size:10.0pt; font-family:Cambria; mso-ascii-font-family:Cambria; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:"&#65325;&#65331; &#26126;&#26397;"; mso-fareast-theme-font:minor-fareast; mso-hansi-font-family:Cambria; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi; mso-fareast-language:JA;} p.MsoListParagraphCxSpMiddle, li.MsoListParagraphCxSpMiddle, div.MsoListParagraphCxSpMiddle {mso-style-priority:34; mso-style-unhide:no; mso-style-qformat:yes; mso-style-type:export-only; margin-top:0in; margin-right:0in; margin-bottom:0in; margin-left:.5in; margin-bottom:.0001pt; mso-add-space:auto; mso-pagination:widow-orphan; font-size:12.0pt; mso-bidi-font-size:10.0pt; font-family:Cambria; mso-ascii-font-family:Cambria; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:"&#65325;&#65331; &#26126;&#26397;"; mso-fareast-theme-font:minor-fareast; mso-hansi-font-family:Cambria; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi; mso-fareast-language:JA;} p.MsoListParagraphCxSpLast, li.MsoListParagraphCxSpLast, div.MsoListParagraphCxSpLast {mso-style-priority:34; mso-style-unhide:no; mso-style-qformat:yes; mso-style-type:export-only; margin-top:0in; margin-right:0in; margin-bottom:0in; margin-left:.5in; margin-bottom:.0001pt; mso-add-space:auto; mso-pagination:widow-orphan; font-size:12.0pt; mso-bidi-font-size:10.0pt; font-family:Cambria; mso-ascii-font-family:Cambria; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:"&#65325;&#65331; &#26126;&#26397;"; mso-fareast-theme-font:minor-fareast; mso-hansi-font-family:Cambria; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi; mso-fareast-language:JA;} .MsoChpDefault {mso-style-type:export-only; mso-default-props:yes; font-size:10.0pt; mso-ansi-font-size:10.0pt; mso-bidi-font-size:10.0pt; font-family:Cambria; mso-ascii-font-family:Cambria; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:"&#65325;&#65331; &#26126;&#26397;"; mso-fareast-theme-font:minor-fareast; mso-hansi-font-family:Cambria; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi; mso-fareast-language:JA;} <at> page WordSection1 {size:8.5in 792.7pt; margin:1.0in 1.0in 1.0in 1.0in; mso-header-margin:.5in; mso-footer-margin:.5in; mso-paper-source:0;} div.WordSection1 {page:WordSection1;} /* List Definitions */ <at> list l0 {mso-list-id:1291060163; mso-list-type:hybrid; mso-list-template-ids:164768244 67698703 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;} <at> list l0:level1 {mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in;} <at> list l0:level2 {mso-level-number-format:alpha-lower; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in;} <at> list l0:level3 {mso-level-number-format:roman-lower; mso-level-tab-stop:none; mso-level-number-position:right; text-indent:-9.0pt;} <at> list l0:level4 {mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in;} <at> list l0:level5 {mso-level-number-format:alpha-lower; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in;} <at> list l0:level6 {mso-level-number-format:roman-lower; mso-level-tab-stop:none; mso-level-number-position:right; text-indent:-9.0pt;} <at> list l0:level7 {mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in;} <at> list l0:level8 {mso-level-number-format:alpha-lower; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in;} <at> list l0:level9 {mso-level-number-format:roman-lower; mso-level-tab-stop:none; mso-level-number-position:right; text-indent:-9.0pt;} <at> list l1 {mso-list-id:1297949324; mso-list-type:hybrid; mso-list-template-ids:-188979792 67698703 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;} <at> list l1:level1 {mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in;} <at> list l1:level2 {mso-level-number-format:alpha-lower; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in;} <at> list l1:level3 {mso-level-number-format:roman-lower; mso-level-tab-stop:none; mso-level-number-position:right; text-indent:-9.0pt;} <at> list l1:level4 {mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in;} <at> list l1:level5 {mso-level-number-format:alpha-lower; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in;} <at> list l1:level6 {mso-level-number-format:roman-lower; mso-level-tab-stop:none; mso-level-number-position:right; text-indent:-9.0pt;} <at> list l1:level7 {mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in;} <at> list l1:level8 {mso-level-number-format:alpha-lower; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in;} <at> list l1:level9 {mso-level-number-format:roman-lower; mso-level-tab-stop:none; mso-level-number-position:right; text-indent:-9.0pt;} <at> list l2 {mso-list-id:1602104492; mso-list-type:hybrid; mso-list-template-ids:-1576256300 67698703 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;} <at> list l2:level1 {mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in;} <at> list l2:level2 {mso-level-number-format:alpha-lower; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in;} <at> list l2:level3 {mso-level-number-format:roman-lower; mso-level-tab-stop:none; mso-level-number-position:right; text-indent:-9.0pt;} <at> list l2:level4 {mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in;} <at> list l2:level5 {mso-level-number-format:alpha-lower; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in;} <at> list l2:level6 {mso-level-number-format:roman-lower; mso-level-tab-stop:none; mso-level-number-position:right; text-indent:-9.0pt;} <at> list l2:level7 {mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in;} <at> list l2:level8 {mso-level-number-format:alpha-lower; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in;} <at> list l2:level9 {mso-level-number-format:roman-lower; mso-level-tab-stop:none; mso-level-number-position:right; text-indent:-9.0pt;} ol {margin-bottom:0in;} ul {margin-bottom:0in;} -->
_______________________________________________
Trans mailing list
Trans <at> ietf.org
https://www.ietf.org/mailman/listinfo/trans
Erwann Abalea | 11 Sep 12:40 2014
Picon

Certificate and Precertificate extensions ordering

Bonjour,

It seems there's no constraint on the order of extensions in the final certificate regarding to the Precert.
Won't it be problematic if the browser wants to validate the SCT signatures by constructing the Precert from the final certificate? Where should a CA add the poisonous extension? And the future "redactedlabels" extension (it has no name)?

--
Erwann.
_______________________________________________
Trans mailing list
Trans <at> ietf.org
https://www.ietf.org/mailman/listinfo/trans
Melinda Shore | 8 Sep 20:50 2014
Picon

Precertificate format

It seems as if we've been talking about precertificate format for
quite some time, without coming to resolution.  Let's try to find
agreement on how to handle it and close issue 26.

The ticket, with description, is here:
http://trac.tools.ietf.org/wg/trans/trac/ticket/26

The fundamental problem is that because precertificates are currently
encoded as X.509 structures we have the potential for two certificates
to exist with the same issuer and same serial number.  Because the
precertificate is not usable as a TLS certificate in practice, this
may not be an issue.  However, it's a clear violation of section 4.1.2.2
in 5280 (and to be honest I'm a little fuzzy on its implications for
CRL processing).

So, are you all comfortable with letting the X.509 representation
stand, or do you have an alternative proposal?

Thanks,

Melinda
Fabrice | 30 Aug 22:48 2014
Picon

OCSP and SCTs

Hi,

Regarding the transport of SCTs as part of OCSP responses, the RFCs only talk about it in the context of OCSP
stapling. Can SCTs also be provided in non stapled OCSP responses to TLS clients?

Also, should 6962-bis also reference rfc6961 (multiple OCSP responses extension) in addition to rfc 6066?

Or should the language be generalized to just talk about SCTs in OCSP responses, no matter how those
responses are provided to the TLS client?

Thanks 

-- Fabrice
Fabrice Gautier | 28 Aug 18:13 2014
Picon

Clarification regarding SCTs and intermediates.

Hi all,

Per my reading of rfc 6962, it seems that SCT (in that RFC) are only
produced for Leaf certificates. 6962-bis introduce a possibility that
intermediates certs are also logged and SCT produced for them.
(Section 3.2.3. Using a Name-Constrained Intermediate CA)

This raised a couple questions:

- How are SCTs for intermediates provided to TLS clients ? Can they be
provided through the TLS extension? Through the OCSP response?
Embedded in the leaf cert ? Or only embedded in the intermediate cert
?

- If intermediates SCTs can be provided by the same channel as SCTs
for leaf certs, how is the TLS client supposed to know which cert
correspond to a given SCT? Should the TLS client just try all the
certs in the chain until the signature match ? - afaict, there is no
data in the SCT that bind it to the cert, beside the signature.

- If I, a TLS client, have SCTs for both leafs and certs, assuming I
figure out which one is for which, what kind of policies are we
expecting the TLS client to apply. I realize this is probably out of
scope for the RFC, but I'm curious what the expectation are here.

In both 6962, and 6962-bis, the TLS client behavior is very shortly
described in section 5.2. TLS Clients. It basically boils down to one
sentence "they (TLS clients) should validate the SCT by computing the
signature input from the SCT data as well as the certificate and
verifying the signature,"

In 6962-bis, section 3.2.3, there is some language about what kind of
intermediate CA are acceptable to log. It seems that at least some
logs clients should also check that intermediates CA with SCTs do obey
those rules. I'm not sure if it's the role of TLS clients, Auditors,
Monitors or all of them to do so.

Thanks

-- Fabrice
Paul Wouters | 28 Aug 17:16 2014
Picon

end to end email encryption using CT gossip protocol


---------- Forwarded message ----------
Date: Thu, 28 Aug 2014 11:15:38
From: Paul Wouters <paul <at> nohats.ca>
To: Trans <trans-bounces <at> ietf.org>
Subject: end to end email encryption using CT gossip protocol

FYI

https://code.google.com/p/end-to-end/wiki/KeyDistribution

 	For End-To-End, our current approach to key distribution, is to use a
 	model similar to Certificate Transparency, and use the email messages
 	themselves as a gossip protocol, which allow the users themselves to
 	keep the centralized authorities honest. This approach allows users to
 	not have to know about keys, but at the same time, be able to make sure
 	that the servers involved aren't doing anything malicious behind the
 	users' back.

 	To allow the system to be easily distributed (across multiple identity
 	providers), key servers can authenticate the user via existing 
federated
 	identity protocols (with OpenID Connect for example). The model of a 
key
 	server with a transparency backend is based on the premise that a user
 	is willing to trust the security of a centralized service, as long as 
it
 	is subject to public scrutiny, and that can be easily discovered if 
it's
 	compromised (so it is still possible to compromise the user's account,
 	but the user will be able to know that as soon as possible).

 	It's worth noting that End-to-End is still under active development, 
and
 	we might change our approach to key distribution if we find weaknesses
 	in this model, or if we find something else that is as easy to use, and
 	as likely to work. Part of the reason we release this document is to
 	seek early feedback from the community, and adapt as needed.

 	We also want to point out we will do our very best to continue to
 	support existing OpenPGP users who want to manually manage and verify
 	keys and fingerprints manually, as we understand that system has been
 	around for a long time, and has been more battle tested than what we 
are
 	proposing.

Gmane