Max Pritikin (pritikin) wrote:
> Jim Schaad wrote:
>
jim> Clarification requested - exactly what element is the Registrar?
mcr> It's an EST RFC7030 term, but essentially it's the server that
mcr> connects to (or is) the CA.
max> The Registrar terminology is from the Anima
Hannes Tschofenig wrote:
> > We want all our clients to be authenticated by DTLS before they start
> > loading up our RF network.
> > I'm not suggesting that the DTLS be skipped, I'm suggesting that the
> > client certificate presented might be meaningless to the EST server.
> I am curious what
Panos Kampanakis (pkampana) wrote:
> Gotcha, so you are describing a provisional DTLS connection at the server.
I'm thinking about a Registrar that might be serving both provisional
connections and ones that are just renewing LDevIDs, and maybe ones that
also serve selected factory installed
> -Original Message-
> From: Ace On Behalf Of Hannes Tschofenig
> Sent: Wednesday, December 12, 2018 8:01 AM
> To: Panos Kampanakis (pkampana) ; Michael
> Richardson ; ace@ietf.org; an...@ietf.org
> Cc: Peter van der Stok ; Max Pritikin (pritikin)
>
> Subject: Re: [Ace] est-coaps
> -Original Message-
> From: Ace On Behalf Of Stefanie Gerdes
> Sent: Wednesday, December 12, 2018 2:17 AM
> To: ace@ietf.org
> Subject: Re: [Ace] Overwriting Tokens
>
> Hi Ludwig,
>
> On 12/12/2018 11:05 AM, Ludwig Seitz wrote:
> > On 12/12/2018 10:33, Stefanie Gerdes wrote:
> >> Hi
Hi Hannes,
Michael was only asking if allowing any anonymous entity to get the cacerts
(trusted root cert list) is worth it. RFC7030 allows for this. Of course an
enrollment would still require authentication/authorization.
I was making the case that it is not worth to even allow anonymous get
Hi Panos, Hi Michael,
> We want all our clients to be authenticated by DTLS before they start loading
> up our RF network.
> I'm not suggesting that the DTLS be skipped, I'm suggesting that the client
> certificate presented might be meaningless to the EST server.
I am curious what security
Hi Ludwig,
On 12/12/2018 11:05 AM, Ludwig Seitz wrote:
> On 12/12/2018 10:33, Stefanie Gerdes wrote:
>> Hi again,
>>
>> I have one additional comment to ace-oauth-17:
>>
>> Section 5.8.1 recommends that RS stores only one token per key and that
>> existing tokens are overwritten by new tokens. I
On 12/12/2018 10:33, Stefanie Gerdes wrote:
Hi again,
I have one additional comment to ace-oauth-17:
Section 5.8.1 recommends that RS stores only one token per key and that
existing tokens are overwritten by new tokens. I wonder how the RS knows
which token is the most recent. I don't think
On 12/12/2018 10:27, Stefanie Gerdes wrote:
Hi Jim,
thank you for your quick response.
On 12/11/2018 09:38 PM, Jim Schaad wrote:
C may receive keying material for the communication with RS from AS.
Unfortunately, the AS does not inform C how long the keying material is
valid. C
therefore
On 11/12/2018 21:38, Jim Schaad wrote:
-Original Message-
From: Ace On Behalf Of Stefanie Gerdes
Sent: Tuesday, December 11, 2018 4:11 AM
To: Ludwig Seitz ; ace@ietf.org
Subject: Re: [Ace] Fwd: New Version Notification for
draft-ietf-ace-oauth-authz-
17.txt and
Hi again,
I have one additional comment to ace-oauth-17:
Section 5.8.1 recommends that RS stores only one token per key and that
existing tokens are overwritten by new tokens. I wonder how the RS knows
which token is the most recent. I don't think the expiration time helps
in this case because
Hi Jim,
thank you for your quick response.
On 12/11/2018 09:38 PM, Jim Schaad wrote:
>>
>> C may receive keying material for the communication with RS from AS.
>> Unfortunately, the AS does not inform C how long the keying material is
> valid. C
>> therefore may use outdated keying material for
13 matches
Mail list logo
