A clarification question from an implementor (me) in the context of
constrained BRSKI state machine.
The /att and /crts requests do not do anything to change the state
of client or server. It would seem that it might be safe to permit
clients which have not yet authenticated to do this
Panos Kampanakis (pkampana) wrote:
> I thought about this for the EST-coaps draft. EST allowed for
> unauthenticated /cacerts and /csrattrs (/crt and /att in EST-coaps) as you
> are suggesting.
Exactly.
> It is not as simple in EST-coaps. Two reasons:
> 1) There are constrained networks where
Jim Schaad wrote:
> Clarification requested - exactly what element is the Registrar?
It's an EST RFC7030 term, but essentially it's the server that connects to
(or is) the CA.
> The one item that I can generally think of that might be a problem is that
> the answers to /att and /crts may
On Dec 11, 2018, at 3:16 PM, Michael Richardson
mailto:mcr+i...@sandelman.ca>> wrote:
Jim Schaad mailto:i...@augustcellars.com>> wrote:
Clarification requested - exactly what element is the Registrar?
It's an EST RFC7030 term, but essentially it's the server that connects to
(or is) the CA.
Clarification requested - exactly what element is the Registrar?
The one item that I can generally think of that might be a problem is that
the answers to /att and /crts may differ based on the entity that is asking
the question. In this case not having the entity being validated means that
the
Hi Michael,
I thought about this for the EST-coaps draft. EST allowed for unauthenticated
/cacerts and /csrattrs (/crt and /att in EST-coaps) as you are suggesting. It
is not as simple in EST-coaps. Two reasons:
1) There are constrained networks where an easy amplification attack could take
Gotcha, so you are describing a provisional DTLS connection at the server.
Just to give a bit more color, in a usecase we are working on right now the
mesh network link rate <100Kbps. That network gets oversubscribed with legit
cacert responses. I can only imagine how worse it would be if bad
Hi,
I looked through the document again. Many issues have been fixed, but I
still have some comments:
I still think that Section 5.8.1, in particular 5.8.1.1 should point out
that RS must check the integrity of the token und validate that it stems
from an authorized AS. Checking the iss field
