Re: [Anima] Proposal of enhancing the BRSKI example scope with CMP

> On 28. Feb 2018, at 23:46, Michael Richardson <m...@sandelman.ca> wrote: > > Fries, Steffen <steffen.fr...@siemens.com> wrote: >> The current BRSKI draft addresses the bootstrapping of a secure >> infrastructure based on existent manufacturer certific

[Anima] Proposal of enhancing the BRSKI example scope with CMP

Hello, I have a question regarding the utilized enrollment protocols in BRSKI. The current BRSKI draft addresses the bootstrapping of a secure infrastructure based on existent manufacturer certificates. This is for sure a basic requirement in industrial applications to enable secure service

Re: [Anima] BRSKI support for asynchronous processing

Michael Richardson wrote: > > Besides this, we see further use cases, in which the connection to the > PKI is > > not always available. This may be the case if the connection to the CA > is only > > temporary available or not directly available. Here, the approach would > require

[Anima] BRSKI support for asynchronous processing

Hi everyone, We are currently in the process of discussing different scenarios and approaches for the onboarding of (IoT) devices in plants, substations, or cloud-based services. The current BRSKI document provides here a good approach to address the case in which a pledge has an online

Re: [Anima] BRSKI support for asynchronous processing

Hi Eliot We are currently in the process of discussing different scenarios and approaches for the onboarding of (IoT) devices in plants, substations, or cloud-based services. The current BRSKI document provides here a good approach to address the case in which a pledge has an online connection

Re: [Anima] BRSKI support for asynchronous processing

Hi Brian -Original Message- From: Brian E Carpenter Sent: Sonntag, 25. November 2018 20:22 To: Eliot Lear ; Fries, Steffen (CT RDA ITS) Cc: anima@ietf.org Subject: Re: [Anima] BRSKI support for asynchronous processing On 2018-11-26 02:09, Eliot Lear wrote: > Hi Stef

Re: [Anima] BRSKI support for asynchronous processing

Hi Eliot I assumed it to be collocates with the RA and that the CA is separate. Ok, well there we have it ;-) I should have been more specific. I was referring to the EST request. The BRSKI request regarding the voucher is assumed to a proxy residing inside the plant. I assumed a strong

Re: [Anima] BRSKI support for asynchronous processing

Hi Eliot OK, thanks. I'm interested in another scenario too: one where the operator will not accept using a connection to the open Internet and therefore will not accept any real-time access to any MASA. As I've said for several years, this is a highly likely scenario in some types of network

Re: [Anima] BRSKI support for asynchronous processing

Hi Eliot On 27 Nov 2018, at 11:49, Fries, Steffen mailto:steffen.fr...@siemens.com>> wrote: Getting back to my original question, do you see the asynchronous handling of pledge enrolment as part of the current charter of the working group? I don’t know (I'll leave the to the chairs). As

Re: [Anima] I-D Action: draft-fries-anima-brski-async-enroll-00.txt

Hi Brian, > Since I won't be in Prague, I'd like to express strong support > for this work. Thank you. > I do have one question. Is the following use > case also valid? (I see the "Building automation" case as a > subset of this case, not to mention all kinds of industrial > control systems.) >

[Anima] FW: New Version Notification for draft-fries-anima-brski-async-enroll-00.txt

for a slot in the agenda to discuss the draft during the next IETF meeting. Best regards Steffen -Original Message- From: internet-dra...@ietf.org Sent: Montag, 11. März 2019 10:52 To: Eliot Lear ; Fries, Steffen (CT RDA ITS) ; Brockhaus, Hendrik (CT RDA ITS SEA-DE) Subject: New Version

Re: [Anima] Call for agenda ANIMA @ IETF 104, Prague

): Steffen Fries Best regards Steffen From: Anima On Behalf Of [ext] Fries, Steffen Sent: Samstag, 9. März 2019 14:18 To: anima@ietf.org; jiangsh...@huawei.com Cc: anima-cha...@ietf.org Subject: Re: [Anima] Call for agenda ANIMA @ IETF 104, Prague Hi Sheng, hi Toerless As asked earlier, we would like

Re: [Anima] Call for agenda ANIMA @ IETF 104, Prague

Hi Sheng, hi Toerless As asked earlier, we would like to have a time slot to discuss the asynchronous enrollment support in BRSKI. I will submit the corresponding draft Monday latest. Name of time slot: Support of asynchronous enrollment in BRSKI Name of draft(s):

[Anima] New work item proposal / agenda request

Hello Toerless, hello Sheng, Based on the discussion we had in December about support of asynchronous operation/enrollment support in BRSKI on the mailing list, I'm preparing a contribution for the next IETF meeting. The work is based on requirements from industrial and IoT scenarios and

Re: [Anima] New work item proposal / agenda request

Hi Toerless, Sounds great. Looking forward to the meeting. Best regards Steffen > -Original Message- > From: Toerless Eckert > Sent: Freitag, 8. Februar 2019 13:26 > To: Fries, Steffen (CT RDA ITS) > Cc: tte+an...@cs.fau.de; jiangsh...@huawei.com; anima@ietf.org; Brockh

Re: [Anima] New work item proposal / agenda request

Hi Sheng, hi Eliot, I think I would probably need around 15 minutes. Or depending on what is left. From my point of view it would be motivating the work in the first step.. Best regards Steffen From: Sheng Jiang Sent: Montag, 11. Februar 2019 09:37 To: Eliot Lear Cc: Fries, Steffen (CT RDA

Re: [Anima] Last Call: (Bootstrapping Remote Secure Key Infrastructures (BRSKI)) to Proposed Standard

mote Secure > Key Infrastructures > (BRSKI)) to Proposed Standard > > On 2019-05-29 11:06 a.m., Fries, Steffen wrote: > > Hi, > > > > As this is the last call, it may not be to late to ask the question. I read > > the draft a couple of times and was stumbling upon t

Re: [Anima] Last Call: (Bootstrapping Remote Secure Key Infrastructures (BRSKI)) to Proposed Standard

Hi, As this is the last call, it may not be to late to ask the question. I read the draft a couple of times and was stumbling upon the following: In Figure 1 of the BRSKI draft, for the communication between the Domain Registrar (RA) and the Key Infrastructure (CA), EST is stated. >From my

Re: [Anima] Last Call: (Bootstrapping Remote Secure Key Infrastructures (BRSKI)) to Proposed Standard

Hi Michael, Cristal clear. Thank you for the prompt response. Best regards Steffen > -Original Message- > From: Michael Richardson > Fries, Steffen wrote: > > Yes, definitely. This would help. Thanks. > > https://github.com/anima-wg/anima-bootstrap/

Re: [Anima] evaluation of pinned-domain-cert equality in BRSKI

Hi Michael, My comments are inline. > -Original Message- > From: Anima On Behalf Of Michael Richardson > Sent: Freitag, 26. April 2019 00:16 > To: anima@ietf.org > Subject: [Anima] evaluation of pinned-domain-cert equality in BRSKI > > > Due to a design concern my MASA looks up

Re: [Anima] Call for agenda ANIMA @ IETF 105, Montreal

Hi Sheng, I would like to ask for a timeslot on: Name of time slot: BRSKI-AE (BRSKI with support for asynchronous enrollment) Name of draft(s): draft-fries-anima-brski-async-enroll-01.txt Time requested: 10min Presenter name(s): Eliot Lear The draft covers the support of asynchronous enrollment

[Anima] FW: New Version Notification for draft-fries-anima-brski-async-enroll-01.txt

ail asking for a presentation slot during the next IETF meeting Best regards Steffen -Original Message- From: internet-dra...@ietf.org Sent: Montag, 8. Juli 2019 12:01 To: Eliot Lear ; Fries, Steffen (CT RDA CST) ; Brockhaus, Hendrik (CT RDA CST SEA-DE) Subject: New Version Notification

[Anima] Questions raised during IETF 105 regarding BRSKI-AE

Hi, during IETF 105, there were several questions raised regarding motivation and approach in BRSKI-AE (https://datatracker.ietf.org/doc/draft-fries-anima-brski-async-enroll/ ) I just checked the recordings and would like to provide some answers. Thanks Eliot for presenting in the first place.

Re: [Anima] Questions raised during IETF 105 regarding BRSKI-AE

Hi Michael, > From: Michael Richardson > Fries, Steffen wrote: > > There was a question regarding the benefits on Full CMC (PKI) Request > > support in EST from Michael. One of the benefits of the Full CMC > > request is that it provides a way to bind t

Re: [Anima] Call for agenda ANIMA @ IETF 106, Singapore

Hi Sheng, We are currently in the process of updating the draft on BRSKI-AE. I would like to give a status update on this work. I will upload the new version in the next couple of days. > Name of time slot: BRSKI-AE Updates > Name of draft(s): draft-fries-anima-brski-async-enroll-02 > Time

[Anima] FW: I-D Action: draft-fries-anima-brski-async-enroll-03.txt

Hi all, I just posted an update of the draft for BRSKI-AE. Besides the already addressed approach using authenticated self-contained objects (signed objects) during the enrollment to address situations in which no direct connectivity to a PKI is available, a second approach is described.

Re: [Anima] ANIMA: Request for agenda items and more for IETF107

Hi Toerless, Based on the submitted update of the draft on BRSKI-AE, I would like to give a status update on the document and also ask for WG adoption. I planned for remote participation of the meeting. Name of time slot: BRSKI-AE Updates Name of draft(s):

Re: [Anima] I-D Action: draft-fries-anima-brski-async-enroll-03.txt

Hi Brian, Thanks for spotting this. The intention here is to behave in the same way as described in draft-ietf-anima-bootstrapping-keyinfra. I will take a note to correct this in the next version. BRSKI-AE is more targeting the data objects used for certificate enrollment but leaving base as

[Anima] Next steps for BRSKI-AE

Hi Toerless, During the interim ANIMA WG meeting last week we discussed the current status of BRSKI-AE and also asked for WG adoption. No objections have been raised in the meeting. What would be the next steps? I understood that the acceptance would be done via the mailing list. Best regards

Re: [Anima] ANIMA interim scheduled - Please (re) ask for timeslots

Hi Toerless, Just uploaded the slides. I also changed the name from Owen to my name for the update o BRSKI-AE in the agenda. Best regards Steffen > -Original Message- > From: Toerless Eckert > Sent: Mittwoch, 8. April 2020 05:13 > To: Fries, Steffen (CT RDA CST) > Cc:

Re: [Anima] ANIMA interim scheduled - Please (re) ask for timeslots

Hi Toerless, Just to be sure I did not miss anything, is the schedule for the meeting on Thursday already fixed? I haven't seen an update, yet. Do you collect the slides in advance for the meeting? Best regards Steffen > -Original Message- > From: Anima On Behalf Of [ext]

Re: [Anima] ANIMA interim scheduled - Please (re) ask for timeslots

Hi Toerless, Based on the submitted update of the draft on BRSKI-AE, I would like to give a status update on the document and also ask for WG adoption. Name of time slot: BRSKI-AE Updates Name of draft(s): draft-fries-anima-brski-async-enroll-03 Time requested: 10-15 min Presenter name(s):

[Anima] Necessary steps for WG adoption of BRSKI-AE, was RE: Next steps for BRSKI-AE

. It was noted, that the adoption would be done via the mailing list. My understanding was that the chairs would initiate that call, but I'm not sure. If there is anything I can do to support, please let me know. Best regards Steffen From: Anima On Behalf Of [ext] Fries, Steffen Sent: Donnerstag, 16

Re: [Anima] ANIMA: WG call for consensus BRSKI "endpoint path" modification (was: Re: Status of renaming endpoint path?)

I support the proposed change. Best regards Steffen > -Original Message- > From: Anima On Behalf Of William Atwood > Sent: Dienstag, 1. September 2020 04:25 > To: Toerless Eckert ; Anima WG > Cc: Warren Kumari > Subject: Re: [Anima] ANIMA: WG call for consensus BRSKI "endpoint path" >

Re: [Anima] Handling of endpoint path names (from BRSKI-AE discussion today)

Hi Michael, > -Original Message- > From: Michael Richardson > Sent: Freitag, 28. August 2020 20:32 > > Maybe I phrased it wrong. The intention is not to make the pledge more > > complex. The goal should be to keep the pledge simple and enhance the > > registrar to handle also

Re: [Anima] BRSKI extensions design team - meeting

Hi Michael, It is on github now. Thanks to Thoams, I was able to upload the current version and the working document Best regards Steffen > -Original Message- > From: Anima On Behalf Of Michael Richardson > Sent: Donnerstag, 8. Oktober 2020 04:44 > To: anima@ietf.org > Subject: Re:

Re: [Anima] Handling of endpoint path names (from BRSKI-AE discussion today)

> From: Michael Richardson > Fries, Steffen wrote: > >> I understand the use case with CoAP, where one wants to be able to > multicast a > >> request to /.well-known/core to find out which devices support a > particular > >> service. >

Re: [Anima] Handling of endpoint path names (from BRSKI-AE discussion today)

Hi Michael, > > As far as I can tell, in the PULL case, when CMP (or another > > mechanism) will be used, there is still a voucher exchange first. The > > Registrar can express it's preference in the (parboiled) voucher-request > from Registrar to MASA. > PULL was meant to describe the behavior

Re: [Anima] Handling of endpoint path names (from BRSKI-AE discussion today)

> -Original Message- > From: Michael Richardson > Sent: Mittwoch, 26. August 2020 21:43 > > Fries, Steffen wrote: > >> Can you explain to me why the discovery via /.well-known/brski is > >> useful? This is on the *REGISTRAR*. > >

Re: [Anima] about moving /.well-known/est/enrollstatus ??

Hi Michael, Sorry for the late replay on this. There is probably one fits all answer for this. The reason is that the enrollment protocols are defined different in that respect. - EST does not provide it out of the box, this was the reason to have it in BRSKI - CMP provides a certificate

Re: [Anima] about moving /.well-known/est/enrollstatus ??

> Sorry for the late replay on this. There is probably one fits all answer for > this. I definitely meant no single answer to this. > The reason is that the enrollment protocols are defined different in that > respect. > - EST does not provide it out of the box, this was the reason to have it in

Re: [Anima] Handling of endpoint path names (from BRSKI-AE discussion today)

> From: Anima On Behalf Of Michael Richardson > Fries, Steffen wrote: > >> My answers: > >> 1) No, I don't want to rename anything. Let BRSKI-AE establish a new > registry. > >> > >> 2) I don't want to Link Discovery, and I thi

Re: [Anima] Handling of endpoint path names (from BRSKI-AE discussion today)

Hi Michael, Thank you for your view on the discussion and the proposals. > Aliasing on the server sides (MASA, Registrar) is trivial. > But, the alias will have to remain for all time. Yes, that was the burden connected. > Aliasing on the client, which has to make a decision and possibly a

Re: [Anima] Handling of endpoint path names (from BRSKI-AE discussion today)

nt upon further need also works. We may reuse the text then for a >separate document if necessary. I conclude that the WG is in favor of this way. Best regards Steffen > > Cheers > Toerless > > > Eliot > > > > > On 30 Jul 2020, at 17:46, Fries, Stef

[Anima] Rquest for a timeslot slot for the ANIMA WG meeting at IETF 108

Hi Toerless, hi Sheng, Sorry for jumping forward as you haven't send out the agenda request email. I will be not available in the next two weeks, hence my early email regarding a slot in the agenda. I'm currently preparing the submission of the draft-ietf-anima-brski-async-enroll-00 after the

[Anima] FW: New Version Notification for draft-ietf-anima-brski-async-enroll-00.txt

ion description as separate sections. History moved to appendix. Best regards Steffen -Original Message- From: internet-dra...@ietf.org Sent: Freitag, 10. Juli 2020 09:29 To: Fries, Steffen (CT RDA CST) ; Eliot Lear ; Brockhaus, Hendrik (CT RDA CST SEA-DE) Subject: New Version Notificat

Re: [Anima] ANIMA-WG: pls chime in: early allocation for otherName code points (draft-ietf-anima-autonomic-control-plane)

+1 I consider going with otherNames for the ACP domain the safe way. Taking interactions with existing infrastructures into account may lead to potential misinterpretations of using other fields as the discussion has shown. Having a distinct allocation is more clear. Best regards Steffen >

Re: [Anima] Adoption call for draft-fries-anima-brski-async-enroll-03, ends July 1st 2020

Hello Sheng, hello Toerless, As the WG adoption call passed, I would like to ask what the next steps are? On the mailing list I saw positive votes and no objection, which is a good sin from my understanding. Please let me know how we proceed, as we plan to provide an update of the draft in the

Re: [Anima] Adoption call for draft-fries-anima-brski-async-enroll-03, ends July 1st 2020

Hi Brian, Thank you for the support. Points taken. I will consider them in the next update. Best regards Steffen > -Original Message- > From: Anima On Behalf Of Brian E Carpenter > Sent: Montag, 22. Juni 2020 22:30 > To: Sheng Jiang > Cc: anima-cha...@ietf.org; Rob Wilton (rwilton) ;

Re: [Anima] Adoption call for draft-fries-anima-brski-async-enroll-03, ends July 1st 2020

Hi Michael > -Original Message- > From: Anima On Behalf Of Michael Richardson > Sent: Montag, 22. Juni 2020 02:59> > I have read draft-fries-anima-brski-async-enroll-03 and I would be happy to > have it as the basis for an extension. PLEASE ADOPT. Thanks for the support. > --- > >

Re: [Anima] last minute changes to BRSKI to do endpoint discovery

Hi Michael, > From: Michael Richardson > > I would appreciate to use /.well-known/brski for the endpoints > > specified in BRSKI and use /.well-known/est for those specified in > > RFC7030. > > This offers more flexibility for future extensions like BSKI-AE. > > Such a change

[Anima] Handling of endpoint path names (from BRSKI-AE discussion today)

Hi, Based on the discussion of splitting up the voucher handling endpoint naming issues from BRSKI-AE today, I just wanted to ensure I got the way forward right. >From the Etherpad discussion I understood Michael that he would not be too >happy with having a BRSKI update right after BRSKI

[Anima] FW: New Version Notification for draft-ietf-anima-brski-async-enroll-01.txt

net-dra...@ietf.org Sent: Donnerstag, 7. Januar 2021 15:24 To: Eliot Lear ; Brockhaus, Hendrik (T RDA CST SEA-DE) ; Fries, Steffen (T RDA CST) ; Werner, Thomas (T RDA CST SEA-DE) Subject: New Version Notification for draft-ietf-anima-brski-async-enroll-01.txt A new version of I-D, draft-i

[Anima] FW: New Version Notification for draft-ietf-anima-brski-async-enroll-02.txt

issues related to the once enumerated in the anima gitlab. Please provide feedback as it helps to further develop the approach. Best regards Steffen -Original Message- From: internet-dra...@ietf.org Sent: Montag, 14. Juni 2021 18:23 To: Eliot Lear ; Brockhaus, Hendrik (T RDA CST SEA-DE) ;

[Anima] Reuse of SZTP-CSR YANG definition in BRSKI-AE

Hi Kent, There is a further YANG related question in the context of BRSKI-AE. In one use case, the pledge has no direct connection to the registrar and a registrar-agent communicates with the pledge. In that specific case we do not have a TLS connection between the pledge and the

Re: [Anima] [netmod] [anima-wg/anima-brski-async-enroll] Definition of new assertion type (agent-proximity) for the voucher (#18)

Hi Andy, Thank you for pointing out that it will not be possible to have a straight forward enhancement of the enum. I have some questions to the points you raised: >From: Anima anima-boun...@ietf.org On Behalf Of >Andy Bierman >An enumeration type is hard-wired.

Re: [Anima] [netmod] [anima-wg/anima-brski-async-enroll] Definition of new assertion type (agent-proximity) for the voucher (#18)

Hi Andy, Thanks for the reference. I have to dive into that a little deeper. Based on your previous comment, it would be possible to use the “deviate replace” to and replace the existing enum in the voucher definition by an enhanced enum definition in our document. If I understood this right,

[Anima] FW: New Version Notification for draft-ietf-anima-brski-async-enroll-03.txt

, Hendrik (T RDA CST SEA-DE) ; Fries, Steffen (T RDA CST) ; Werner, Thomas (T RDA CST SEA-DE) Subject: New Version Notification for draft-ietf-anima-brski-async-enroll-03.txt A new version of I-D, draft-ietf-anima-brski-async-enroll-03.txt has been successfully submitted by Steffen Fries and posted

Re: [Anima] [anima-wg/anima-brski-async-enroll] Definition of new assertion type (agent-proximity) for the voucher (#18)

Hi Kent New assertion type for the voucher necessary for agent-proximity. Likely to enhance the enum in the YANG module for the voucher in [RFC

Re: [Anima] Input/Questions for ANIMA @ IETF 111, online

Hi Toerless, Given the current state of discussion in the design team and also evolvement of BRSKI-AE it would probably be good to have more time to present/discuss. So I would like to ask for 15 minutes on this topic to provide an overview about the current state and approaches. Best

Re: [Anima] revising RFC8366 -- Re: BRSKI-AE enum issue -> empty, but what's he encoding ?

> From: Michael Richardson > Sent: Montag, 5. Juli 2021 00:17 > Fries, Steffen wrote: > >> I thought I wrote a really nice ASCII art version of what documents > inherit > from > >> RFC8366. I can't find it in my outbox... I wonder if

Re: [Anima] Resending: Call for adoption: draft-richardson-anima-jose-voucher

Hi Toerless, I support the adoption. As you wrote we are using the approach in BRSKI-AE and depend on it. Best regards Steffen > -Original Message- > From: Anima On Behalf Of Toerless Eckert > Sent: Donnerstag, 1. Juli 2021 18:34 > To: anima@ietf.org > Subject: [Anima] Resending:

Re: [Anima] revising RFC8366 -- Re: BRSKI-AE enum issue -> empty, but what's he encoding ?

Hi Michael, > -Original Message- > From: Michael Richardson > Sent: Mittwoch, 30. Juni 2021 02:37 > I thought I wrote a really nice ASCII art version of what documents inherit > from > RFC8366. I can't find it in my outbox... I wonder if I nuked the draft by > mistake. > > The

Re: [Anima] Call for agenda items ANIMA @ IETF 111, online

Hello Toreless, We would like to provide an update to BRSKI-AE. Here the info: Topic/Title : BRSKI-AE Name of Presenter(s) : Steffen Fries Length of time requested : 15 min If applicable :

[Anima] BRSKI-AE#2: Terminology change from pledge-agent to registrar-agent

Hi, based on the discussion during the ANIMA session this week, we would like to discuss some open issues related to BRSKI-AE. They are also available under https://github.com/anima-wg/anima-brski-async-enroll/issues Issue#2: Terminology change for pledge-agent Current term used in BRSKI-AE

[Anima] BRSKI-AE #3: Terminology change for PULL/PUSH model

Hi, based on the discussion during the ANIMA session this week, we would like to discuss some open issues related to BRSKI-AE. They are also available under https://github.com/anima-wg/anima-brski-async-enroll/issues Issue#3: Terminology change for PULL/PUSH model The currently used

[Anima] BRSKI-AE #4 Trust relation between registrar-agent and registrar

Hi, based on the discussion during the ANIMA session this week, we would like to discuss some open issues related to BRSKI-AE. They are also available under https://github.com/anima-wg/anima-brski-async-enroll/issues Issue #4: Trust relation between registrar-agent and registrar (use case 2

[Anima] BRSKI-AE#5 Trust relation between pledge(-callee) and registrar-agent

Hi, based on the discussion during the ANIMA session this week, we would like to discuss some open issues related to BRSKI-AE. They are also available under https://github.com/anima-wg/anima-brski-async-enroll/issues Issue #5: Trust relation between pledge(-callee) and registrar-agent (use

Re: [Anima] draft-ietf-acme-star-delegation-05.txt and BRSKI-AE

Hi Michael, Sorry for the late response. > We have struggled with brski-ae to deal with how the pledge can pin a thing > from the pledge-agent to prove proximity. Based on some further discussion, we have to decide, how the proximity is handled in BRSKI-AE. The motivation for now was to have it

Re: [Anima] draft-ietf-acme-star-delegation-05.txt and BRSKI-AE

> From: Michael Richardson wrote: > > Sorry for the late response. > >> We have struggled with brski-ae to deal with how the pledge can pin a > >> thing from the pledge-agent to prove proximity. > > > Based on some further discussion, we have to decide, how the proximity > >

Re: [Anima] Adoption call for draft-friel-anima-brski-cloud-04, ends April 20th 2021

Hi, I'm in favor of adoption. Introducing a cloud registrar also addresses domains with no local registrar to allow pledges to onboard to specific domain. Best regards Steffen From: Anima On Behalf Of Sheng Jiang Sent: Mittwoch, 7. April 2021 12:01 To: anima@ietf.org Cc:

Re: [Anima] Adoption call for draft-richardson-anima-voucher-delegation-03, ends April 19th 2021

Hi, I'm in favor of adopting the document as it allows for more flexibility in the voucher handling specifically in use cases, in which a direct connection to a MASA may not be possible during the bootstrapping. Best regards Steffen From: Anima On Behalf Of Sheng Jiang Sent: Dienstag, 6.

Re: [Anima] Yangdoctors early review of draft-ietf-anima-brski-async-enroll-03

Hi Reshad, Thank you for the review. I will address the points in the next update of the draft. I took over the proposed changes you made and will provide the tree diagram and the enhancement to the security considerations as suggested. In the ANIMA design team we will discuss the

[Anima] CSR grouping introduced in draft-ietf-netconf-sztp-csr-06

Hi Kent, I just went over the changes regarding the csr-grouping (https://datatracker.ietf.org/doc/html/draft-ietf-netconf-sztp-csr-08#section-3.2) you introduced in draft-ietf-netconf-sztp-csr-06. To my understanding (I'm not too deep into YANG yet) the new grouping of the csr in the YANG

Re: [Anima] BRSKI-AE document split discussion

Hi Toerless, Just using the previous thread to ask if there has been a decision regarding the document split of BRSKI-AE, we proposed during IETF 111. Best regards Steffen > -Original Message- > From: Anima On Behalf Of Michael Richardson > Sent: Donnerstag, 5. August 2021 15:58 > To:

Re: [Anima] Yangdoctors early review of draft-ietf-anima-brski-async-enroll-03

Hi Reshad, From: Reshad Rahman Sent: Mittwoch, 18. August 2021 23:08 >reshad> Other comments: - rc:yang-data (RFC8040) is used. While this >reshad> seems to be fine, if the voucher- request-async-artifact template >reshad> needs to be extended in the future, my understanding is that

Re: [Anima] Yangdoctors early review of draft-ietf-anima-brski-async-enroll-03

Hi Michael, > -Original Message- > From: Michael Richardson > Sent: Mittwoch, 18. August 2021 13:27 > > reshad> Other comments: - rc:yang-data (RFC8040) is used. While this > reshad> seems to be fine, if the voucher- request-async-artifact template > reshad> needs to be

Re: [Anima] BRSKI-AE document split discussion

Hi Toerless, hi Michael > -Original Message- > From: Michael Richardson > Sent: Freitag, 3. September 2021 19:09 > > t...@cs.fau.de wrote: > > plant would often want to have a combination of both scenarios: > > The manufacturing plant might prefer to not be connected to the >

Re: [Anima] BRSKI-AE document split discussion

Hi Michael, hi Brian, > -Original Message- > From: Brian E Carpenter > Sent: Montag, 2. August 2021 23:07 > On 03-Aug-21 07:55, Michael Richardson wrote: > > > > Fries, Steffen wrote: > > > Based on the discussion in the ANIMA WG last week,

[Anima] Timeline for BRSKI-AE Review

Dear Yang Doctors, I just wanted to ask if there is any timeline information available for the review of BRSKI-AE. We have at least two YANG questions connected to the draft, on relates to the ongoing discussion regarding RFC8366bis to allow further assertions to be added. This relates to

Re: [Anima] [yang-doctors] Timeline for BRSKI-AE Review

Hello Reshad, hello Mehmet, Thank you for getting back on this. I think end of the week is perfect. The review was intended as a pre-review. Best regards Steffen From: Reshad Rahman Sent: Dienstag, 10. August 2021 04:45 To: Fries, Steffen (T RDA CST) ; Mehmet Ersue Cc: 'Eliot Lear

[Anima] BRSKI-AE document split discussion

Hello, Based on the discussion in the ANIMA WG last week, I would like to proceed with the discussion on the author's proposal to split the current BRSKI-AE draft (https://datatracker.ietf.org/doc/html/draft-ietf-anima-brski-async-enroll-03) to separate the contained use cases as they have

Re: [Anima] BRSKI-AE document split discussion

Hi Michael > -Original Message- > From: Michael Richardson > Sent: Dienstag, 3. August 2021 18:28 > > Fries, Steffen wrote: > > Use Case 1 is relying on RFC 8995 for communication flow and for the > > voucher handling, but targets to use alter

Re: [Anima] BRSKI-AE document split discussion

concise and specific for the normative part. As soon as we have further output from the discussion, we will post it to the list. Best regards Steffen > -Original Message- > From: t...@cs.fau.de > Sent: Donnerstag, 7. Oktober 2021 20:22 > To: Fries, Steffen (T RDA CST) &

Re: [Anima] BRSKI-AE document split discussion

design team meeting today. Based on that we would fork the repository (with the new names) and start to separate the content. Best regards Steffen > -Original Message- > From: Anima On Behalf Of Fries, Steffen > Sent: Freitag, 8. Oktober 2021 10:28 > To: t...@cs.fau.de

Re: [Anima] BRSKI-AE document split discussion

The next steps would be to prepare the documents (and repository) and submit a first version of both drafts as WG draft before the submission deadline. We would give an overview about the changes during the ANIMA session at IETF 112. Best regards Steffen > -Original Message- > F

Re: [Anima] BRSKI-AE document split discussion

Hi Michael > -Original Message- > From: Michael Richardson > Sent: Sonntag, 10. Oktober 2021 18:51 > Fries, Steffen wrote: > > We will go ahead and discuss the split (content, authors, ...) in the > > round of current authors and will also pro

Re: [Anima] BRSKI-AE document split discussion

etf.org > Cc: t...@cs.fau.de; Fries, Steffen (T RDA CST) > Subject: Re: [Anima] BRSKI-AE document split discussion > > > I think that Thomas' explanation makes sense. > > Split the document. I suggest you clone the repo, and post a second copy > under > a new name. >

[Anima] FW: I-D Action: draft-ietf-anima-brski-async-enroll-04.txt

Hello all, This is the update of BRSKI-AE with the changes discussed last week. The current document focuses on use case 1 discussed in BRSKI-AE. I have also submitted a separate document covering UC2, which I will forward to the WG, once the submission has been approved by the WG chairs. We

Re: [Anima] Call for agenda items ANIMA @ IETF 112

Hi Toerless, hi Cheng We would like to give an overview on BRSKI-AE and the performed document split and the addressed issues. Title: Status of BRSKI-AE and derived work Presenter: Steffen Fries Length: 10 minutes Drafts: - Support of Asynchronous Enrollment in BRSKI (BRSKI-AE),

[Anima] FW: I-D Action: draft-ietf-anima-brski-prm-00.txt

Hello, Yesterday the second part of the original work on BRSKI-AE covering use case 2 was submitted as new WG draft. The following changes have been made: * Moved UC2 related parts defining the pledge in responder mode from draft-ietf-anima-brski-async-enroll-03 to this document This

Re: [Anima] Call for adoption: draft-richardson-anima-rfc8366bis, ends December 19th, 2021

Hi, This is necessary work we rely on in BRSKI-PRM. I fully support the adoption. Best regards Steffen From: Anima On Behalf Of Sheng Jiang Sent: Montag, 6. Dezember 2021 07:57 To: anima@ietf.org Cc: anima-cha...@ietf.org; Toerless Eckert Subject: [Anima] Call for adoption:

Re: [Anima] New Version Notification for draft-richardson-anima-rfc8366bis-04.txt

Hi Michael, Thank you for the update, I included the updated voucher also in BRSKI-PRM (working version on github), which should address issue https://github.com/anima-wg/anima-brski-prm/issues/4. Nevertheless, BRSKI-PRM currently does not contain a YANG module for the voucher itself, only for

Re: [Anima] Steffen/Michael/*: Slot for draft-ietf-anima-jws-voucher-00 ?! Re: Call for agenda items ANIMA @ IETF 111, online

nt: Freitag, 23. Juli 2021 02:12 > To: Fries, Steffen (T RDA CST) > Cc: anima@ietf.org; anima-cha...@ietf.org; Werner, Thomas (T RDA CST SEA- > DE) ; Brockhaus, Hendrik (T RDA CST SEA-DE) > ; Eliot Lear > Subject: Steffen/Michael/*: Slot for draft-ietf-anima-jws-voucher-00 ?! Re: &

[Anima] FW: I-D Action: draft-ietf-anima-brski-prm-01.txt

Hello all, I just uploaded a new version of BRSKI-PRM. It contains the following changes to the last version: Here is the list of contained changes: * Issue #15 lead to the inclusion of an option for an additional signature of the registrar on the voucher received from the MASA before

Re: [Anima] Call for agenda items/attendance ANIMA @ IETF 113

Hi Toerless, I would like to ask for a slot in the agenda. Topic/Title: Status Update on BRSKI-PRM Name of Presenter(s): Steffen Fries Length of time requested: 10 minutes name of draft(s): discussed draft-ietf-anima-brski-prm-01 (will be version 02 as we plan to submit a further update before

Re: [Anima] Call for agenda items/attendance ANIMA @ IETF 113

to submit a further update before the deadline) Best regards Steffen > -Original Message- > From: Fries, Steffen (T CST) > Sent: Mittwoch, 23. Februar 2022 11:19 > To: t...@cs.fau.de; anima@ietf.org > Cc: anima-cha...@ietf.org > Subject: RE: [Anima] Call for agenda items/atten

[Anima] FW: I-D Action: draft-ietf-anima-brski-prm-02.txt

Hello, I just uploaded a new version of BRSKI-PRM. We plan to provide an overview of the changes in the ANIMA session of IETF 113 The main changes comprise: * Resolution of Issue #15 included additional signature on voucher from registrar in Section 5.1.4.2 and Section 5.1.1 to allow for

Re: [Anima] title for join proxy document

Hi Esko, I would also assume that the constraint part is the pledge in the first place, which may take over the role of a join proxy. If the intention is to emphasize that the pledge is constraint my favorite out of the 3 would be _Join Proxy for Lightweight Bootstrapping Protocols_. I would

Re: [Anima] Initial Call for agenda discussion / items ANIMA@IETF118 Prague (was: anima - New Meeting Session Request for IETF 118)

Hi Toreless, I would like to ask for the following slots in the IETF 118 meeting: Topic/TitleBRSKI-AE Status Update Name of Presenter(s) David von Oheimb Length of time requested 5 min If applicable: name of draft(s)

  1   2   >