Hi Tommy! Thanks for the quick response. What you are proposing below would address my concern. See below ...
> -----Original Message----- > From: iesg <[email protected]> On Behalf Of Tommy Pauly > Sent: Wednesday, January 22, 2020 1:04 PM > To: Roman Danyliw <[email protected]> > Cc: Erik Kline <[email protected]>; draft-ietf-intarea-provisioning- > [email protected]; [email protected]; The IESG <[email protected]>; intarea- > [email protected] > Subject: Re: Roman Danyliw's Discuss on draft-ietf-intarea-provisioning- > domains-10: (with DISCUSS and COMMENT) > > Hi Roman, > > Thanks for the review! > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > Section 4.4. Per “When a host retrieves the PvD Additional > > Information, it MUST verify that the TLS server certificate is valid > > for the performed request (e.g., that the Subject Alternative Name is > > equal to the PvD ID expressed as an FQDN). This authentication > > creates a secure binding between the information provided by the > > trusted Router Advertisement, and the HTTPS server.”, what is the > > trust anchor the client is supposed to use to valid the server certificate > > is > valid? How is that trust anchor provisioned? > > There isn't any assumption that a non-default trust anchor needs to be used > by the client for this validation. By default, a client would use its system > TLS > trust anchors to validate the server. This leaves open the possibility for > enterprise scenarios to configure custom trust anchor settings, but that is > currently beyond the scope of this document. > > Is there anything you'd like to see specifically covered in this text? Including a version of the text you wrote above would address my concern. The two key issues you hit are that (1) (obviously) a trust anchor should be used otherwise you not getting the authenticity you think you are; and (2) this anchor might need to be provisioned, whose complexity is out of scope (like you said). > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > I support Ben Kaduk and Adam Roach’s DISCUSS positions. > > > > Section 4.1. Per “If the HTTP status of the answer is between 200 and > > 299, inclusive, the host MAY get a file containing a single JSON > > object”, what should be the behavior of a host that gets 200 status > > code but no JSON object – should it try again, conclude (like in a > > 4xx status code) that there is not further information, etc.? > > > > > > Yes, I agree that this should be clarified—that will be covered as part of the > discuss from Adam. Makes sense. Thanks, Roman > Thanks, > Tommy _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
