Eric Rescorla's Discuss on draft-ietf-httpbis-expect-ct-07: (with DISCUSS and COMMENT)

[Eric Rescorla]

Following up, I don't see any response to these comments.

-Ekr

I have one other non-blocking comment: Why is this document Experimental?
People are already deploying CT without this. It seems like PS would make
more sense or Informational.
Alexey, I leave it to you.
-Ekr

Eric Rescorla has entered the following ballot position for
draft-ietf-httpbis-expect-ct-07: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.
https://datatracker.ietf.org/doc/draft-ietf-httpbis-expect-ct/
----------------------------------------------------------------------
----------------------------------------------------------------------
https://mozphab-ietf.devsvcdev.mozaws.net/D4579
This generally seems like a sound mechanism, but I believe there are
some points here that are sufficiently unclear they might create
interop problems,s o I am balloting DISCUSS.
Most importantly, this document just says you support CT, but that
creates a potential interop problem if say 6962-tris had a different
way of delivering CT information or a different syntax. I'm not saying
you need a version here, but you need to indicate that it's not
forward-looking.
Also, see below.
DETAIL
S 2.4.

beginning an HTTP conversation over the TLS channel.
If a connection to a Known Expect-CT Host violates the UA's CT

policy

(i.e., the connection is not CT-qualified), and if the Known

Expect-

CT Host's Expect-CT metadata indicates an "enforce" configuration,
the UA MUST treat the CT compliance failure as an error.

Is this supposed to be a hard failure, as with HSTS. If not, how does
it interact with HSTS's hard failure reqs.
S 3.1.

(This may differ from the value of the

"served-certificate-chain"

key.) The value is provided as an array of strings, which MUST
appear in the order matching the chain that the UA validated;

each

string in the array is the Privacy-Enhanced Mail (PEM)
representation of each X.509 certificate as described in
[RFC7468].

What happens if you try to construct multiple paths?
S 3.1.

does not have or does not trust the public key of the log

from

which the SCT was issued), "valid" (indicating that the UA
successfully validated the SCT as described in Section 5.2 of
[RFC6962] or Section 8.2.3 of [I-D.ietf-trans-rfc6962-bis]),

or

"invalid" (indicating that the SCT validation failed because
of, e.g., a bad signature).

Is "invalid" anything other than the specific cases listed above?
----------------------------------------------------------------------
----------------------------------------------------------------------

allows web host operators to instruct user agents to expect valid
Signed Certificate Timestamps (SCTs) to be served on connections to
these hosts. Expect-CT allows web host operators to discover
misconfigurations in their Certificate Transparency deployments and
ensure that misissued certificates accepted by UAs are discoverable
in Certificate Transparency logs.

I don't believe that it does this. Consider a client which simply did
not support CT, then it would (a) accept a misissued certificate that
(b) was not discoverable
S 2.1.1.

Figure 2: Syntax of the report-uri directive value
"absolute-URI" is defined in Section 4.3 of [RFC3986].
Hosts may set "report-uri"s that use HTTP or HTTPS. If the scheme

in
Why are you allowing HTTP?
S 2.3.2.

the "enforce", "max-age", or "report-uri" header field value
directives convey information different from that already
maintained by the UA. If the "max-age" directive has a value of
0, the UA MUST remove its cached Expect-CT information if the

host

was previously noted as a Known Expect-CT Host, and MUST NOT

note

this host as a Known Expect-CT Host if it is not already noted.

As noted above, I think you need to clear the cache when you upgrade
to a potentially incompatible CT version, or otherwise reconfigure the
client.
S 2.3.2.1.

this host as a Known Expect-CT Host if it is not already noted.
2.3.2.1. Noting Expect-CT
Upon receipt of the Expect-CT response header field over an error-
free TLS connection (including the validation adding in Section

2.4),
s/adding/added/?
S 2.3.2.1.

host's domain name and its associated Expect-CT directives in non-
volatile storage.
To note a host as a Known Expect-CT Host, the UA MUST set its

Expect-

CT metadata given in the most recently received valid Expect-CT
header field, as specified in Section 2.3.2.2.

This seems ungrammatical. Set it where?
S 2.3.2.2.

2.3.2.2. Storage Model
If the substring matching the host production from the Request-URI
(of the message to which the host responded) does not congruently
match an existing Known Expect-CT Host's domain name, per the

I would say "exactly match" rather than "congruently match" unless
this ia term of art somewhere.
S 2.3.2.2.

understands them, the UA MAY note them as well.
UAs MAY set an upper limit on the value of max-age, so that UAs

that

have noted erroneous Expect-CT hosts (whether by accident or due to
attack) have some chance of recovering over time. If the server

sets

a max-age greater than the UA's upper limit, the UA MAY behave as

if
This MAY seems out of place, given that you already said MAY.
S 2.4.

When a UA connects to a Known Expect-CT Host using a TLS

connection,

if the TLS connection has no errors, then the UA will apply an
additional correctness check: compliance with a CT Policy. A UA
should evaluate compliance with its CT Policy whenever connecting

to

a Known Expect-CT Host, as soon as possible. However, the check

can
What does "as soon as possible" mean?
S 2.4.

terminates the connection due to an Expect-CT failure, this could
cause the UA to skip subsequent correctness checks. When the CT
compliance check is skipped or bypassed, Expect-CT reports
(Section 3) will not be sent.
When CT compliance is evaluted for a Known Expect-CT Host, the UA

Nit: evaluated
S 2.4.1.

"report-uri" (Section 3).
2.4.1. Skipping CT compliance checks
It is acceptable for a UA to skip CT compliance checks for some

hosts

according to local policy. For example, a UA may disable CT

Should this be MAY?
S 3.1.

o "scts": the value represents the SCTs (if any) that the UA
received for the Expect-CT host and their validation statuses.
The value is provided as an array of JSON objects. The SCTs may
appear in any order. Each JSON object in the array has the

So these just apply to the EE cert? What about CT for the non-EE
certs?
S 3.1.

of, e.g., a bad signature).
* The "source" key, with a string value that indicates from

where

the UA obtained the SCT, as defined in Section 3 of [RFC6962]
and Section 6 of [I-D.ietf-trans-rfc6962-bis]. The UA MUST

set

the value to one of "tls-extension", "ocsp", or "embedded".

What do these mean? They seem obvious, but you don't say.

[Emily Stark]

Sorry for the delay. I'm on maternity leave but hope to have these
addressed in the next couple weeks.

Post by Eric Rescorla
Following up, I don't see any response to these comments.
-Ekr

I have one other non-blocking comment: Why is this document Experimental?
People are already deploying CT without this. It seems like PS would make
more sense or Informational.
Alexey, I leave it to you.
-Ekr

Eric Rescorla has entered the following ballot position for
draft-ietf-httpbis-expect-ct-07: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to
https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.
https://datatracker.ietf.org/doc/draft-ietf-httpbis-expect-ct/
----------------------------------------------------------------------
----------------------------------------------------------------------
https://mozphab-ietf.devsvcdev.mozaws.net/D4579
This generally seems like a sound mechanism, but I believe there are
some points here that are sufficiently unclear they might create
interop problems,s o I am balloting DISCUSS.
Most importantly, this document just says you support CT, but that
creates a potential interop problem if say 6962-tris had a different
way of delivering CT information or a different syntax. I'm not saying
you need a version here, but you need to indicate that it's not
forward-looking.
Also, see below.
DETAIL
S 2.4.

beginning an HTTP conversation over the TLS channel.
If a connection to a Known Expect-CT Host violates the UA's CT

policy

(i.e., the connection is not CT-qualified), and if the Known

Expect-

CT Host's Expect-CT metadata indicates an "enforce" configuration,
the UA MUST treat the CT compliance failure as an error.

Is this supposed to be a hard failure, as with HSTS. If not, how does
it interact with HSTS's hard failure reqs.
S 3.1.

(This may differ from the value of the

"served-certificate-chain"

key.) The value is provided as an array of strings, which MUST
appear in the order matching the chain that the UA validated;

each

string in the array is the Privacy-Enhanced Mail (PEM)
representation of each X.509 certificate as described in
[RFC7468].

What happens if you try to construct multiple paths?
S 3.1.

does not have or does not trust the public key of the log

from

which the SCT was issued), "valid" (indicating that the UA
successfully validated the SCT as described in Section 5.2

of

[RFC6962] or Section 8.2.3 of

[I-D.ietf-trans-rfc6962-bis]), or

"invalid" (indicating that the SCT validation failed because
of, e.g., a bad signature).

Is "invalid" anything other than the specific cases listed above?
----------------------------------------------------------------------
----------------------------------------------------------------------

allows web host operators to instruct user agents to expect valid
Signed Certificate Timestamps (SCTs) to be served on connections

to

these hosts. Expect-CT allows web host operators to discover
misconfigurations in their Certificate Transparency deployments

and

ensure that misissued certificates accepted by UAs are

discoverable

in Certificate Transparency logs.

I don't believe that it does this. Consider a client which simply did
not support CT, then it would (a) accept a misissued certificate that
(b) was not discoverable
S 2.1.1.

Figure 2: Syntax of the report-uri directive value
"absolute-URI" is defined in Section 4.3 of [RFC3986].
Hosts may set "report-uri"s that use HTTP or HTTPS. If the

scheme in
Why are you allowing HTTP?
S 2.3.2.

the "enforce", "max-age", or "report-uri" header field value
directives convey information different from that already
maintained by the UA. If the "max-age" directive has a value

of

0, the UA MUST remove its cached Expect-CT information if the

host

was previously noted as a Known Expect-CT Host, and MUST NOT

note

this host as a Known Expect-CT Host if it is not already noted.

As noted above, I think you need to clear the cache when you upgrade
to a potentially incompatible CT version, or otherwise reconfigure the
client.
S 2.3.2.1.

this host as a Known Expect-CT Host if it is not already noted.
2.3.2.1. Noting Expect-CT
Upon receipt of the Expect-CT response header field over an error-
free TLS connection (including the validation adding in Section

2.4),
s/adding/added/?
S 2.3.2.1.

host's domain name and its associated Expect-CT directives in non-
volatile storage.
To note a host as a Known Expect-CT Host, the UA MUST set its

Expect-

CT metadata given in the most recently received valid Expect-CT
header field, as specified in Section 2.3.2.2.

This seems ungrammatical. Set it where?
S 2.3.2.2.

2.3.2.2. Storage Model
If the substring matching the host production from the Request-URI
(of the message to which the host responded) does not congruently
match an existing Known Expect-CT Host's domain name, per the

I would say "exactly match" rather than "congruently match" unless
this ia term of art somewhere.
S 2.3.2.2.

understands them, the UA MAY note them as well.
UAs MAY set an upper limit on the value of max-age, so that UAs

that

have noted erroneous Expect-CT hosts (whether by accident or due

to

attack) have some chance of recovering over time. If the server

sets

a max-age greater than the UA's upper limit, the UA MAY behave as

if
This MAY seems out of place, given that you already said MAY.
S 2.4.

When a UA connects to a Known Expect-CT Host using a TLS

connection,

if the TLS connection has no errors, then the UA will apply an
additional correctness check: compliance with a CT Policy. A UA
should evaluate compliance with its CT Policy whenever connecting

to

a Known Expect-CT Host, as soon as possible. However, the check

can
What does "as soon as possible" mean?
S 2.4.

terminates the connection due to an Expect-CT failure, this could
cause the UA to skip subsequent correctness checks. When the CT
compliance check is skipped or bypassed, Expect-CT reports
(Section 3) will not be sent.
When CT compliance is evaluted for a Known Expect-CT Host, the UA

Nit: evaluated
S 2.4.1.

"report-uri" (Section 3).
2.4.1. Skipping CT compliance checks
It is acceptable for a UA to skip CT compliance checks for some

hosts

according to local policy. For example, a UA may disable CT

Should this be MAY?
S 3.1.

o "scts": the value represents the SCTs (if any) that the UA
received for the Expect-CT host and their validation statuses.
The value is provided as an array of JSON objects. The SCTs

may

appear in any order. Each JSON object in the array has the

So these just apply to the EE cert? What about CT for the non-EE
certs?
S 3.1.

of, e.g., a bad signature).
* The "source" key, with a string value that indicates from

where

the UA obtained the SCT, as defined in Section 3 of

[RFC6962]

and Section 6 of [I-D.ietf-trans-rfc6962-bis]. The UA MUST

set

the value to one of "tls-extension", "ocsp", or "embedded".

What do these mean? They seem obvious, but you don't say.

[Eric Rescorla]

No problem. Just wanted to make sure I wasn't the hold-up.

-Ekr

Post by Emily Stark
Sorry for the delay. I'm on maternity leave but hope to have these
addressed in the next couple weeks.

Post by Eric Rescorla
Following up, I don't see any response to these comments.
-Ekr

I have one other non-blocking comment: Why is this document
Experimental? People are already deploying CT without this. It seems like
PS would make more sense or Informational.
Alexey, I leave it to you.
-Ekr

Eric Rescorla has entered the following ballot position for
draft-ietf-httpbis-expect-ct-07: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to
https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.
https://datatracker.ietf.org/doc/draft-ietf-httpbis-expect-ct/
----------------------------------------------------------------------
----------------------------------------------------------------------
https://mozphab-ietf.devsvcdev.mozaws.net/D4579
This generally seems like a sound mechanism, but I believe there are
some points here that are sufficiently unclear they might create
interop problems,s o I am balloting DISCUSS.
Most importantly, this document just says you support CT, but that
creates a potential interop problem if say 6962-tris had a different
way of delivering CT information or a different syntax. I'm not saying
you need a version here, but you need to indicate that it's not
forward-looking.
Also, see below.
DETAIL
S 2.4.

beginning an HTTP conversation over the TLS channel.
If a connection to a Known Expect-CT Host violates the UA's CT

policy

(i.e., the connection is not CT-qualified), and if the Known

Expect-

CT Host's Expect-CT metadata indicates an "enforce"

configuration,

the UA MUST treat the CT compliance failure as an error.

Is this supposed to be a hard failure, as with HSTS. If not, how does
it interact with HSTS's hard failure reqs.
S 3.1.

(This may differ from the value of the

"served-certificate-chain"

key.) The value is provided as an array of strings, which

MUST

appear in the order matching the chain that the UA validated;

each

string in the array is the Privacy-Enhanced Mail (PEM)
representation of each X.509 certificate as described in
[RFC7468].

What happens if you try to construct multiple paths?
S 3.1.

does not have or does not trust the public key of the log

from

which the SCT was issued), "valid" (indicating that the UA
successfully validated the SCT as described in Section 5.2

of

[RFC6962] or Section 8.2.3 of

[I-D.ietf-trans-rfc6962-bis]), or

"invalid" (indicating that the SCT validation failed

because

of, e.g., a bad signature).

Is "invalid" anything other than the specific cases listed above?
----------------------------------------------------------------------
----------------------------------------------------------------------

allows web host operators to instruct user agents to expect valid
Signed Certificate Timestamps (SCTs) to be served on connections

to

these hosts. Expect-CT allows web host operators to discover
misconfigurations in their Certificate Transparency deployments

and

ensure that misissued certificates accepted by UAs are

discoverable

in Certificate Transparency logs.

I don't believe that it does this. Consider a client which simply did
not support CT, then it would (a) accept a misissued certificate that
(b) was not discoverable
S 2.1.1.

Figure 2: Syntax of the report-uri directive value
"absolute-URI" is defined in Section 4.3 of [RFC3986].
Hosts may set "report-uri"s that use HTTP or HTTPS. If the

scheme in
Why are you allowing HTTP?
S 2.3.2.

the "enforce", "max-age", or "report-uri" header field value
directives convey information different from that already
maintained by the UA. If the "max-age" directive has a value

of

0, the UA MUST remove its cached Expect-CT information if the

host

was previously noted as a Known Expect-CT Host, and MUST NOT

note

this host as a Known Expect-CT Host if it is not already

noted.
As noted above, I think you need to clear the cache when you upgrade
to a potentially incompatible CT version, or otherwise reconfigure the
client.
S 2.3.2.1.

this host as a Known Expect-CT Host if it is not already

noted.

2.3.2.1. Noting Expect-CT
Upon receipt of the Expect-CT response header field over an

error-

free TLS connection (including the validation adding in Section

2.4),
s/adding/added/?
S 2.3.2.1.

host's domain name and its associated Expect-CT directives in

non-

volatile storage.
To note a host as a Known Expect-CT Host, the UA MUST set its

Expect-

CT metadata given in the most recently received valid Expect-CT
header field, as specified in Section 2.3.2.2.

This seems ungrammatical. Set it where?
S 2.3.2.2.

2.3.2.2. Storage Model
If the substring matching the host production from the

Request-URI

(of the message to which the host responded) does not congruently
match an existing Known Expect-CT Host's domain name, per the

I would say "exactly match" rather than "congruently match" unless
this ia term of art somewhere.
S 2.3.2.2.

understands them, the UA MAY note them as well.
UAs MAY set an upper limit on the value of max-age, so that UAs

that

have noted erroneous Expect-CT hosts (whether by accident or due

to

attack) have some chance of recovering over time. If the server

sets

a max-age greater than the UA's upper limit, the UA MAY behave

as if
This MAY seems out of place, given that you already said MAY.
S 2.4.

When a UA connects to a Known Expect-CT Host using a TLS

connection,

if the TLS connection has no errors, then the UA will apply an
additional correctness check: compliance with a CT Policy. A UA
should evaluate compliance with its CT Policy whenever

connecting to

a Known Expect-CT Host, as soon as possible. However, the check

can
What does "as soon as possible" mean?
S 2.4.

terminates the connection due to an Expect-CT failure, this could
cause the UA to skip subsequent correctness checks. When the CT
compliance check is skipped or bypassed, Expect-CT reports
(Section 3) will not be sent.
When CT compliance is evaluted for a Known Expect-CT Host, the UA

Nit: evaluated
S 2.4.1.

"report-uri" (Section 3).
2.4.1. Skipping CT compliance checks
It is acceptable for a UA to skip CT compliance checks for some

hosts

according to local policy. For example, a UA may disable CT

Should this be MAY?
S 3.1.

o "scts": the value represents the SCTs (if any) that the UA
received for the Expect-CT host and their validation statuses.
The value is provided as an array of JSON objects. The SCTs

may

appear in any order. Each JSON object in the array has the

So these just apply to the EE cert? What about CT for the non-EE
certs?
S 3.1.

of, e.g., a bad signature).
* The "source" key, with a string value that indicates from

where

the UA obtained the SCT, as defined in Section 3 of

[RFC6962]

and Section 6 of [I-D.ietf-trans-rfc6962-bis]. The UA

MUST set

the value to one of "tls-extension", "ocsp", or "embedded".

What do these mean? They seem obvious, but you don't say.

[Emily Stark]

Hi again,

Thanks for your patience. I've addressed these comments in
https://github.com/httpwg/http-extensions/commit/58a16cdcc535bde6bd7532b021d9473e6eb5b112.
I added a note in the introduction and in 2.3.2 that this version of
Expect-CT is only compatible with RFC 6962 and 6962-bis and not any future
versions of CT. Also see a couple replies inline.

Emily

Post by Eric Rescorla
No problem. Just wanted to make sure I wasn't the hold-up.
-Ekr

Post by Emily Stark
Sorry for the delay. I'm on maternity leave but hope to have these
addressed in the next couple weeks.

Post by Eric Rescorla
Following up, I don't see any response to these comments.
-Ekr

I have one other non-blocking comment: Why is this document
Experimental? People are already deploying CT without this. It seems like
PS would make more sense or Informational.
Alexey, I leave it to you.
-Ekr

Eric Rescorla has entered the following ballot position for
draft-ietf-httpbis-expect-ct-07: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to
https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.
https://datatracker.ietf.org/doc/draft-ietf-httpbis-expect-ct/
----------------------------------------------------------------------
----------------------------------------------------------------------
https://mozphab-ietf.devsvcdev.mozaws.net/D4579
This generally seems like a sound mechanism, but I believe there are
some points here that are sufficiently unclear they might create
interop problems,s o I am balloting DISCUSS.
Most importantly, this document just says you support CT, but that
creates a potential interop problem if say 6962-tris had a different
way of delivering CT information or a different syntax. I'm not saying
you need a version here, but you need to indicate that it's not
forward-looking.
Also, see below.
DETAIL
S 2.4.

beginning an HTTP conversation over the TLS channel.
If a connection to a Known Expect-CT Host violates the UA's CT

policy

(i.e., the connection is not CT-qualified), and if the Known

Expect-

CT Host's Expect-CT metadata indicates an "enforce"

configuration,

the UA MUST treat the CT compliance failure as an error.

Is this supposed to be a hard failure, as with HSTS. If not, how does
it interact with HSTS's hard failure reqs.
S 3.1.

(This may differ from the value of the

"served-certificate-chain"

key.) The value is provided as an array of strings, which

MUST

appear in the order matching the chain that the UA

validated; each

string in the array is the Privacy-Enhanced Mail (PEM)
representation of each X.509 certificate as described in
[RFC7468].

What happens if you try to construct multiple paths?
S 3.1.

does not have or does not trust the public key of the log

from

which the SCT was issued), "valid" (indicating that the UA
successfully validated the SCT as described in Section

5.2 of

[RFC6962] or Section 8.2.3 of

[I-D.ietf-trans-rfc6962-bis]), or

"invalid" (indicating that the SCT validation failed

because

of, e.g., a bad signature).

Is "invalid" anything other than the specific cases listed above?
----------------------------------------------------------------------
----------------------------------------------------------------------

allows web host operators to instruct user agents to expect

valid

Signed Certificate Timestamps (SCTs) to be served on

connections to

these hosts. Expect-CT allows web host operators to discover
misconfigurations in their Certificate Transparency deployments

and

ensure that misissued certificates accepted by UAs are

discoverable

in Certificate Transparency logs.

I don't believe that it does this. Consider a client which simply did
not support CT, then it would (a) accept a misissued certificate that
(b) was not discoverable
S 2.1.1.

Figure 2: Syntax of the report-uri directive value
"absolute-URI" is defined in Section 4.3 of [RFC3986].
Hosts may set "report-uri"s that use HTTP or HTTPS. If the

scheme in
Why are you allowing HTTP?

This had been brought up in a previous review and is now limited to HTTPS.

Post by Eric Rescorla

Post by Emily Stark

Post by Eric Rescorla

S 2.3.2.

the "enforce", "max-age", or "report-uri" header field value
directives convey information different from that already
maintained by the UA. If the "max-age" directive has a

value of

0, the UA MUST remove its cached Expect-CT information if

the host

was previously noted as a Known Expect-CT Host, and MUST NOT

note

this host as a Known Expect-CT Host if it is not already

noted.
As noted above, I think you need to clear the cache when you upgrade
to a potentially incompatible CT version, or otherwise reconfigure the
client.
S 2.3.2.1.

this host as a Known Expect-CT Host if it is not already

noted.

2.3.2.1. Noting Expect-CT
Upon receipt of the Expect-CT response header field over an

error-

free TLS connection (including the validation adding in Section

2.4),
s/adding/added/?
S 2.3.2.1.

host's domain name and its associated Expect-CT directives in

non-

volatile storage.
To note a host as a Known Expect-CT Host, the UA MUST set its

Expect-

CT metadata given in the most recently received valid Expect-CT
header field, as specified in Section 2.3.2.2.

This seems ungrammatical. Set it where?
S 2.3.2.2.

2.3.2.2. Storage Model
If the substring matching the host production from the

Request-URI

(of the message to which the host responded) does not

congruently

match an existing Known Expect-CT Host's domain name, per the

I would say "exactly match" rather than "congruently match" unless
this ia term of art somewhere.
S 2.3.2.2.

understands them, the UA MAY note them as well.
UAs MAY set an upper limit on the value of max-age, so that UAs

that

have noted erroneous Expect-CT hosts (whether by accident or

due to

attack) have some chance of recovering over time. If the

server sets

a max-age greater than the UA's upper limit, the UA MAY behave

as if
This MAY seems out of place, given that you already said MAY.
S 2.4.

When a UA connects to a Known Expect-CT Host using a TLS

connection,

if the TLS connection has no errors, then the UA will apply an
additional correctness check: compliance with a CT Policy. A UA
should evaluate compliance with its CT Policy whenever

connecting to

a Known Expect-CT Host, as soon as possible. However, the

check can
What does "as soon as possible" mean?
S 2.4.

terminates the connection due to an Expect-CT failure, this

could

cause the UA to skip subsequent correctness checks. When the CT
compliance check is skipped or bypassed, Expect-CT reports
(Section 3) will not be sent.
When CT compliance is evaluted for a Known Expect-CT Host, the

UA
Nit: evaluated
S 2.4.1.

"report-uri" (Section 3).
2.4.1. Skipping CT compliance checks
It is acceptable for a UA to skip CT compliance checks for some

hosts

according to local policy. For example, a UA may disable CT

Should this be MAY?
S 3.1.

o "scts": the value represents the SCTs (if any) that the UA
received for the Expect-CT host and their validation

statuses.

The value is provided as an array of JSON objects. The SCTs

may

appear in any order. Each JSON object in the array has the

So these just apply to the EE cert? What about CT for the non-EE
certs?

AFAIK 6962 and 6962-bis only define ways to deliver SCTs for the EE cert,
so that's all that Expect-CT is concerned with. Theoretically I suppose
future versions of CT and Expect-CT could handle intermediate certs as well.

Post by Eric Rescorla

Post by Emily Stark

Post by Eric Rescorla

S 3.1.

of, e.g., a bad signature).
* The "source" key, with a string value that indicates from

where

the UA obtained the SCT, as defined in Section 3 of

[RFC6962]

and Section 6 of [I-D.ietf-trans-rfc6962-bis]. The UA

MUST set

the value to one of "tls-extension", "ocsp", or

"embedded".
What do these mean? They seem obvious, but you don't say.