https://tinyurl.com/y2skc9xz
Benjamin Kaduk <[email protected]> wrote: >> We did not resort to a YANG data model for the auditlog responses, so I spent >> a few minutes mystified by your complaint... then: >> We referenced 7951 (YANG->JSON), but we should have just referenced RFC7159 (JSON)! > Oh! That would make a lot more sense... (but 7159 is obsoleted by 8259, > of course) got them all now. >> If so, the reason for normative language is because, we want to say, "if you >> do X, then you MUST do it this way". >> >> Second, we have referenced some pieces of section 7.2 from section 9. >> We think that there are significant security issues by accepting nonceless >> vouchers, which we discuss in 11.1. A variation of the protocol is when >> the manufacturer programs the pledge to ALWAYS accept nonceless vouchers. >> There could otherwise be some more complex (proprietary, or documented later >> on) evaluation of whether to accept a nonceless voucher. For instance, the >> MASA could sign them with a different key, perhaps one stored in an HSM. > Okay, so it is that the client (well, manufacturer?) chooses whether or not > to accept nonceless vouchers. So we could change the introduction to the > enumerated list to be saying that this is a list of exclusive candidate > behaviors that could be chosen independently of each other, and not a > collection of behaviors all of which are expected to be implemented. I have revised section 7.2. My use of normative language seems inconsistent at this point. I need to distinguish between "X is possible" from "when doing X you MUST Y" better. >> > (14) In Section 5.6: >> >> > The server MUST answer with a suitable 4xx >> > or 5xx HTTP [RFC2616] error code when a problem occurs. In this case, >> > the response data from the MASA MUST be a plaintext human- readable >> > (ASCII, English) error message containing explanatory information >> > describing why the request was rejected. >> >> > It seems hard to support this stance on internationalization in 2019. >> >> We don't believe that this response will go anywhere other than logs, >> for software suppliers to evaluate. Localizing these error message causes >> more problems in my experience than benefit. 90% of the information is in >> the 4xx/5xx code. > I should probably defer to my ART-area colleagues here. But you're saying > that mandating English is better than allowing UTF-8 and otherwise leaving > it as implementation defined? We have removed "ASCII, English), and left this as "UTF-8", with the expectation that the message may be localized. Emphasis is on human readable. >> > (15) In Section 5.9.4: >> >> > To indicate successful enrollment the client SHOULD re-negotiate the >> > EST TLS session using the newly obtained credentials. This occurs by >> > the client initiating a new TLS ClientHello message on the existing TLS >> > connection. The client MAY simply close the old TLS session and start >> > a new one. The server MUST support either model. >> >> > Is this supposed to be sending a new TLS ClientHello in the application >> > data channel or as a new handshake message (aka "renegotiation")? The >> > latter is not possible in TLS 1.3 and is generally disrecommended >> > anyways even in TLS 1.2. I would strongly suggest to remove the >> > "renegotiation" option and just leave "close the connection and start a >> > new connection/handshake". >> >> Okay, fixed to say: >> >> <t>To indicate successful enrollment the client SHOULD re-negotiate >> the EST TLS session using the newly obtained credentials. This >> - occurs by the client initiating a new TLS ClientHello message on the >> - existing TLS connection. The client MAY simply close the old TLS >> - session and start a new one. The server MUST support either >> + occurs by the client closing the existing TLS connection, and >> + starting a new one. The server MUST support either >> model.</t> > I'd prefer to s/re-negotiate/re-establish/ as well, but this is probably > good enough to clear the discuss. Changed. -- Michael Richardson <[email protected]>, Sandelman Software Works -= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
