Subject: [Acme] Adam Roach's Yes on draft-ietf-acme-star-09: (with COMMENT)

From: Adam Roach via Datatracker <[email-masked]>
Date: Tue, 01 Oct 2019 18:22:52 -0700

Adam Roach has entered the following ballot position for
draft-ietf-acme-star-09: Yes

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.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-acme-star/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for the work that everyone put into this document! I have
a small number of very minor editorial nits.

[Sorry for the earlier DISCUSS; I had mixed up the cert issuance
model in my head again].

§3.3:

>  The Server SHOULD include the "Cert-Not-Before" and "Cert-Not-After"
>  HTTP headers in the response.

Nit: "...HTTP header fields..."

>  Following are further clarifications regarding usage of these
>  headers, as per [RFC7231] Sec. 8.3.1.  All apply to both headers.

Nit: "...header fields..."

>
>  o  This header is a single value, not a list.

Nit: "...header field..."

>  o  The header is used only in responses to GET, HEAD and POST-as-GET

Nit: "...header field..."

>     requests, and only for MIME types that denote public key
>     certificates.
>  o  Header semantics are independent of context.

Nit: "Header field..."

>  o  The header is not hop-by-hop.

Nit: "...header field..."

>  o  Intermediaries MAY insert or delete the value, but MUST ensure
>     that if present, the header value equals the corresponding value

Nit: "...header field..."

>     within the credential.
>  o  The header is not appropriate for a Vary field.

Nit: "...header field..."

>  o  The header is allowed within message trailers.

Nit: "...header field..."

>  o  The header is not appropriate within redirects.

Nit: "...header field..."

>  o  The header does not introduce additional security considerations.

Nit: "...header field..."

>     It discloses in a simpler form information that is already
>     available inside the credential.

---------------------------------------------------------------------------

§3.3:

>  o  Intermediaries MAY insert or delete the value, but MUST ensure
>     that if present, the header value equals the corresponding value
>     within the credential.

This probably isn't what you want to say. Read literally, this imposes
a requirements on intermediaries who are neither removing nor adding
these header fields to validate that they match the value in the certs.
That's clearly an unrealistic expectation. I suspect the intention here
is that any entity who inserts a value must ensure that the newly inserted
value matches the corresponding value in the certificate.

---

From: Thomas Fossati <[email-masked]>
Date: Wed, 2 Oct 2019 05:32:04 +0000

Hi Adam,

Thank you very much for your review.

On 02/10/2019, 02:22, "Adam Roach via Datatracker" <[email-masked]> wrote:
> >     that if present, the header value equals the corresponding
> >     value within the credential.
>
> these header fields to validate that they match the value in the
> certs.  That's clearly an unrealistic expectation. I suspect the
> intention here is that any entity who inserts a value must ensure that
> the newly inserted value matches the corresponding value in the
> certificate.

Indeed, good catch.

This and the rest of your comments have been incorporated in [1].

BTW, IESG feedback is being cumulatively processed here [2].

Cheers, thanks!

[1] https://github.com/yaronf/I-D/commit/1c8682a8e22db63dca199dc62979f516f11b975e
[2] https://github.com/yaronf/I-D/compare/acme-star-iesg-processing?expand=1

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.