Re: Working Group Last Call for draft-ietf-httpbis-expect-ct-05

Made the following changes:
- Made explicit that the expiration date is relative to when the UA
received the header, not when the response was generated, consistent with
HSTS/HPKP (
https://github.com/httpwg/http-extensions/commit/299eb574ed7a03dfbae1646dfab4553266037541
)
- Clarified that correctness checks can prevent CT compliance from being
checked and vice versa, with an example (
https://github.com/httpwg/http-extensions/commit/2b384788bcfd4b203081f220c17a6a87781d3b5b
)
- Added media types IANA considerations section (
https://github.com/httpwg/http-extensions/commit/bcd334e124e530215b860078889e9bcbc71fcb7e)
and will send mail to media-types@iana.org

I'm not quite sure what to do about IP certificates. I value consistency
with HSTS/HPKP and I'm not sure it makes sense to allow IP certificates for
Expect-CT for hypothetical use cases at the cost of diverging from
HSTS/HPKP.

On Wed, Jun 6, 2018 at 4:47 AM Ryan Sleevi <ryan-ietf@sleevi.com> wrote:

>
>
> On Tue, Jun 5, 2018 at 5:55 AM, Martin Thomson <martin.thomson@gmail.com>
> wrote:
>
>> On Mon, Jun 4, 2018 at 10:56 PM Emily Stark <estark@google.com> wrote:
>> > Might have been blindly cribbed from HSTS/HPKP -- I don't remember
>> discussing it specifically for Expect-CT. Filed
>> https://github.com/httpwg/http-extensions/issues/637
>>
>> Thanks.
>>
>> >> CAs can (and do) issue IP certificates, so why does this specifically
>> >> exclude those?  If this is a requirement imposed by CT, then please
>> >> cite that.  Otherwise, I think that this should allow IP literals.
>> >
>> >
>> > This was also cribbed from HSTS/HPKP. I'll try to find out the
>> motivation for including it in those specs; I'm a little wary of dropping
>> it from Expect-CT without understanding why it's there for the other two...
>>
>> There was some confusion about the status of IP certificates at some
>> points in the past.  I don't think that it is necessary to concern
>> this spec with the types of identifier that need to be covered.
>>
>
> Right, that's listed in https://tools.ietf.org/html/rfc6797#appendix-A
> for HSTS, and as HPKP originally started as an option of HSTS, it retained
> that functionality. The difficulty in both interoperability (in clients)
> and obtaining an IP certificate (by servers)
>
>