Max Pritikin (pritikin) <[email protected]> wrote: max> Aside, but can post to the list if you want.
mcr> There are two telemetry status reports that BRSKI added .. "to
mcr> EST". The first is the /.well-known/est/voucher_status. This is a
mcr> report on whether the voucher was acceptable. This is entirely
mcr> RFC8366/BRSKI content, and is completely independant of the certificate
mcr> enrollment protocol. It should change to
/.well-known/brski/voucher_status.
max> An argument that s5.7 voucher_status should be at BRSKI well-known
could be made.
max> I’ve always thought of this as an extension of EST but the language
max> has changed. See 2nd to last paragraph of s1 and all of section 5.9
max> as discussions of the integration. In particular though s5 states:
doc> BRSKI is described as extensions to EST
doc> [RFC7030]. The
doc> goal of these extensions is to reduce the number of TLS connections
doc> and crypto operations required on the pledge. The registrar
doc> implements the BRSKI REST interface within the same "/.well-known"
doc> URI tree as the existing EST URIs as described in EST
doc> [RFC7030]
doc> section 3.2.2. The communication channel between the pledge and the
doc> registrar is referred to as "BRSKI-EST" (see Figure
doc> 1).
max> So are you proposing to shift a bunch over?
The question is about the enrollment_status only.
mcr> It seems that moving it to /brski is acceptable, but it might be that
mcr> it should remain in /est. I am not steeped in the art of CMP or SCEP
or ???,
mcr> so I don't know if what we've done for EST will translate well.
max> This feels more like a perspective and pedant discussion. If folks
max> are particularly pedantic or feel that BRSKI is distinct from EST
max> then put them in distinct well-known locations. Or if folks agree
max> they’re closely linked and might be implemented using the same
max> server’s then put them at the same location.
I want to point out that implementing any of the things on very much separate
servers is very problematic. The authorization for the enrollment operation
(whether EST or anything) is essentially dependant on the successful voucher
operation. When the Registrar sends a successful voucher to the pledge, it
essentially has to bless that TLS connection.
max> I think its that implementation question that might matter the most?
max> But since there is a focus on re-using the TLS connection it would
max> feel weird to me to have distinct processes; which means closely
max> integrated implementation which means this isn’t an implementation
max> problem. Methinks.
Eliot has mentioned questions about Flask, or Rails, or other frameworks
ability to deal with different URL paths. Maybe there are some where it's an
issue, in which case, I'd say that they are probably broken in more profound
ways. I have not encountered a framework where it matters.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] [email protected] http://www.sandelman.ca/ | ruby on rails [
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
