Michael Richardson <[email protected]> wrote: > We support two methods of redirect: 307 redirect and voucher based redirect. > The first method allows a Pledge to find a BRSKI capable Registrar at which > it starts the normal voucher-request/voucher process. > The second method allows the Cloud Registrar to process a voucher request > and then redirect the Pledge to an EST-only capable Registration Authority.
> The questions are two:
> 1) do we allow multiple layers of 307 redirect? This can be pretty
powerful
> as it allows a manufacturer to just know which regional distributor they
> resold to, and the distributor knows which VAR, etc.
> If so, I guess we need to establish some limit to how many redirects we
allow.
> BRSKI says some things at section 5.6 about limiting redirects to one.
> My opinion is that this restriction should not apply.
There is a second problem which I just thought about.
Let me past in the sequence diagram:
| |
| 1. Mutual-authenticated TLS |
|<----------------------------------------------->|
| |
| 2. Voucher Request |
|------------------------------------------------>|
| |
| 3. 307 Location: owner-ra.example.com |
|<------------------------------------------------|
| 4. Provisional TLS | |
|<-------------------->| |
The first TLS connection (1) is to a burnt-in destination.
RFC6125 DNS-ID validatio may be done against an Implicit TA database must be
used to validate the server certificate.
After step 3, the Pledge does not know if it should start a Provisional TLS
connection to the intended Registrar (which would not be verified by Implicit
TA), or if it should attempt to validate owner-ra.example.com against it's
Implicit TA.
One possibility is that in the Cloud Registrar case, if the Pledge *can*
validate the given name against the Implicit TA database that it has, then it
should. If it does manage to do that, then it can accept another 307
Redirect. If it can't validate, then it can't accept another 307.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | IoT architect [
] [email protected] http://www.sandelman.ca/ | ruby on rails [
--
Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
