[email protected] <[email protected]> wrote: > Hello, Thank you for the review.
> If DHCP is used for bootstrapping, it should provide enough information
> to fulfill the expectations required in this draft.
Well, yes/no.
Imagine your company ships you a SIP phone for your work-from-home office.
It gets shipped directly from a warehouse, and never visits HQ... because
pandemic or just logistics.
So the DHCP server at your *home* has no ability to provision the right
things... it perhaps *could*, but you have no idea how to actually configure
that.
If this use case is not clear from the introduction, can you say so?
> Minor Issues:
> The Pledge does not know who its owner will be when
> manufactured. Instead, in BRSKI it is assumed that the network to which
> the Pledge connects belongs to the owner of the Pledge and therefore
> network-supported discovery mechanisms can resolve generic, non-owner
> specific names to the owners Registrar.
> Is this a new attack surface? Does this need to be mentioned in the
> security considerations section?
well, if it's a strongly coupled supply chain, where the cloud-registrar know
which customer has bought which device, then no voucher would be issued to an
invalid registrar.
In half-strong coupled supply chain, it might not be known which device which
to which customer, but as long as it went to *a* valid customer, it would be
okay. Generally, brski-cloud only works for strongly coupled supply chains;
a reason for multiple 307 redirects is because the manufacturer might only
know which VAR the device was sent to, while the chain of VARs would know
where they shipped the device.
> == In BRSKI, the Pledge performs enrolment ... enrollment
British vs American spelling, opposite of the normal rule... Owen fixed it.
> == ... it can return a voucher that pins the actual Owner Registrar.
> I'm not certain about the use of "pins" here (?) ... maybe "describes"
> or "redirects to" or something similar? "Pins" doesn't seem to be used
> in a lot of other places in the document.
well, it's widely used in PKIs to speak about how a certificate or public key
is kept the same. It's not in RFC4949 though, which I find weird.
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =- *I*LIKE*TRAINS*
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list -- [email protected] To unsubscribe send an email to [email protected]
