[Anima] FW: New Version Notification for draft-ietf-anima-brski-ae-11.txt

[Fries, Steffen]

Dear all,

we just submitted version 11 of BRSKI-AE addressing the review comments we 
received from Mahesh. The comments and resolution have been discussed in the 
previous email.

Best regards
Steffen

-Original Message-
From: internet-dra...@ietf.org 
Sent: Monday, June 3, 2024 4:01 PM
To: von Oheimb, David (T CST SEA-DE) ; von 
Oheimb, David (T CST SEA-DE) ; Brockhaus, Hendrik 
(T CST SEA-DE) ; Fries, Steffen (T CST) 

Subject: New Version Notification for draft-ietf-anima-brski-ae-11.txt

A new version of Internet-Draft draft-ietf-anima-brski-ae-11.txt has been 
successfully submitted by Steffen Fries and posted to the IETF repository.

Name: draft-ietf-anima-brski-ae
Revision: 11
Title:BRSKI-AE: Alternative Enrollment Protocols in BRSKI
Date: 2024-06-03
Group:anima
Pages:41
URL:  https://www.ietf.org/archive/id/draft-ietf-anima-brski-ae-11.txt
Status:   https://datatracker.ietf.org/doc/draft-ietf-anima-brski-ae/
HTML: https://www.ietf.org/archive/id/draft-ietf-anima-brski-ae-11.html
HTMLized: https://datatracker.ietf.org/doc/html/draft-ietf-anima-brski-ae
Diff: https://author-tools.ietf.org/iddiff?url2=draft-ietf-anima-brski-ae-11

Abstract:

   This document defines an enhancement of Bootstrapping Remote Secure
   Key Infrastructure (BRSKI, RFC 8995).  It supports alternative
   certificate enrollment protocols, such as CMP, that use authenticated
   self-contained signed objects for certification messages.

About This Document

   This note is to be removed before publishing as an RFC.

   Status information for this document may be found at
   https://datatracker.ietf.org/doc/draft-ietf-anima-brski-ae/.

   Source for this draft and an issue tracker can be found at
   https://github.com/anima-wg/anima-brski-ae.



The IETF Secretariat


___
Anima mailing list -- anima@ietf.org
To unsubscribe send an email to anima-le...@ietf.org

Re: [Anima] RFC 8995, Voucher Signing, MASA Certificate Chain provisioning

[Fries, Steffen]

Hi Michael, 

> -Original Message-
> From: Michael Richardson 
> Sent: Saturday, March 16, 2024 1:35 AM
> To: Esko Dijk ; Fries, Steffen (T CST)
> ; anima@ietf.org
> Subject: Re: [Anima] RFC 8995, Voucher Signing, MASA Certificate Chain
> provisioning
> 
> 
> Esko Dijk  wrote:
> > The requirement for the Pledge in RFC 8995 is (5.6.1): The pledge MUST
> > verify the voucher signature using the manufacturer-installed trust
> > anchor(s) associated with the manufacturer's MASA
> 
> > This leaves quite some vendor flexibility I think on how exactly to
> > verify: against 1 public key, against multiple public keys, against a
> > chain baked into the device, against a single root CA cert, against a
> > single root CA cert taken from the chain baked into the device, etc
> > etc.
> 
> Thank you for expounding on the variations.
> We have the advantage that pledges are controlled by manufacturers and they
> can decide how simple or complex they want to make their process.
> 
> The gotcha is registrars that want to verify the resulting voucher.
> It's not entirely required by RFC8995, but maybe enouraged.
> So I'd love to collect more of this kind of consideration in the 
> masa-considerations
> or the registrar-considerations.
[stf] In BRSKI-PRM, we also recommended (SHOULD) the registrar to verify the 
received voucher before signing it in 
https://www.ietf.org/archive/id/draft-ietf-anima-brski-prm-12.html#section-7.3.4.
 This emphasizes the statement in RFC 8995. 

Best regards
Steffen

> 
> >> I would propose to also allow the submission of the certificate chain
> >> of the MASA signing certificate in the SignedData part of the CMS
> >> container of the voucher.
> 
> > I expect this is already allowed by RFC 8995, given the text in 11.6:
> 
> Yes, it's not just allowed, but I would say, encouraged.
> The question is how do we do it on a constrained voucher.
> The cbrski document says some things already about this.
> 
> > There are good cryptographic hygiene reasons why a manufacturer would
> > not want to maintain access to a private key for many decades. A
> > manufacturer in that situation can leverage a long-term CA anchor,
> > built-in to the pledge, and then a certificate chain may be
> > incorporated using the normal CMS certificate set. This may increase
> > the size of the voucher artifacts, but that is not a significant issue
> > in non-constrained
> > 
> environments.¶<https://datatracker.ietf.org/doc/html/rfc8995#section-11.6-
> 3>
> > So this effectively says a vendor may want to not use the "simplest
> > solution" for security reasons, and include a cert chain of the signer.
> 
> I think that we have not done enough interoperability testing lately.
> Particularly between Registrar and MASA.
> I'd like to change this, and I'm thinking that the Paris hackathon might be a 
> good
> target date.
> 
> --
> ]   Never tell me the odds! | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works| network architect  [
> ] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails
> [
> 

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] ANIMA@IETF119 agenda posted (was: Re: ANIMA@IETF119 - call for agenda items)

[Fries, Steffen]

Hi Toerless, 

I just had a discussion with Thomas regarding agenda point 2 jws-voucher. As 
there haven't been changes to the document and as stated it is beyond WGLC that 
slot can be freed.  It is sufficient to state that the document is with the AD 
for review and it will be updated nonce comments have been received. There are 
some smaller point, which are already marked in the latest draft, but they 
rather relate to the update of references, once RFC8366bis has advanced.

Best regard
Steffen

> -Original Message-
> From: Anima  On Behalf Of Toerless Eckert
> Sent: Monday, March 11, 2024 10:56 PM
> To: anima@ietf.org
> Cc: Sheng JIANG ; mjethanand...@gmail.com;
> rwil...@cisco.com
> Subject: [Anima] ANIMA@IETF119 agenda posted (was: Re:
> ANIMA@IETF119 - call for agenda items)
> 
> Agenda is now posted.
> 
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fnotes
> .ietf.org%2Fs%2Fnotes-ietf-119-
> anima=05%7C02%7Csteffen.fries%40siemens.com%7Ce705d19d1718
> 4320d8d708dc421614ba%7C38ae3bcd95794fd4addab42e1495d55a%7C1
> %7C0%7C638457909800722705%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi
> MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0
> %7C%7C%7C=4lMy1Y8X0%2Bta8dQzMJhjCqDLVxXZfqFILnMm%2By3
> pJZ0%3D=0
> 
> If you're gong to be local in Brisbane, please consider to be note-take, that
> would be greatly appreciated!
> 
> This is a fairly lightweight agenda, but we have a few core questions that
> would be good to discuss in person, in addition, we have change of AD and
> hope to be able to discuss progress with AD/IESG review process.
> 
> Cheers
> Toerless
> 
> ___
> Anima mailing list
> Anima@ietf.org
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> .ietf.org%2Fmailman%2Flistinfo%2Fanima=05%7C02%7Csteffen.fries%
> 40siemens.com%7Ce705d19d17184320d8d708dc421614ba%7C38ae3bcd9
> 5794fd4addab42e1495d55a%7C1%7C0%7C638457909800732403%7CUnk
> nown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6I
> k1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=gKYoFXYy8O0DKQJl7T
> %2BFsKqBHuuEG%2FaB0XCFBHIUP7Q%3D=0

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] ANIMA@IETF119 - call for agenda items

[Fries, Steffen]

Hi Toerless,

I'm registered for remote participation. Luckily, the ANIMA WG meeting is 
timewise fine for European participation. 

Best regards
Steffen


> -Original Message-
> From: Toerless Eckert 
> Sent: Monday, March 11, 2024 11:05 PM
> To: Fries, Steffen (T CST) 
> Cc: anima@ietf.org; anima-cha...@ietf.org; rwil...@cisco.com
> Subject: Re: [Anima] ANIMA@IETF119 - call for agenda items
> 
> Thanks, Steffen
> 
> Let me know if you folks need any help registrering remotely to be able to 
> attend
> the meetecho. I think there is also a single-day registration option for 
> single
> meeting that we as chairs might be able to help with, if the remote attendance
> fee is not acceptable for any of you remote authors for Brisbane.
> 
> Cheers
> Toerless
> 
> On Tue, Feb 06, 2024 at 05:16:00PM +, Fries, Steffen wrote:
> > Hi Toerless,
> >
> > Here is the list of potential presentations on status updates of WG 
> > documents.
> Note that none of the drafts (so far) had substantial changes beyond 
> clarifications
> resulting from comments. If that holds until the meeting, we may also report 
> the
> status based on the chair slides.
> > Nevertheless, here the list:
> >
> > Topic/Title   Update on BRSKI-AE
> > Name of Presenter(s)David von Oheimb
> > Length of time requested 5min
> > name of draft(s) discussed   draft-ietf-anima-brski-ae-09
> > Local/remote  remote
> >
> > Topic/Title   Update on JWS-Voucher
> > Name of Presenter(s)Thomas Werner (Steffen Fries)
> > Length of time requested 5min
> > name of draft(s) discussed   draft-ietf-anima-jws-voucher-09
> > Local/remote  remote
> >
> > Topic/Title   Update on BRSKI-PRM
> > Name of Presenter(s)Steffen Fries
> > Length of time requested 5min
> > name of draft(s) discussed   draft-ietf-anima-brski-prm-11
> > Local/remote  remote
> >
> > Best regards
> > Steffen
> >
> > > -Original Message-
> > > From: Anima  On Behalf Of Toerless Eckert
> > > Sent: Friday, February 2, 2024 4:18 AM
> > > To: anima@ietf.org
> > > Cc: anima-cha...@ietf.org; rwil...@cisco.com
> > > Subject: [Anima] ANIMA@IETF119 - call for agenda items
> > >
> > > Dear ANIMA-WG
> > >
> > > We have just put in a request for a 1-hour slot to meet in Brisbane, 
> > > IETF119.
> > > Given how we will likely not have all contributors locally, we try
> > > to ensure that the meeting is in the afternoon to make remote
> > > attendance from Europe as little terrible as possible.
> > >
> > > We are also pondering if we should do an interim after Brisbane, but
> > > i think it may be useful to decide on the timing by the end of Brisbane.
> > >
> > > So, for Brisbane, pls. provide  the usual agenda item request info
> > > to anima- cha...@ietf.org or anima@ietf.org in reply to this email .
> > >
> > > Topic/Title
> > > Name of Presenter(s)
> > > Length of time requested
> > > If applicable: name of draft(s) discussed Local/remote.
> > >
> > > Thanks
> > > Toerless on behalf of the chairs
> > >
> > > In-Reply-To:
> > > <170684244040.8474.7119428583314086...@ietfa.amsl.com>
> > >
> > > On Thu, Feb 01, 2024 at 06:54:00PM -0800, IETF Meeting Session
> > > Request Tool wrote:
> > > >
> > > >
> > > > A new meeting session request has just been submitted by Toerless
> > > > Eckert, a Chair of the ANIMA Working Group.
> > > >
> > > >
> > > > -
> > > > Working Group Name: Autonomic Networking Integrated Model and
> > > Approach
> > > > Area Name: Operations and Management Area Session Requester:
> > > > Toerless Eckert
> > > >
> > > >
> > > > Number of Sessions: 1
> > > > Length of Session(s): 1 Hour
> > > > Number of Attendees: 30
> > > > Conflicts to Avoid:
> > > >  Chair conflict: detnet bier 6man intarea pim iabopen  Technology
> > > > overlap: netconf  Key participant conflict: opsarea intarea
> > > >
> > > 

Re: [Anima] RFC 8995, Voucher Signing, MASA Certificate Chain provisioning

[Fries, Steffen]

Hi Esko,

Thank you for your thoughts. I agree to your statements. I was merely thinking 
about the flexibility that is provided by BRSKI for the pledge/MASA interface.
After rethinking my comments based on your answer, this flexibility is 
something which relates only to the relation between the pledge and the MASA. 
With that the potential interoperability question can directly be addressed by 
the manufacturer to ensure interworking between his MASA and his produced 
pledges.

Thanks also for the pointer to section 11.6. The paragraph you cited is exactly 
the one I was looking for. The inclusion of the certificate chain in the CMS 
container is mentioned there. I was looking in 9.1.1 for this statement, but 
missed to check the security considerations.

Regards
Steffen


From: Anima  On Behalf Of Esko Dijk
Sent: Friday, March 8, 2024 12:41 PM

> it would mean to provide the MASA certificate chain also in the pledge 
> firmware

This is one way to do it. The simplest solution is only include the public key 
of the signer (MASA), also allowed by the 9.1.1 text. In this case, it's less 
flexible: the MASA service can't go sign with another identity/private-key: it 
MUST sign with the private key associated with the public key that's already 
baked into the Pledge.
In case a whole chain is included in the Pledge firmware as you propose, the 
validation can be a bit more flexible I think.

The requirement for the Pledge in RFC 8995 is (5.6.1):
The pledge MUST verify the voucher signature using the manufacturer-installed 
trust anchor(s) associated with the manufacturer's MASA

This leaves quite some vendor flexibility I think on how exactly to verify: 
against 1 public key, against multiple public keys, against a chain baked into 
the device, against a single root CA cert, against a single root CA cert taken 
from the chain baked into the device, etc etc.

> I would propose to also allow the submission of the certificate chain of the 
> MASA signing certificate in the SignedData part of the CMS container of the 
> voucher.

I expect this is already allowed by RFC 8995, given the text in 11.6:

There are good cryptographic hygiene reasons why a manufacturer would not want 
to maintain access to a private key for many decades. A manufacturer in that 
situation can leverage a long-term CA anchor, built-in to the pledge, and then 
a certificate chain may be incorporated using the normal CMS certificate set. 
This may increase the size of the voucher artifacts, but that is not a 
significant issue in non-constrained 
environments.¶<https://datatracker.ietf.org/doc/html/rfc8995#section-11.6-3>
So this effectively says a vendor may want to not use the "simplest solution" 
for security reasons, and include a cert chain of the signer.

Regards
Esko


From: Anima mailto:anima-boun...@ietf.org>> On Behalf 
Of Fries, Steffen
Sent: Wednesday, March 6, 2024 16:41
To: anima@ietf.org<mailto:anima@ietf.org>
Subject: [Anima] RFC 8995, Voucher Signing, MASA Certificate Chain provisioning

Hi Michael,

I've got a question regarding the MASA voucher signing or better the 
certificate chain provisioning for the MASA certificate to the pledge.

RFC 8995 states in section 91.1. 
(https://www.rfc-editor.org/rfc/rfc8995.html#section-9.1.1)
"The online service MUST have access to a private key with which to sign 
voucher artifacts 
[RFC8366<https://www.rfc-editor.org/rfc/rfc8995.html#RFC8366>]. The public key, 
certificate, or certificate chain MUST be built into the device as part of the 
firmware."

I had the assumption that the pledge only knows its IDevID and with that his 
own certificate, public/private key pair and the certificate chain from the 
issuing CA to the trust anchor.
In operational environments the issuing CA for the IDevID may not be the same 
as the issuing CA for the MASA signing certificate. From the requirement above, 
it would mean to provide the MASA certificate chain also in the pledge 
firmware, if it is different than the IDevID issuing CA. As the voucher is a 
CMS container that allows to convey the certificate chain of the signer in the 
SignedData, I would have expected it is contained there. This would be similar 
to the voucher request, in which the registrar-voucher-request also contains 
the certificate chain according to section 5.5.2 
(https://www.rfc-editor.org/rfc/rfc8995.html#section-5.5.2), which states:
"A certificate chain is extracted from the registrar's signed CMS container. "

I would propose to also allow the submission of the certificate chain of the 
MASA signing certificate in the SignedData part of the CMS container of the 
voucher.
Any thoughts?

Best regards
Steffen
--
Steffen Fries



___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

[Anima] RFC 8995, Voucher Signing, MASA Certificate Chain provisioning

[Fries, Steffen]

Hi Michael,

I've got a question regarding the MASA voucher signing or better the 
certificate chain provisioning for the MASA certificate to the pledge.

RFC 8995 states in section 91.1. 
(https://www.rfc-editor.org/rfc/rfc8995.html#section-9.1.1)
"The online service MUST have access to a private key with which to sign 
voucher artifacts 
[RFC8366]. The public key, 
certificate, or certificate chain MUST be built into the device as part of the 
firmware."

I had the assumption that the pledge only knows its IDevID and with that his 
own certificate, public/private key pair and the certificate chain from the 
issuing CA to the trust anchor.
In operational environments the issuing CA for the IDevID may not be the same 
as the issuing CA for the MASA signing certificate. From the requirement above, 
it would mean to provide the MASA certificate chain also in the pledge 
firmware, if it is different than the IDevID issuing CA. As the voucher is a 
CMS container that allows to convey the certificate chain of the signer in the 
SignedData, I would have expected it is contained there. This would be similar 
to the voucher request, in which the registrar-voucher-request also contains 
the certificate chain according to section 5.5.2 
(https://www.rfc-editor.org/rfc/rfc8995.html#section-5.5.2), which states:
"A certificate chain is extracted from the registrar's signed CMS container. "

I would propose to also allow the submission of the certificate chain of the 
MASA signing certificate in the SignedData part of the CMS container of the 
voucher.
Any thoughts?

Best regards
Steffen
--
Steffen Fries



___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

[Anima] FW: New Version Notification for draft-ietf-anima-brski-prm-12.txt

[Fries, Steffen]

Hello all,

We just submitted an update of BRSKI-PRM.
It includes the Shepherd review part 2 comment resolution.

There will be a part 3 of the review, addressing the remaining parts of the 
document.

Best regards
Steffen

-Original Message-
From: internet-dra...@ietf.org 
Sent: Monday, March 4, 2024 9:49 PM
To: Michael C. Richardson ; Eliot Lear ; 
Michael Richardson ; Fries, Steffen (T CST) 
; Werner, Thomas (T CST SEA-DE) 

Subject: New Version Notification for draft-ietf-anima-brski-prm-12.txt

A new version of Internet-Draft draft-ietf-anima-brski-prm-12.txt has been 
successfully submitted by Steffen Fries and posted to the IETF repository.

Name: draft-ietf-anima-brski-prm
Revision: 12
Title:BRSKI with Pledge in Responder Mode (BRSKI-PRM)
Date: 2024-03-04
Group:anima
Pages:105
URL:  https://www.ietf.org/archive/id/draft-ietf-anima-brski-prm-12.txt
Status:   https://datatracker.ietf.org/doc/draft-ietf-anima-brski-prm/
HTMLized: https://datatracker.ietf.org/doc/html/draft-ietf-anima-brski-prm
Diff: 
https://author-tools.ietf.org/iddiff?url2=draft-ietf-anima-brski-prm-12

Abstract:

   This document defines enhancements to Bootstrapping a Remote Secure
   Key Infrastructure (BRSKI, RFC8995) to enable bootstrapping in
   domains featuring no or only limited connectivity between a pledge
   and the domain registrar.  It specifically changes the interaction
   model from a pledge-initiated mode, as used in BRSKI, to a pledge-
   responding mode, where the pledge is in server role.  For this, BRSKI
   with Pledge in Responder Mode (BRSKI-PRM) introduces a new component,
   the Registrar-Agent, which facilitates the communication between
   pledge and registrar during the bootstrapping phase.  To establish
   the trust relation between pledge and registrar, BRSKI-PRM relies on
   object security rather than transport security.  The approach defined
   here is agnostic to the enrollment protocol that connects the domain
   registrar to the domain CA.



The IETF Secretariat


___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Adoption call on draft-eckert-anima-brski-discovery-01 by 2024/2/23rd

[Fries, Steffen]

Hi Sheng, Toerless,

I'm happy that we took discovery as single topic out of the related drafts to 
address it once and use it in the different other drafts you listed. 
That said yes, I think it addresses a valid problem and is needed. 

Bet regards
Steffen

> -Original Message-
> From: Anima  On Behalf Of Sheng JIANG
> Sent: Friday, February 9, 2024 9:29 AM
> To: anima 
> Cc: anima-chairs ; rwilton 
> Subject: [Anima] Adoption call on draft-eckert-anima-brski-discovery-01 by
> 2024/2/23rd
> 
> Hi, ANIMAers,
> 
> This email starts a two-week adoption call on draft-eckert-anima-brski-
> discovery-01. It ends by 2024/2/23rd.
> 
> This draft is not new as normal -01 individual draft. It is coalesced from the
> discovery options parts of several ANIMA WG documents:
> 
> draft-ietf-anima-brski-prm
> draft-ietf-anima-brski-ae
> draft-ietf-anima-brski-constrained-voucher
> draft-ietf-anima-brski-constrained-proxy
> 
> 
> It has been introduced and discussed during the Prague meeting. Hence, the
> ANIMA chairs think it has a reasonable good foundation for adoption. Please
> express your opinions on whether this document is meaningful for our ANIMA
> WG by the ending time 2024/2/23rd. The writing quality of this document is a
> late consideration after WG adoption.
> 
> Regards,
> 
> 
> Sheng JIANG
> 
> 
> ___
> Anima mailing list
> Anima@ietf.org
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> .ietf.org%2Fmailman%2Flistinfo%2Fanima=05%7C02%7Csteffen.fries%
> 40siemens.com%7C4c8a383ffd924c5dc71908dc2949352d%7C38ae3bcd95
> 794fd4addab42e1495d55a%7C1%7C0%7C638430641603141748%7CUnkn
> own%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik
> 1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=TCfrjDrg%2FMTT5NFV
> bMEGTsq6jO1TBDK0IUOic44cwMc%3D=0

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] ANIMA@IETF119 - call for agenda items

[Fries, Steffen]

Hi Toerless,

Here is the list of potential presentations on status updates of WG documents. 
Note that none of the drafts (so far) had substantial changes beyond 
clarifications resulting from comments. If that holds until the meeting, we may 
also report the status based on the chair slides. 
Nevertheless, here the list:

Topic/Title   Update on BRSKI-AE

  
Name of Presenter(s)David von Oheimb
 
Length of time requested 5min
name of draft(s) discussed   draft-ietf-anima-brski-ae-09
Local/remote  remote

Topic/Title   Update on JWS-Voucher 

 
Name of Presenter(s)Thomas Werner (Steffen Fries)   
  
Length of time requested 5min
name of draft(s) discussed   draft-ietf-anima-jws-voucher-09
Local/remote  remote

Topic/Title   Update on BRSKI-PRM   

   
Name of Presenter(s)Steffen Fries   
  
Length of time requested 5min
name of draft(s) discussed   draft-ietf-anima-brski-prm-11
Local/remote  remote

Best regards
Steffen

> -Original Message-
> From: Anima  On Behalf Of Toerless Eckert
> Sent: Friday, February 2, 2024 4:18 AM
> To: anima@ietf.org
> Cc: anima-cha...@ietf.org; rwil...@cisco.com
> Subject: [Anima] ANIMA@IETF119 - call for agenda items
> 
> Dear ANIMA-WG
> 
> We have just put in a request for a 1-hour slot to meet in Brisbane, IETF119.
> Given how we will likely not have all contributors locally, we try to ensure 
> that
> the meeting is in the afternoon to make remote attendance from Europe as
> little terrible as possible.
> 
> We are also pondering if we should do an interim after Brisbane, but i think 
> it
> may be useful to decide on the timing by the end of Brisbane.
> 
> So, for Brisbane, pls. provide  the usual agenda item request info to anima-
> cha...@ietf.org or anima@ietf.org in reply to this email .
> 
> Topic/Title
> Name of Presenter(s)
> Length of time requested
> If applicable: name of draft(s) discussed
> Local/remote.
> 
> Thanks
> Toerless on behalf of the chairs
> 
> In-Reply-To:
> <170684244040.8474.7119428583314086...@ietfa.amsl.com>
> 
> On Thu, Feb 01, 2024 at 06:54:00PM -0800, IETF Meeting Session Request
> Tool wrote:
> >
> >
> > A new meeting session request has just been submitted by Toerless
> > Eckert, a Chair of the ANIMA Working Group.
> >
> >
> > -
> > Working Group Name: Autonomic Networking Integrated Model and
> Approach
> > Area Name: Operations and Management Area Session Requester: Toerless
> > Eckert
> >
> >
> > Number of Sessions: 1
> > Length of Session(s): 1 Hour
> > Number of Attendees: 30
> > Conflicts to Avoid:
> >  Chair conflict: detnet bier 6man intarea pim iabopen  Technology
> > overlap: netconf  Key participant conflict: opsarea intarea
> >
> >
> >  Can't meet: Monday morning, Tuesday morning, Wednesday morning,
> > Thursday morning, Friday morning
> >
> > Participants who must be present:
> >   Michael Richardson
> >
> > Resources Requested:
> >
> > Special Requests:
> >   Key speakers will be remote from Europe time zone, hence i tried to
> accommodate them by locking out the morning sessions.
> > -
> >
> >
> 
> --
> ---
> t...@cs.fau.de
> 
> ___
> Anima mailing list
> Anima@ietf.org
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> .ietf.org%2Fmailman%2Flistinfo%2Fanima=05%7C02%7Csteffen.fries%
> 40siemens.com%7C1db68e0b0a604161be6c08dc239da49f%7C38ae3bcd95
> 794fd4addab42e1495d55a%7C1%7C0%7C638424407180239413%7CUnkn
> own%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik
> 1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=65mcRKpDych8W0MP
> 79U04SUCKH274EmxfD3SEsGnDEU%3D=0

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

[Anima] FW: New Version Notification for draft-ietf-anima-brski-prm-11.txt

[Fries, Steffen]

Hi,

We just uploaded an update of BRSKI-PRM. The changes address the remaining open 
issues from WGLC and also the result of further discussions in the design team 
meetings as well as the second early review of the SECDIR. Based on the latest 
changes all of the issues collected on github 
(https://github.com/anima-wg/anima-brski-prm/issues) could be closed.
Stating that, the current version is ready for the Shepherd's review, which was 
announced as next step in the process during IETF 118.

Some summary on the changes done:
- issue #79, clarified that BRSKI discovery in the context of BRSKI-PRM is not 
needed in Section 5.6.1.
- issue #103, removed step 6 in verification handling for the wrapped CA 
certificate provisioning as only applicable after enrollment Section 6.3.3
- issue #128: included notation of nomadic operation of the Registrar-Agent in 
Section 5, including proposed text from PR #131
- issue #130, introduced DNS service discovery name for brski_pledge to enable 
discovery by the Registrar-Agent in Section 8
- removed unused reference RFC 5280
- removed site terminology
- deleted duplicated text in Section 5.5
- clarified registrar discovery and relation to BRSKI-Discovery in Section 5.6.1
- clarified discovery of pledges by the Registrar-Agent in Section 5.6.2, 
deleted reference to GRASP as handled in BRSKI-Discovery
- addressed comments from SECDIR early review

Thank you for the discussion.

Best regards
Steffen

-Original Message-
From: internet-dra...@ietf.org 
Sent: Monday, November 20, 2023 5:39 PM
To: Michael C. Richardson ; Eliot Lear ; 
Michael Richardson ; Fries, Steffen (T CST) 
; Werner, Thomas (T CST SEA-DE) 

Subject: New Version Notification for draft-ietf-anima-brski-prm-11.txt

A new version of Internet-Draft draft-ietf-anima-brski-prm-11.txt has been 
successfully submitted by Steffen Fries and posted to the IETF repository.

Name: draft-ietf-anima-brski-prm
Revision: 11
Title:BRSKI with Pledge in Responder Mode (BRSKI-PRM)
Date: 2023-11-20
Group:anima
Pages:99
URL:  https://www.ietf.org/archive/id/draft-ietf-anima-brski-prm-11.txt
Status:   https://datatracker.ietf.org/doc/draft-ietf-anima-brski-prm/
HTMLized: https://datatracker.ietf.org/doc/html/draft-ietf-anima-brski-prm
Diff: 
https://author-tools.ietf.org/iddiff?url2=draft-ietf-anima-brski-prm-11

Abstract:

   This document defines enhancements to Bootstrapping a Remote Secure
   Key Infrastructure (BRSKI, RFC8995) to enable bootstrapping in
   domains featuring no or only limited connectivity between a pledge
   and the domain registrar.  It specifically changes the interaction
   model from a pledge-initiated mode, as used in BRSKI, to a pledge-
   responding mode, where the pledge is in server role.  For this, BRSKI
   with Pledge in Responder Mode (BRSKI-PRM) introduces a new component,
   the Registrar-Agent, which facilitates the communication between
   pledge and registrar during the bootstrapping phase.  To establish
   the trust relation between pledge and registrar, BRSKI-PRM relies on
   object security rather than transport security.  The approach defined
   here is agnostic to the enrollment protocol that connects the domain
   registrar to the domain CA.



The IETF Secretariat


___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] summary of design team meeting, 2023-10-24

[Fries, Steffen]

Hi Michael,

Thank you for the minutes. Very good to keep track of the discussion.

Some of the issues discussed yesterday have been addressed by comments and 
commits already. 

Best regards
Steffen

> -Original Message-
> From: Anima  On Behalf Of Michael Richardson
> Sent: Dienstag, 24. Oktober 2023 18:16
> To: anima@ietf.org
> Subject: [Anima] summary of design team meeting, 2023-10-24
> 
> 
> To help with the WG keeping abreast of issues resolved by the (BRSKI) design
> team, we will post a summary of issues worked on during the Tuesday
> meetings.
> To remind everyone is welcome to join the design team meetings which are
> most
> Tuesdays at 11am Eastern at whereby.com/sandelman.   There are calendar
> invites in the archives.
> There will be design team meeting on Oct.31 or Nov. 7.
> We will resume on Nov.14, and I will resend an invite for that date.
> 
> Who: Toerless, Michael, Steffen, Thomas, Matthias, Marco Calipari.
> 
> 1.
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu
> b.com%2Fanima-wg%2Fanima-brski-
> prm%2Fissues%2F79=05%7C01%7Csteffen.fries%40siemens.com%7Cc
> 5188f121eb543ba384408dbd4acb27d%7C38ae3bcd95794fd4addab42e14
> 95d55a%7C1%7C0%7C638337610431515641%7CUnknown%7CTWFpbGZs
> b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6M
> n0%3D%7C3000%7C%7C%7C=GV5HdCuWwIwVJB65lZ3a1BkPQG7O
> AJeS%2BRLravetSNE%3D=0
> discovery of registrar with BRSKI-PRM function set
> 
> (one realization is that there will be Registrar/Registrar-Agent
> communication/configuration which likely will go beyond the standards we
> are defining.  We have no experience here, and there will need to be
> experiments with running code before we can have standardization here.
> i.e. a Registrar and Registrar-Agent are part of a single product offering)
> 
> 2.
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu
> b.com%2Fanima-wg%2Fanima-brski-
> prm%2Fissues%2F106=05%7C01%7Csteffen.fries%40siemens.com%7C
> c5188f121eb543ba384408dbd4acb27d%7C38ae3bcd95794fd4addab42e14
> 95d55a%7C1%7C0%7C638337610431515641%7CUnknown%7CTWFpbGZs
> b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6M
> n0%3D%7C3000%7C%7C%7C=6uUvd9qNNYFcNSNDeRW3R7oQJjdT
> %2BHvjAyEfoxZ8Pug%3D=0
> "registrar-agent signatures" check consistent use closed with text in section
> 6.3.6
> 
> 3.
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu
> b.com%2Fanima-wg%2Fanima-brski-
> prm%2Fissues%2F116=05%7C01%7Csteffen.fries%40siemens.com%7C
> c5188f121eb543ba384408dbd4acb27d%7C38ae3bcd95794fd4addab42e14
> 95d55a%7C1%7C0%7C638337610431515641%7CUnknown%7CTWFpbGZs
> b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6M
> n0%3D%7C3000%7C%7C%7C=%2FDxO3syvCVBgtwSGPS8ujI5nNWH
> Xn0aXR4EXxjTmg%2F0%3D=0
> Security Considerations - nonce explanation closed, everyone happy with text
> 
> 4.
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu
> b.com%2Fanima-wg%2Fanima-brski-
> prm%2Fissues%2F117=05%7C01%7Csteffen.fries%40siemens.com%7C
> c5188f121eb543ba384408dbd4acb27d%7C38ae3bcd95794fd4addab42e14
> 95d55a%7C1%7C0%7C638337610431671874%7CUnknown%7CTWFpbGZs
> b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6M
> n0%3D%7C3000%7C%7C%7C=r%2BuBHhUV%2B6VYT1uUbJpcDDdA
> VFslRumPZyUAVgM%2FH6g%3D=0
> Security Considerations - Misuse of Registrar-Agent Credentials nothing
> changed in the text, agreed that description was good enough.
> issue closed.
> 
> 5.
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu
> b.com%2Fanima-wg%2Fanima-brski-
> prm%2Fissues%2F128=05%7C01%7Csteffen.fries%40siemens.com%7C
> c5188f121eb543ba384408dbd4acb27d%7C38ae3bcd95794fd4addab42e14
> 95d55a%7C1%7C0%7C638337610431671874%7CUnknown%7CTWFpbGZs
> b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6M
> n0%3D%7C3000%7C%7C%7C=nyNgOBxIKHcTXRwVMBeSOVUUhZTya
> vKI5DvlkqBVSuc%3D=0
> "domain/site" terminology definition and consistent usage We had a long
> discussion about whether or not the term "site" needs to be go into the
> document.  Does it mean the same as "domain" or not?
> It has been in slides, and often was used to refer to the multiple 
> "downstairs"
> sites.  We also discussed that "site" is a place where multicast DNS works
> (which is kinda of standing the defintion on its head) We think we will remove
> all references to site, and try to emphasize the nomadic connectivity of the
> Registrar-Agent using some new term.
> 
> 6.
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu
> b.com%2Fanima-wg%2Fanima-brski-
> prm%2Fissues%2F129=05%7C01%7Csteffen.fries%40siemens.com%7C
> c5188f121eb543ba384408dbd4acb27d%7C38ae3bcd95794fd4addab42e14
> 95d55a%7C1%7C0%7C638337610431671874%7CUnknown%7CTWFpbGZs
> b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6M
> n0%3D%7C3000%7C%7C%7C=eR042VimBcUpglKKFRZR2TtiXCreK%2F
> i6r9I%2FnuXkGHo%3D=0
> Need to add IANA registration for brski-pledge 

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

[Fries, Steffen]

Hello,

We just updated uploaded BRSKI-PRM (draft-ietf-anima-brski-prm-10.txt) with the 
following changes from IETF draft 09 -> IETF draft 10:
*  issue #79, clarified discovery in the context of BRSKI-PRM and included 
information about future discovery enhancements in a separate draft in Section 
5.3.1.
*  issue #93, included information about conflict resolution in mDNS and GRASP 
in Section 5.3.2
*  issue #103, included verification handling for the wrapped CA certificate 
provisioning in Section 6.3.3
*  issue #106, included additional text to elaborate more the registrar status 
handling in Section 6.3.6
*  issue #116, enhanced DoS description in Section 10.1
*  issue #120, included statement regarding pledge host header processing in 
Section 5.2
*  issue #122, availability of serial number information on registrar agent 
clarified in Section 6.1
*  issue #123, Clarified usage of alternative voucher formats in Section 6.2.3
*  issue #124, determination of pinned domain certificate done as in RFC 8995 
included in Section 6.2.4
*  issue #125, remove strength comparison of voucher assertions in Section 5.1 
and Section 6
*  issue #130, aligned the usage of site and domain throughout the document
*  changed naming of registrar certificate from LDevID(RegAgt) to EE (RegAgt) 
certificate throughout the document
*  change x5b to x5bag according to [RFC9360]
*  updated JSON examples -> "signature": BASE64URL(JWS Signature)

We will present discussions during IETF 118 in the ANIMA session

Best regards
Steffen


-Original Message-
From: Anima  On Behalf Of internet-dra...@ietf.org
Sent: Montag, 23. Oktober 2023 16:31
To: i-d-annou...@ietf.org
Cc: anima@ietf.org
Subject: [Anima] I-D Action: draft-ietf-anima-brski-prm-10.txt

Internet-Draft draft-ietf-anima-brski-prm-10.txt is now available. It is a work 
item of the Autonomic Networking Integrated Model and Approach (ANIMA) WG of 
the IETF.

   Title:   BRSKI with Pledge in Responder Mode (BRSKI-PRM)
   Authors: Steffen Fries
Thomas Werner
Eliot Lear
Michael C. Richardson
   Name:draft-ietf-anima-brski-prm-10.txt
   Pages:   95
   Dates:   2023-10-23

Abstract:

   This document defines enhancements to Bootstrapping a Remote Secure
   Key Infrastructure (BRSKI, RFC8995) to enable bootstrapping in
   domains featuring no or only limited connectivity between a pledge
   and the domain registrar.  It specifically changes the interaction
   model from a pledge-initiated mode, as used in BRSKI, to a pledge-
   responding mode, where the pledge is in server role.  For this, BRSKI
   with Pledge in Responder Mode (BRSKI-PRM) introduces a new component,
   the registrar-agent, which facilitates the communication between
   pledge and registrar during the bootstrapping phase.  To establish
   the trust relation between pledge and registrar, BRSKI-PRM relies on
   object security rather than transport security.  The approach defined
   here is agnostic to the enrollment protocol that connects the domain
   registrar to the domain CA.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-anima-brski-prm/

There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-anima-brski-prm-10

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-anima-brski-prm-10

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

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

[Fries, Steffen]

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) discussed: draft-ietf-anima-brski-ae-06 
(version 06 to be submitted) 

Topic/TitleJWS-voucher Status Update
Name of Presenter(s)Thomas Werner/ Steffen Fries
Length of time requested  5 min
If applicable: name of draft(s) discussed: draft-ietf-anima-jws-voucher-09

Topic/TitleBRSKI-PRM Status Update
Name of Presenter(s) Steffen Fries
Length of time requested  10 min
If applicable: name of draft(s) discussed: draft-ietf-anima-brski-prm-10 
(version 10 to be submitted)

Best regards
Steffen

> -Original Message-
> From: Anima  On Behalf Of Toerless Eckert
> Sent: Thursday, September 14, 2023 1:12 AM
> To: anima@ietf.org
> Cc: anima-cha...@ietf.org; rwil...@cisco.com
> Subject: [Anima] Initial Call for agenda discussion / items ANIMA@IETF118
> Prague (was: anima - New Meeting Session Request for IETF 118)
> 
> Dear ANIMA WG,
> 
> This time, we wanted to ask for agenda items for ANIMA@IETF118 early
> enough that we can accordingly ask for a fitting slot length. The window for
> requesting WG slots closes on 09-22 23:59 UTC.
> 
> For now, we have requested a one hour slot based on feedback from our AD
> and others who ae trying to ensure that IETF in-person meeting time is spent
> mostly on discussions that can only be had in-person, especially given the 
> ever
> growing number of WGs.
> 
> Given how we are making good working progress with most our adopted
> BRSKI WG items on our weekly online meetings (to the extend they are not on
> back-burner because of serialization/dependencies), we think for those WG
> items one hour will suffice at IETF118, so that is the current request.
> 
> If you have additional work you would like to see discussed, please start
> discuss it on the list, so that we can consider extending the WG meeting time
> request for
> IETF118 as then needed.
> 
> Cheers
>   Toerless - for the chairs
> 
> On Wed, Sep 13, 2023 at 04:05:47PM -0700, IETF Meeting Session Request
> Tool wrote:
> >
> >
> > A new meeting session request has just been submitted by Toerless
> > Eckert, a Chair of the ANIMA Working Group.
> >
> >
> > -
> > Working Group Name: Autonomic Networking Integrated Model and
> Approach
> > Area Name: Operations and Management Area Session Requester: Toerless
> > Eckert
> >
> >
> > Number of Sessions: 1
> > Length of Session(s): 1 Hour
> > Number of Attendees: 40
> > Conflicts to Avoid:
> >  Chair conflict: detnet bier 6man intarea pim v6ops iabopen
> > Technology overlap: emu netconf mboned  Key participant conflict: nmrg
> > opsarea intarea saag
> >
> >
> >
> >
> > Participants who must be present:
> >   Michael Richardson
> >
> > Resources Requested:
> >
> > Special Requests:
> >   China remote attendance friendly time would be lovely (the earlier
> > in the day, the better). One co-chair likely attending remotely
> > -
> >
> 
> --
> ---
> t...@cs.fau.de
> 
> ___
> Anima mailing list
> Anima@ietf.org
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> .ietf.org%2Fmailman%2Flistinfo%2Fanima=05%7C01%7Csteffen.fries%
> 40siemens.com%7C610b34f12fc2405a350308dbb4aed160%7C38ae3bcd95
> 794fd4addab42e1495d55a%7C1%7C0%7C638302435211613955%7CUnkn
> own%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik
> 1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=gE1niRS8cT4rdaPL
> m3lLRiEt7RDmJjZGqb6hvG0yYEw%3D=0

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] BRSKI-AE text proposal: how to signal to a pledge which BRSKI variant(s) with which parameter(s) a registrar supports

[Fries, Steffen]

t; ae=05%7C01%7Csteffen.fries%40
> > >
> siemens.com%7Cd0d214aa621a478d08dbaf424411%7C38ae3bcd957
> 94fd4add
> > >
> ab42e1495d55a%7C1%7C0%7C638296471381705308%7CUnknown%7CT
> WFpbGZsb3d8e
> > >
> yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
> D%7C
> > >
> 3000%7C%7C%7C=WpInfwc%2BquC8CMyGy1KzTCcVebMFyN6BzoSX
> zPPTCmw%3D
> > > =0
> > >
> > > The change log so far is:
> > >
> > >   * Remove entries from the terminology section that should be clear
> > > from BRSKI
> > >   * Tweak use of the terms IDevID and LDevID and replace PKI RA/CA by
> > > RA/CA
> > >   * Add the abbreviation 'LwCMP' for Lightweight CMP to the
> > > terminology section
> > >   * State clearly in Section 5.1 that LwCMP is mandatory when using CMP
> > >   * Change URL of BRSKI-AE-overview graphics to slide on IETF 116
> > > meeting material
> > >
> > >
> > > The first two items were suggested internally by Steffen, while the
> > > remaining ones address the below points by Toerless and Brian.
> > >
> > > Regarding the reference to EST, the authors discussed this and came
> > > to the conclusion that we better keep the reference to EST [RFC
> > > 7030] as /informative/ because we do not really depend on its
> > > contents since the EST instance of BRSKI-AE has effectively been
> > > removed from the draft (and just remain as a theoretical option).
> > > The only "feature" that stems from EST that we take over in
> > > BRSKI-AE, namely the endpoint naming scheme, is already covered by
> > > the reference to BRSKI [RFC 8995], such that having BRSKI as a
> > > /normative/ reference fully covers this.
> > > OTOH, the references to CMP are clearly /normative/ for the case
> > > that BRSKI-AE is instantiated to CMP, which we have made more
> > > explicit in the upcoming version as stated in the above change log.
> > >
> > > Thus we believe that we have covered all open points, and since the
> > > IPR poll has been finished as well, the draft would be ready for
> > > being submitted and for AD review,
> > > but:
> > >
> > > On Thu, 2023-04-27 at 11:02 +, Fries, Steffen wrote:
> > > To: anima@ietf.org 
> > > Subject: [Anima] Design Team Meeting discussion (April 25) on
> > > BRSKI-PRM discovery with cross relation to BRSKI-AE
> > >
> > > > Independent of the final solution picked, as BRSKI-AE is also
> > > > enhancing the functionality of a BRSKI registrar by supporting
> > > > alternative enrollment protocols, the same approach is to be
> > > > intended for BRSKI-AE as well. Therefore, we will wait with the
> > > > submission of an updated BRSKI-AE draft until the discussion has
> > > > ended.
> > >
> > > So we are holding back the draft until this has been sorted out,
> > > most likely resulting in a small paragraph to be added to BRSKI-AE.
> > >
> > > If there is any further comment or suggestion for improval, please
> > > let us (the authors) know.
> > >
> > > Best,
> > > David
> > >
> 
> --
> ---
> t...@cs.fau.de

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Use of problem details in BRSKI (and other ANIMA) documents (rfc9457)

[Fries, Steffen]

Hi Toerless,

Providing errors with more detailed information is certainly helpful. My gut 
feeling would be to have this as SHOULD and not as MUST. Reasoning is that for 
instance in BRSKI-PRM, we have different error codes for different states in 
the verification as discussed in the design Team meetings (see 
https://github.com/anima-wg/anima-brski-prm/issues/103). This allows to easily 
deduce in which state the pledge currently is and allows appropriate reaction 
in that specific state. Having more detailed information may lead to a more 
specific handling in that state. Based that the current approach allows for 
proper reaction, I would consider it as optional.

Best regards
Steffen

> -Original Message-
> From: Toerless Eckert 
> Sent: Wednesday, September 6, 2023 8:31 PM
> To: anima@ietf.org
> Cc: draft-ietf-anima-brski-...@ietf.org
> Subject: Use of problem details in BRSKI (and other ANIMA) documents (rfc9457)
>
> Dear ANIMA-WG
>
> In the weekly BRSKI  calls we did discuss on and off the issue of limited 
> HTTP error
> codes returned when calling BRSKI endpoint URIs. Especially the point that 
> it's
> difficult to map all error conditions to unique HTTP status codes.
>
> So, i would hereby like to suggest that we revisit error codes returned by new
> BRSKI work to follow what the IETF has specified and follow what seems to be
> like a very simple way to apply that method, as found in ACME (which is kinda
> related to our BRSKI work).
>
> -- Reference:
>
> RFC7807 defines how to signal problem details for HTTP APIs. It was 
> superceeded
> by RFC9457, but of course, there are more RFC already using/referencing
> RFC7807 than RFC9457.
>
> --- Simple example:
>
> ACME, RFC9115 seems like a good, minimum complexity way to apply this
> problem report method. It specifies for example:
>
>... MUST return an error response with status code 403
>(Forbidden), providing a problem document [RFC7807] with type
>"urn:ietf:params:acme:error:unknownDelegation".
>
> And then there is an IANA section asking to register this "unknownDelegation".
> Aka: minimum text work.
>
> --- Longer example reference:
>
> Of course, one of our RFC, maybe rfc8366bis needs to ask for creation of a 
> registry
> for "urn:ietf:params:brski", and the error registry, but that's easily 
> written,
> especially when it follows the ACME approach.
>
> RFC8555 , the main  ACME does of course introduce a long list of error codes,
> They can also all be found in the registry:
>
> https://www.iana/.
> org%2Fassignments%2Facme%2Facme.xhtml%23acme-error-
> types=05%7C01%7Csteffen.fries%40siemens.com%7C96d0c9691fa94b1c6
> 62e08dbaf0779f0%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638
> 296218869389810%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ
> QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=
> aFb8goeUiPdCq2xCiZ5bRJPiZhtzmu6ws4jGuGUczBk%3D=0
>
> --- Example of how to apply:
>
> Lets take an example with BRSKI-PRM, which currently specifies:
>
>   400 Bad Request: if the pledge detected an error in the format
>   of the request or detected invalid JSON even though the PER media type was 
> set
> to application/json.
>
> Instead of just returning 400, we could change this to MUST/SHOULD also
> indicate an appropriate problem report.
>
> --- How to apply to BRSKI:
>
> Technically, the eror transaction would look like this
>
> GET /.well-known/brski/tpvr HTTP/1.1
> Host: brski-registrar.example.com
> Content-Type: application/json
> Accept: application/json, application/problem+json {
>   ... existing BRSKI PRM PVR data
> }
>
> Aka: in the request, the initiator would indicate that it supports 
> problem+json
>
> HTTP/1.1 400 Bad Request
> Content-Type: application/problem+json
> Content-Language: en
>
> {
>  "type": "urn:ietf:params:brski:error:ErrorNameNNN",
>  "title": "...",
>  "detail": "...",
>  "blablabla": "...",
> }
>
> In the reply, we would be able to have a combination of specific ErrorNameNNN
> and other fields.
>
> I think the logic of applying ErrorNameNNN and the other fields would be based
> on the following considerations:
>
> Whenever an initiator should or could have two different reactions to two
> different errors, such as different retries, then there MUST be two different
> ErrorNameNNN. Aka: automated reactions must be possible by only examining
> the ErrorNameNNN.
>
> Whenever it is easy to distinguish two different Errors by name, then we 
> should
> also introduce those different ErrorNameNNN. The list of ACME error codes
> might be a good help.
>
> Whenever there must be a human in the loop anyhow to resolve the issue, it is
> sufficient to describe the problem differences in the "detail" and 
> potentially other
> fields, which can be custom, such as indicated via "blablabla".
>
> So, for the example of this "Bad Request", the problem of course is that some
> plege or agent developer (or even worse customer/operator) needs to figure out
> what the registrar did not like.
>
> 

Re: [Anima] title for join proxy document

[Fries, Steffen]

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 understand the other two more in 
the direction of "reduced functionality" either of the network or the 
bootstrapping protocol itself.

A further alternative may be _Join Proxy for Bootstrapping of Constrained 
Network Elements_

Best regards
Steffen

> -Original Message-
> From: Anima  On Behalf Of Esko Dijk
> Sent: Tuesday, September 5, 2023 2:08 PM
> To: Michael Richardson ; anima@ietf.org
> Subject: Re: [Anima] title for join proxy document
>
> I typically assumed the Pledge/joiner would be a constrained device, and also 
> the
> Join Proxy would be a constrained device: in a mesh situation typically a 
> Joiner
> that just successfully joined starts to operate as Join Proxy for any future 
> Pledges.
> And these devices would operate in a constrained network.
>
> Here some potential titles to reflect that:
>
> _ Join Proxy for Bootstrapping Protocols in Constrained Networks_
>
> _ Join Proxy for Constrained-Network Bootstrapping Protocols _
>
> _ Join Proxy for Lightweight Bootstrapping Protocols _
>
>
> These titles do not make a claim about whether the Join Proxy itself is a
> constrained device, or not. That could be said in the intro, that it *could* 
> be a
> constrained device.
>
> Esko
>
> -Original Message-
> From: Anima  On Behalf Of Michael Richardson
> Sent: Monday, September 4, 2023 19:22
> To: anima@ietf.org
> Subject: [Anima] title for join proxy document
>
>
> Russ points out that the title is a slightly mis-leading.
> https://github.co/
> m%2Fanima-wg%2Fconstrained-join-
> proxy%2Fissues%2F51=05%7C01%7Csteffen.fries%40siemens.com%7C487
> 6268a6fc84d0d75b008dbae08bb1a%7C38ae3bcd95794fd4addab42e1495d55a%
> 7C1%7C0%7C638295124751198185%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM
> C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7
> C%7C%7C=VF3luW2aud0xbKTZVNGDTyaENEY0BM9%2BnYOicyegWUU%
> 3D=0
>
> The document is titled:
> _Constrained Join Proxy for Bootstrapping Protocols_
>
>   --- abstract
>   This document extends the work of Bootstrapping Remote Secure Key
>   Infrastructures (BRSKI) by replacing the Circuit-proxy between
>   Pledge and Registrar by a stateless/stateful constrained Join
>   Proxy. The constrained Join Proxy is a mesh neighbor of the
>   Pledge and can relay a DTLS session originating from a Pledge with only 
> link-local
>   addresses to a Registrar which is not a mesh neighbor of the
>   Pledge.
>
>   This document defines a protocol to securely assign a Pledge to a domain,
>   represented by a Registrar, using an intermediary node between Pledge and
>   Registrar. This intermediary node is known as a "constrained Join
>   Proxy". An enrolled Pledge can act as a constrained Join Proxy.
>
> {paragraph two is most definitely wrong, but paragraph one is absolutely 
> correct}
>
> Russ is wrong in thinking that the join proxy machine is not constrained; it 
> may
> well be, and that's why we want to reduce/eliminate state if possible.
> (Or rather, move it into the network and into the Registrar)
>
> However, I stubbed my toe on the title while trying to fix things.
>
> It is the (Constrained Join) Proxy for Bootstrapping Protocols.
> Not, the:  (Constrained Join Proxy) for Bootstrapping Protocols_
>
> I thought about instead:
>   Stateless Join Proxy for Constrained Bootstrapping Protocols
>
> Or even s/Bootstrapping/Onboarding/
> but, actually we document both State and Stateless mechanisms.
>
> Please help me fix the title and from that, the abstract.
>
> --
> Michael Richardson. o O ( IPv6 IøT consulting )
>Sandelman Software Works Inc, Ottawa and Worldwide
>
>
>
>
> ___
> Anima mailing list
> Anima@ietf.org
> https://www.ietf/.
> org%2Fmailman%2Flistinfo%2Fanima=05%7C01%7Csteffen.fries%40sieme
> ns.com%7C4876268a6fc84d0d75b008dbae08bb1a%7C38ae3bcd95794fd4addab
> 42e1495d55a%7C1%7C0%7C638295124751198185%7CUnknown%7CTWFpbGZs
> b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%
> 3D%7C3000%7C%7C%7C=EJySSvA%2BRpV0PxJwke%2BynJD8rpklLYswDd
> 6szPITpG8%3D=0

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] New Version of draft-eckert-anima-grasp-dnssd

[Fries, Steffen]

Hi Brian,

There is ongoing work in the ANIMA design team about the extension of the 
discovery information for a registrar, to contain more information about 
specific features of the registrar. We currently identified:
- the operational mode: registrar as responder (as in RFC 8995) or pledge as 
responder (as in BRSKI-PRM)
- the enrollment protocol: EST as in RFC 8995) or CMP (as in BRSIK-AE) or 
future adaptations
- the voucher format: CMS-signed JSON (as in RFC 8995) or JOSE-signed JSON (as 
in JWS-Voucher used in BRSKI-PRM

The discussion is to define TXT key value pairs for DNS-SD, and use this 
approach also for GRASP.

Best regards
Steffen

> -Original Message-
> From: Michael Richardson 
> Sent: Monday, July 17, 2023 11:47 PM
> To: Brian E Carpenter 
> Cc: Fries, Steffen (T CST) ; anima@ietf.org
> Subject: Re: [Anima] New Version of draft-eckert-anima-grasp-dnssd
> 
> 
> Brian E Carpenter  wrote:
> > I can't answer that, but note that the AN_Proxy and AN_join_registrar
> > GRASP objectives defined in RFC 8995 include an objective-value field.
> > For AN_Proxy that field is "any" so is currently undefined and could be
> > extended in any way we want. For AN_join_registrar it is defined as
> 
> In hindsight, 8995 should have created an IANA registry for these.
> 
> > I find that "(list of)" a bit unclear but again there is flexibility to
> > extend the semantics as we want. In fact that "(list of)" is almost
> > worth an errata, since I wouldn't know what to write in a program to
> > implement it.
> 
> :-)
> 
> --
> Michael Richardson. o O ( IPv6 IøT consulting )
>Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
> 

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] BRSKI-CLE: A Certificateless Enrollment protocol in BRSKI

[Fries, Steffen]

Hi Lei Yan,

I'm just using your latest response as I had similar questions as Michael 
regarding BRSKI-CLE. I put my remarks inline

Best regards
Steffen

From: Anima  On Behalf Of Yanlei(Ray)
Sent: Friday, July 21, 2023 12:27 PM
To: Michael Richardson 
Cc: anima@ietf.org
Subject: Re: [Anima] BRSKI-CLE: A Certificateless Enrollment protocol in BRSKI

Hi Michael,
Thank you for your comments.

On 20. Jul 2023, Michael Richardson 
mailto:mcr+i...@sandelman.ca>>  wrote:

>Having read through the emails and reviewed the document a bit more, I think 
>that I see some ways in which the document could be clarified.
>
>First, this is not an extension or amendment to BRSKI.
>BRSKI is a way to introduce trust between Pledges and Registrars via the 
>third-party RFC8366 voucher.
>In 8995, it results in a RFC7030 *EST* channel, which is literally... 
>"Enrollment over Secure Transport".
>RFC7030 defines a CSR-based method to get a new certificate.
>
>CLE is not about BRSKI at all, it's about a new kind of enrollment.
>So, this document should be "EST-CLE", which is much akin to "BRSKI-AE"
>(which arguably from this point of view, should be "EST-AE" or even "EST-CMP", 
>only it's not EST at all)
>
>The reason CMP changes BRSKI is because it does away with the (provisional) 
>TLS connection, and RFC8995 deals primarily with how that connection is setup 
>to be useful.
>
>From what I can see, BRSKI-CLE does nothing to the provisional-TLS connection 
>at all, but rather changes what occurs after the Secure Transport exists.

Yes, you are right.
BRSKI-CLE just changes the enrollment phase in BRSKI.
I think enrollment is also a part of the bootstrap process in BRSKI, as shown 
in RFC8995.
Therefore, I think BRSKI-CLE somehow changes the process of BRSKI.

I saw BRSKI-AE is a working group draft.

Thus, I think BRSKI-CLE is also suitable under the auspices of the ANIMA WG.
[stf]  BRSKI-AE essentially described a way to exchange the enrollment protocol 
used in RFC 8995 with another enrollment. Specifically it employes CMP using 
the Lightweight CMP Profile. So in general the idea is to rely on the voucher 
exchange and ideally utilize the established TLS session also for the 
enrollment. The new enrolment protocol is expected to define an own endpoint 
for operation. In case of BRSKI-AE using CMP the endpoint is "cmp". In case of 
BRSKI-CLE, would the enrollment for credentials be an independent protocol 
employed by RSKI as it is the case for EST and CMP?


>The BRSKI-CLE document has a lot of text dealing with how the public keys are 
>derived.
>I don't really understand what the credential that is created by the AC is... 
>it looks like it's a signed object.

>Second, I don't understand how to devices (having been enrolled) as depicted 
>in section 2.3, as client and server are able to trust each other.  Maybe 
>there is some important magic that I've missed among the math.

The AC is a trusted third party, similar to the CA.
The CA uses its private key to sign the pledge's public key.
Other pledges use the CA's public key to verify whether the signature is signed 
by the CA.
The AC adds its public and private keys to the process of generating the 
pledge's public and private keys.
Other pledges can also use the AC's public key to verify whether the 
credential, which can derive the pledge's public key, is generated by the AC.
[stf] Based on section 2 in the draft, the credentials have no validity period 
and may not support revocation.  Would this require to renew also the AC keys 
if some existing keys are to be marked as invalid?

>I don't understand how it would differ from all the work in OAUTH and ACE.

A token is used by a client to request resources from a server in the scenario 
of ACE-OAUTH [RFC9200].
In  BRSKI-CLE, the usage of the credential is more general.
The pledge's action after the authentication using credentials is not specified 
in BRSKI-CLE.
[stf] I understood section 2.3 for the mutual authentication to describe the 
application of the credentials in some kind of independent manner

>I don't think that section 3 needs to educate us about Schnorr.  I learnt 
>nothing about the trust algorithm from the math.

The certificateless cryptography in BRSKI-CLE is similar to ECDSA and ECDHE.
I wrote these algorithms because I think it is necessary to explain the 
principle of certificateless authentication for applying it in BRSKI.
Now, I also realize putting the math algorithms in this draft may not be 
suitable.
However, I don't know which working group is proper for promoting the 
certificateless cryptography algorithms.
Do you have any suggestions?
[stf] If this is a new approach for setting up credentials it would be good if 
there is some more investigation of the security (you referred to the Schnorr 
signature algorithm, but the credential establishment seems to go further). To 
get feedback on the approach, it could be provided to LAMPS or also to the CRFG 
to get their opinion.

>Something about a 

[Anima] New Version of draft-eckert-anima-grasp-dnssd

[Fries, Steffen]

Hi,

I've read the latest version of draft-eckert-anima-grasp-dnssd-05 
(https://datatracker.ietf.org/doc/draft-eckert-anima-grasp-dnssd/), which has 
been updated just recently. It targets provisioning of service discovery 
information similar as mDNS but solely relying on GRASP. This approach seems 
appropriate in setups in which mDNS is not intended to be used.

It specifically considers the mapping of TXT params, which may be leveraged 
also in the current discussion of discovery of BRSKI registrars with enhanced 
feature sets. Here, the intention is, to provide additional TXT params to 
describe specific services a registrar may offer, like a different enrollment 
protocol or support for alternative voucher encodings. While this functionality 
is discussed in the context of mDNS (for BRSKI-PRM), it can easily be mapped to 
GRASP using the described approach.

That said, I'm not really deep in GRASP, but I think if we currently discuss 
service discovery options using mDNS to detect enhanced feature sets for BRSKI 
registrars, it would be equally important to have this opportunity also for 
ANIs using GRASP instead of mDNS to enable a more specific discovery of 
registrars.

Toerless, will it be discussed in the IETF 117 ANIMA session?

Best regards

Steffen
--
Steffen Fries

Siemens AG
Technology
Cybersecurity & Trust
T CST
Otto-Hahn-Ring 6
81739 Munich, Germany
Phone: +49 (89) 7805-22928
mailto:steffen.fr...@siemens.com
www.siemens.com
[Logo]
Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann 
Snabe; Managing Board: Roland Busch, Chairman, President and Chief Executive 
Officer; Cedrik Neike, Matthias Rebellius, Ralf P. Thomas, Judith Wiese; 
Registered offices: Berlin and Munich, Germany; Commercial registries: 
Berlin-Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] New Version Notification for draft-ietf-anima-brski-prm-09.txt

[Fries, Steffen]

Hello,

We just submitted an update of BRSKI-PRM (now version 09)
Since the last IETF meeting we mainly addressed the comments from the WGLC and 
the chair review, as there are:

   *  issue #80, enhanced Section 5.3.2 with clarification on the serial number 
and the inclusion of GRASP
   *  issue #81, enhanced introduction with motivation for agent_signed_data
   *  issue #82, included optional TLS protection of the communication link 
between registrar-agent and pledge in the introduction, Section 4, and Section 
6.1
   *  issue #83, enhanced Section 6.1.4 and Section 6.2.6 with note to 
re-enrollment
   *  issue #87, clarified available information at the registrar-agent in 
Section 6.1
   *  issue #88, clarified, that the PVR in Section 6.1.2 and PER in Section 
6.1.4 may contain the certificate chain.  If not contained it MUST be available 
at the registrar.
   *  issue #91, clarified that a separate HTTP connection may also be used to 
provide the PER in Section 6.2.6
   *  resolved remaining editorial issues discovered after WGLC (responded to 
on the mailing list in Reply 1 and Reply 2) resulting in more consistent 
descriptions
   *  issue #92: kept separate endpoint for wrapped CSR on registrar Section 
6.2.7
   *  issue #94: clarified terminology (possess vs. obtained)
   *  issue #95: clarified optional IDevID CA certificates on registrar- agent 
Section 6.3
   *  issue #96: updated Figure 14 to correct to just one CA certificate 
provisioning
   *  issue #97: deleted format explanation in Section 6.3 as it may be 
misleading
   *  issue #99: motivated verification of second signature on voucher in 
Section 6.3
   *  issue #100: included negative example in Figure 15
   *  issue #101: included handling if Section 6.3.2 voucher telemetry 
information has not been received by the registrar-agent
   *  issue #102: relaxed requirements for CA certs provisioning in Section 
6.3.3
   *  issue #105: included negative example in Figure 16
   *  issue #107: included example for certificate revocation in Section 6.3.6
   *  issue #108: renamed heading to Pledge-Status Request of Section 6.4.1
   *  issue #111: included pledge-status response processing for authenticated 
requests in Section 6.4.2
   *  issue #112: added "Example key word in pledge-status response in Figure 22
   *  issue #113: enhanced description of status reply for "factory-default" in 
Section 6.4.2
   *  issue #114: Consideration of optional TLS usage in Privacy Considerations
   *  issue #115: Consideration of optional TLS usage in Privacy Considerations 
to protect potentially privacy related information in the bootstrapping like 
status information, etc.
   *  issue #116: Enhanced DoS description and mitigation options in security 
consideration section

Most changes resulted in clarifications of terminology and approaches and 
additional error handling.
There are some open issues in the ANIMA git, which are discussed during the 
design team meetings. The solution of these issues is expected straight 
forward. There is one issue to be discussed for the BRSKI enhancements in 
general, which relates to the discovery of registrars with additional features. 
The intention is to come up for a solution, which is applicable to BRSKI-AE, 
BRSKI-PRM, constraint BRSKI.

Best regards
Steffen


> -Original Message-
> From: internet-dra...@ietf.org 
> Sent: Monday, July 10, 2023 9:34 PM
> To: Michael C. Richardson ; Eliot Lear
> ; Michael Richardson ; Fries,
> Steffen (T CST) ; Werner, Thomas (T CST SEA-DE)
> 
> Subject: New Version Notification for draft-ietf-anima-brski-prm-09.txt
> 
> 
> A new version of I-D, draft-ietf-anima-brski-prm-09.txt has been successfully
> submitted by Steffen Fries and posted to the IETF repository.
> 
> Name: draft-ietf-anima-brski-prm
> Revision: 09
> Title:BRSKI with Pledge in Responder Mode (BRSKI-PRM)
> Document date:2023-07-10
> Group:anima
> Pages:91
> URL:
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> .ietf.org%2Farchive%2Fid%2Fdraft-ietf-anima-brski-prm-
> 09.txt=05%7C01%7Csteffen.fries%40siemens.com%7Cdf72d4003fab4
> 2993ac008db817c8e09%7C38ae3bcd95794fd4addab42e1495d55a%7C1%
> 7C0%7C638246144182588719%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM
> C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C300
> 0%7C%7C%7C=KnV6w2R9H22iRcIL53A822%2FowLa12mlNsbREGgv
> MyeU%3D=0
> Status:
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatat
> racker.ietf.org%2Fdoc%2Fdraft-ietf-anima-brski-
> prm%2F=05%7C01%7Csteffen.fries%40siemens.com%7Cdf72d4003fa
> b42993ac008db817c8e09%7C38ae3bcd95794fd4addab42e1495d55a%7C1
> %7C0%7C638246144182588719%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi
> MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3
> 000%7C%7C%7C=2GdedDwvgEVmhw

Re: [Anima] Call for agenda items ANIMA@IETF117@ San Francisco

[Fries, Steffen]

Hi Sheng,

I would like to ask for the following slots for a status update on WG drafts

Topic/TitleBRSKI-AE Status Update
Name of Presenter(s) David von Oheimb
Length of time requested  5 min
If applicable: name of draft(s) discussed: draft-ietf-anima-brski-ae-05

Topic/TitleJWS-voucher Status Update
Name of Presenter(s) Steffen Fries
Length of time requested  5 min
If applicable: name of draft(s) discussed: draft-ietf-anima-jws-voucher-06

Topic/TitleBRSKI-PRM Status Update
Name of Presenter(s) Steffen Fries
Length of time requested  5 min
If applicable: name of draft(s) discussed: draft-ietf-anima-brski-prm-09

The slots are intended for a short update on the document status. There is a 
shared open issue (shared between the BRSKI related documents) for discovery of 
the registrar, which is intended to be discussed in a separate slot.

Best regards
Steffen



> -Original Message-
> From: Anima  On Behalf Of ??
> Sent: Thursday, July 6, 2023 10:33 AM
> To: anima 
> Cc: anima-chairs ; Toerless Eckert 
> Subject: [Anima] Call for agenda items ANIMA@IETF117@ San Francisco
>
> Dear ANIMA WG,
>
> The preliminary IETF117 agenda is on the web.
> ANIMA WG will meet at IETF117 for one 2 hour slot:
> Wednesday July 26th, 09:30-11:30 (Session I), Plaza B, MEETING TIMEZONE (San
> Francisco).
>
> Please submit your requests for Agenda items in reply to this email, as soon 
> as
> possible.
> The chairs plan to make WG draft agenda before 7/14/2023, so would be great if
> you could submit your agenda requests in before!
>
> Note that you do not need to have the slides by the time you're asking for the
> slot!
>
> Please send requests to anima-cha...@ietf.org.
> Copy anima@ietf.org if you like.
>
> Topic/Title
> Name of Presenter(s)
> Length of time requested
> If applicable: name of draft(s) discussed
>
> Also: Once you have your slides, go to:
>
>
> https://datatracke/
> r.ietf.org%2Fmeeting%2F117%2Fsession%2Fanima=05%7C01%7Csteffen.fri
> es%40siemens.com%7C83c1684d70744b8be17808db7dfbb42f%7C38ae3bcd957
> 94fd4addab42e1495d55a%7C1%7C0%7C638242292265880204%7CUnknown%7
> CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJ
> XVCI6Mn0%3D%7C3000%7C%7C%7C=WMpqXh1m3jQr3Ncl7YSyKnsvyB5
> HOLXD3HI5Aec82FA%3D=0
>
> and upload your slides via the "Propose Slides" Button (pick either of the 
> two slots
> as you see fit).
>
> Please also remember to (re-)start discussing any non-WG adopted work also on
> the anima@ietf.org mailing list to encourage WG members to read your work and
> comment!
>
> More details about the IETF 117 will be found at:
> https://www.ietf/.
> org%2Fhow%2Fmeetings%2F117%2F=05%7C01%7Csteffen.fries%40siemen
> s.com%7C83c1684d70744b8be17808db7dfbb42f%7C38ae3bcd95794fd4addab42
> e1495d55a%7C1%7C0%7C638242292266035988%7CUnknown%7CTWFpbGZsb3
> d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D
> %7C3000%7C%7C%7C=L4XyLoQG%2BUoDgu3lQh6KI2O5qdAwHRduj8Hdr
> JMltfw%3D=0
>
> Thank you so much!
>
> ANIMA WG Chairs,
> Sheng/Toerless
> ___
> Anima mailing list
> Anima@ietf.org
> https://www.ietf/.
> org%2Fmailman%2Flistinfo%2Fanima=05%7C01%7Csteffen.fries%40sieme
> ns.com%7C83c1684d70744b8be17808db7dfbb42f%7C38ae3bcd95794fd4addab4
> 2e1495d55a%7C1%7C0%7C638242292266035988%7CUnknown%7CTWFpbGZsb
> 3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
> D%7C3000%7C%7C%7C=2ULFt%2FWLxt%2FGyL4aLz%2FAhtTKarWiqDJFK
> i%2BJ6g%2FNYa4%3D=0
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] ANIMA: Certificate authentication, BRSKI PRM and RFC8995

[Fries, Steffen]

Hi Toerless,

As discussed in the last Design Team meeting, we agreed to include optional 
support for TLS between the registrar-agent and the pledge, to protect the 
communication regarding privacy. Depending on the utilized TLS version, certain 
information about the pledge may still be visible (TLS 1.2 has the handshake in 
clear, so the pledge IDevID certificate will be visible during the 
establishment). On the other hand, as the pledge will accept incoming 
connections in factory mode, it is also possible the TLS connection is 
established by a potential active adversary.

The optional TLS support has been included in the latest commit on gitlab 
addressing issue #82 and also #83.

Next week we will further discuss remaining open issues in the Design Team 
Meeting.

Best regards
Steffen

> -Original Message-
> From: Anima  On Behalf Of Fries, Steffen
> Sent: Dienstag, 2. Mai 2023 07:50
> To: Esko Dijk ; Toerless Eckert ;
> anima@ietf.org; draft-ietf-anima-...@ietf.org
> Cc: draft-t2trg-idevid-considerati...@ietf.org
> Subject: Re: [Anima] ANIMA: Certificate authentication, BRSKI PRM and
> RFC8995
>
> Hi Toerless, Esko,
>
> After some further discussions and double check of RFC 2818 I agree, it is
> possible to omit the hostname verification.
> The key I think is the statement in section 3.1 of RFC 2818
> (https://datatrac/
> ker.ietf.org%2Fdoc%2Fhtml%2Frfc2818%23section-
> 3.1=05%7C01%7Csteffen.fries%40siemens.com%7Cc2662a2ceff649ab93f
> e08db4ad110d2%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C6381
> 86034047182057%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ
> QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C
> =nzQ4Q4em6jN9yCqrXPNNTMVlCkMD6Ct9Q%2F6wu%2B7Hj5A%3D=
> 0):
> If the client has external information as to the expected identity of 
> the
> server, the hostname check MAY be omitted.
> A similar statement can be found in section 4.3.4 of RFC 9110
> (https://www.rfc/
> -editor.org%2Frfc%2Frfc9110.html%23name-https-certificate-
> verificat=05%7C01%7Csteffen.fries%40siemens.com%7Cc2662a2ceff649
> ab93fe08db4ad110d2%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7
> C638186034047182057%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM
> DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C
> =Mxr%2F%2BXwUx77bmIJiyfec2hYY5DLF7IvHO6pUZBjuKPo%3D
> d=0)
> In special cases, it might be appropriate for a client to simply 
> ignore the
> server's identity, but it must be understood that this leaves a connection 
> open to
> active attack.
>
> In case of BRSKI-PRM the identity check of the pledge (as TLS server) may be
> done based on the device serial numbers a registrar-agent must possess before
> onboarding pledges as outlined in section 6.1
> (https://www.iet/
> f.org%2Farchive%2Fid%2Fdraft-ietf-anima-brski-prm-08.html%23name-request-
> objects-
> acquisition=05%7C01%7Csteffen.fries%40siemens.com%7Cc2662a2ceff6
> 49ab93fe08db4ad110d2%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%
> 7C638186034047182057%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM
> DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C
> =heSaUFyA8n6dno4k3oBYZETpmKFlaxmg4LiBiEDfrV0%3D=0).
> This is in addition to the trustanchor (IDevID CA certificate) the 
> registrar-agent
> (TLS client) would need to verify the IDevID certificate of the pledge to 
> ensure
> he is connected to the specific instance of the pledge.
>
> Getting back to the origin of the discussion, as the discussion was a result 
> on
> one of the reasoning provided in BRSKI-PRM to not apply TLS between the
> registrar-agent and the pledge:
> - In BRSKI-PRM the communication between the registrar-agent and the pledge
> was designed to not rely on transport security, to enable also alternative
> transports such as BTLE or even NFC. For these, the use of TLS was not 
> expected
> and therefore security is applied on the messages exchanged directly.
> - As BRSKI-PRM targets as first approach for the exchange of the bootstrapping
> information to utilize http as transport we could recommend using TLS here to
> protect the privacy of the communication. This would only enhance the existing
> approach for that specific communication link as TLS is already used between
> the registrar-agent and the registrar.
>
> I will provide a proposal what to change in BRSKI-PRM for discussion in the 
> next
> Design Team Meeting (today).
>
> Best regards
> Steffen
>
>
> > -Original Message-
> > From: Anima  On Behalf Of Esko Dijk
> > Sent: Donnerstag, 27. April 2023 23:46
> > To: Toerless Eckert ; anima@ietf.org; draft-ietf-anima-
> > p...@ietf.org
> > Cc: draft-t2trg-idevid-considerati...@ietf.org
> > Subject: Re: [Anima] ANIMA: Certificate authenticati

Re: [Anima] ANIMA: Certificate authentication, BRSKI PRM and RFC8995

[Fries, Steffen]

Hi Toerless, Esko,

After some further discussions and double check of RFC 2818 I agree, it is 
possible to omit the hostname verification.
The key I think is the statement in section 3.1 of RFC 2818 
(https://datatracker.ietf.org/doc/html/rfc2818#section-3.1):
If the client has external information as to the expected identity of 
the server, the hostname check MAY be omitted.
A similar statement can be found in section 4.3.4 of RFC 9110 
(https://www.rfc-editor.org/rfc/rfc9110.html#name-https-certificate-verificat)
In special cases, it might be appropriate for a client to simply ignore 
the server's identity, but it must be understood that this leaves a connection 
open to active attack.

In case of BRSKI-PRM the identity check of the pledge (as TLS server) may be 
done based on the device serial numbers a registrar-agent must possess before 
onboarding pledges as outlined in section 6.1 
(https://www.ietf.org/archive/id/draft-ietf-anima-brski-prm-08.html#name-request-objects-acquisition).
 This is in addition to the trustanchor (IDevID CA certificate) the 
registrar-agent (TLS client) would need to verify the IDevID certificate of the 
pledge to ensure he is connected to the specific instance of the pledge.

Getting back to the origin of the discussion, as the discussion was a result on 
one of the reasoning provided in BRSKI-PRM to not apply TLS between the 
registrar-agent and the pledge:
- In BRSKI-PRM the communication between the registrar-agent and the pledge was 
designed to not rely on transport security, to enable also alternative 
transports such as BTLE or even NFC. For these, the use of TLS was not expected 
and therefore security is applied on the messages exchanged directly.
- As BRSKI-PRM targets as first approach for the exchange of the bootstrapping 
information to utilize http as transport we could recommend using TLS here to 
protect the privacy of the communication. This would only enhance the existing 
approach for that specific communication link as TLS is already used between 
the registrar-agent and the registrar.

I will provide a proposal what to change in BRSKI-PRM for discussion in the 
next Design Team Meeting (today).

Best regards
Steffen


> -Original Message-
> From: Anima  On Behalf Of Esko Dijk
> Sent: Donnerstag, 27. April 2023 23:46
> To: Toerless Eckert ; anima@ietf.org; draft-ietf-anima-
> p...@ietf.org
> Cc: draft-t2trg-idevid-considerati...@ietf.org
> Subject: Re: [Anima] ANIMA: Certificate authentication, BRSKI PRM and
> RFC8995
>
> Hi Toerless,
>
> I agree with your analysis here. RFC 2818 does allow to omit the hostname
> check if the client has additional information about the expected identity of 
> the
> server. (Which is in the PRM case, the CA trust anchors of the manufacturer of
> the device - or a set of trusted manufacturers that the commissioning tool
> tusts.)
>
> Also notice that although EST (RFC 7030) mentions RFC 2818, the BRSKI-PRM
> device to be onboarded does not implement EST server so any RFC 7030
> requirements on the server are not really applicable for that BRSKI-PRM 
> device.
> We define a new type of server here (the "Pledge-PRM" TLS server?) with own
> rules. I don't see why it should follow EST server rules here, it's not an EST
> server.
>
> That said, RFC 9110 makes things more restrictive it seems. But it also says 
> in 4.3
> "However, authoritative access is not limited to the identified mechanism."
> which means that other means of authoritative access to a resource/HTTPS
> server , i.e. other than the method defined in section 4.3 , are also 
> foreseen.
> So it should be okay to use HTTPS for the BRSKI-PRM use case.
>
> Regards
> Esko
>
> -Original Message-
> From: Anima  On Behalf Of Toerless Eckert
> Sent: Wednesday, April 26, 2023 19:11
> To: anima@ietf.org; draft-ietf-anima-...@ietf.org
> Cc: draft-t2trg-idevid-considerati...@ietf.org
> Subject: [Anima] ANIMA: Certificate authentication, BRSKI PRM and RFC8995
>
> In the process of discussing shepherd review feedback for BRSKI-PRM draft, the
> authors brought up arguments relating to their interpretation of requirements
> against required TLS server certificate validation by the client.
>
> Let me try to hopefully correctly restate and provide my thoughts, if i am
> misrepresenting, please correct me!
>
> Pre:
>
> A pledge has an IDevID and some dynamically assigned IP(v6) address, and no
> domain name.
>
> Claim of the authors
>
> Another device can not build a HTTP over TLS connection to the pledge and
> authenticate the pledge, because of the absence of domain name and IP-
> address based SubjectAltNames in the certificate - according to RFC2818.
> RFC2818 is required to be met because BRSKI relies on RFC7030 and RFC7030
> requires RFC2818.
>
> My assessment:
>
> I think this is an incorrect reading: I think that any time that a TLS server 
> would
> identify itself with an IDevID, paragraph 2 of section 3.1 of RFC2818 would be
> 

[Anima] Design Team Meeting discussion (April 25) on BRSKI-PRM discovery with cross relation to BRSKI-AE

[Fries, Steffen]

Hi Toerless, all

During the design team meeting on Tuesday, we had a discussion on issue #79 
(https://github.com/anima-wg/anima-brski-prm/issues/79) regarding the discovery 
of a registrar with enhanced functionalities like described in BRSKI-PRM. 
BRSKI-PRM supports pledges  in responder mode and defines additional endpoints 
at the registrar to facilitate newly defined communication.

To discover a registrar with this functionality, we currently discussion two 
options: DNS-SD  sub-types or TXT parameters to describe the additional 
functionality. From the discussion on Tuesday, it looks like TXT parameters are 
used more widespread and that it would be a good a approach to go this way. 
Nevertheless, we will also have a look into the DNS subtypes. If you have any 
suggestion please post them in the issue directly.

Independent of the final solution picked, as BRSKI-AE is also enhancing the 
functionality of a BRSKI registrar by supporting alternative enrollment 
protocols, the same approach is to be intended for BRSKI-AE as well. Therefore, 
we will wait with the submission of an updated BRSKI-AE draft until the 
discussion has ended.

Best regards
Steffen
--
Steffen Fries

Siemens AG
Technology
Cybersecurity & Trust
T CST
Otto-Hahn-Ring 6
81739 Munich, Germany
Phone: +49 (89) 7805-22928
mailto:steffen.fr...@siemens.com
www.siemens.com
[Logo]
Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann 
Snabe; Managing Board: Roland Busch, Chairman, President and Chief Executive 
Officer; Cedrik Neike, Matthias Rebellius, Ralf P. Thomas, Judith Wiese; 
Registered offices: Berlin and Munich, Germany; Commercial registries: 
Berlin-Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] IPR poll for draft-ietf-anima-brski-ae

[Fries, Steffen]

Dear Toerless,
 
As stated in the Design Team meeting, I am not aware of any IPR against 
BRSKI-AE (https://datatracker.ietf.org/doc/draft-ietf-anima-brski-ae/).
 
Best regards
 Steffen
 
> > -Original Message-
> > From: Toerless Eckert 
> > Sent: Mittwoch, 19. April 2023 18:19
> > To: draft-ietf-anima-brski...@ietf.org
> > Cc: anima@ietf.org; anima-cha...@ietf.org; rwil...@cisco.com
> > Subject: [Anima] IPR poll for draft-ietf-anima-brski-ae
> >
> > Dear subject draft authors and ANIMA WG:
> >
> > I am working on the document shepherd for draft-ietf-anima-brski-ae.
> > Here are the IPR question. The chairs must have answers for a) in
> > order to forward this work (authors may reply to chairs only). If any
> > one happens to know (b), then please reply to the chairs as well. Thanks!
> >
> > (a) We need for each of the drafts authors to make an IPR statement
> > about the draft (before it can proceed).
> >
> > As applicable, for example:
> >
> >   "I am not aware of any IPR against this document"
> >
> > [ Note: if some IPR that was declared against other IETF documents
> > also applies against this document, it needs to be re-declared for
> > this document.]
> >
> > (b) Dear ANIMA WG participants: if any of you has IPR knowledge
> > against this document, now would be a good time to bring it up. The
> > IETF IPR rules do ask you to do so:
> >
> >
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> >
> .ietf.org%2Fstandards%2Fipr%2F=05%7C01%7Csteffen.fries%40sieme
> >
> ns.com%7C6a8233bf35c141b0025d08db40f1c142%7C38ae3bcd95794fd4addab
> >
> 42e1495d55a%7C1%7C0%7C638175179293365401%7CUnknown%7CTWFpbGZ
> >
> sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6M
> >
> n0%3D%7C3000%7C%7C%7C=0cXmQQ7WALZDmamYuVIDH9vUjXULv
> > 86aG0osrYQlrwA%3D=0
> >
> > "During the standards process any IETF contribution covered by patents
> > or patent applications owned by a participant or their sponsor must be
> > disclosed, or they must refrain from participating."
> >
> > Aka: The only difference between authors and participants is that
> > participants do not need to report that they are no aware of any IPR.
> >
> > In general, you should not be unaware of IPR with your name on it.
> >
> > Currently,  there are no IPR disclosures against BRSKI-AE, so there is
> > now of course good time to check this voluntarily.
> >
> > Regards,
> > Toerless

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] PLEASE PROPOSE SLIDES - Re: Primary ANIMA agenda uploaded

[Fries, Steffen]

Hi Toreless, hi Sheng,

I just uploaded the slides for BRSKI-AE as well. Unfortunately, David will not 
be able to participate, so I'll give the status update as well. That said, 
including my previous email, I would propose to start like this, to have the 
related draft adjacent:

02 Update on JWS voucher
Time: 13:10 - 13:15 (5 minutes)
Draft: draft-ietf-anima-jws-voucher-06 (was -05 at IETF115)
Presenter: Steffen Fries (remote)

03 Update on BRSKI Pledge in responder Mode (BRSKI-PRM)
Time: 13:15 - 13:30 (15 Minutes)
Draft: draft-ietf-anima-brski-prm-08 (was -05 at IETF115)
Presenter: David von Oheimb (remote)

04 Update on BRSKI alternative enrollment (BRSKI-AE)
Time: 13:30 - 13:40 (10 Minutes)
Draft: draft-ietf-anima-brski-ae-04 (was -03 at IETF115)
Presenter: Steffen Fries (remote)


Best regards
Steffen

> -Original Message-
> From: Fries, Steffen (T CST)
> Sent: Montag, 27. März 2023 08:03
> To: Toerless Eckert ; Sheng Jiang 
> Cc: anima ; anima-chairs ;
> rwil...@cisco.com
> Subject: RE: [Anima] PLEASE PROPOSE SLIDES - Re: Primary ANIMA agenda
> uploaded
> 
> Hi Toerless, hi Sheng,
> 
> I just looked at the agenda.
> For JWS Voucher, 5-7 Minutes should be fine as it is merely a status update.
> I would propose to make BRSKI-PRM the next presentation as it relies on JWS
> voucher and it would make sense to have these presentations adjacent. BTW, I
> changed the version of BRSKI-PRM in the agenda from 7 to 8.
> Letting it follow by BRSKI-AE would keep the context to BRSKI enhancements.
> 
> Thanks and best regards
> Steffen
> 
> > -Original Message-
> > From: Anima  On Behalf Of Toerless Eckert
> > Sent: Sonntag, 26. März 2023 08:54
> > To: Sheng Jiang 
> > Cc: anima ; anima-chairs ;
> > rwil...@cisco.com
> > Subject: [Anima] PLEASE PROPOSE SLIDES - Re: Primary ANIMA agenda
> > uploaded
> >
> > Thanks Sheng!
> >
> > We have now also uploaded the agenda on the notes page, so it's easier
> > to collaboratively edit, and we will take notes on it during the
> > meeting as we did during the last meetings as well:
> >
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fnote
> > s.iet
> > f.org%2Fnotes-ietf-116-
> >
> anima=05%7C01%7Csteffen.fries%40siemens.com%7C817e0ba44f5f487f
> >
> 012408db2dc6e38a%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C6
> >
> 38154104460396726%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi
> >
> LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C
> >
> ata=VYs4%2FVt6PWX75mCS9stE1BK1yHeyzEOPs4UKNTwG3SQ%3D=0
> >
> > Please check if the session you requested is captured correctly, if
> > not, please talk to use. Also: if you see a "SLIDES MISSING" for your 
> > session,
> please "propose"
> > your slides on DataTracker as usual.
> >
> > Thanks & see you on wednesday in color and hopefully as many of you as
> > possible also in person!
> >
> > Cheers
> > Toerless
> >
> > On Sun, Mar 26, 2023 at 02:04:26PM +0800, Sheng Jiang wrote:
> > > Hi, Animaers,
> > >
> > >
> > > The chairs has updated a primary version of ANIMA agenda for
> > > IETF116, as
> > below link.
> > >
> > >
> > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fda
> > > ta
> > > tracker.ietf.org%2Fmeeting%2F116%2Fmaterials%2Fagenda-116-anima-
> > 00
> > >
> >
> a=05%7C01%7Csteffen.fries%40siemens.com%7C817e0ba44f5f487f012408db2
> > dc6
> > >
> >
> e38a%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C6381541044603
> > 96726%7
> > >
> >
> CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI
> > 6Ik1
> > >
> >
> haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=mNCCoHYM2VNBfzib3F
> > Wnpc1EtXTF
> > > EMmqJ61WhN5P2es%3D=0
> > >
> > >
> > > It is still an objective for changing. If you have any questions,
> > > please do
> > contact the chairs.
> > >
> > >
> > > Regards,
> > >
> > >
> > > Sheng
> >
> > ___
> > Anima mailing list
> > Anima@ietf.org
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> > ietf
> >
> .org%2Fmailman%2Flistinfo%2Fanima=05%7C01%7Csteffen.fries%40siem
> >
> ens.com%7C817e0ba44f5f487f012408db2dc6e38a%7C38ae3bcd95794fd4adda
> >
> b42e1495d55a%7C1%7C0%7C638154104460396726%7CUnknown%7CTWFpbGZ
> >
> sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0
> >
> %3D%7C3000%7C%7C%7C=hk%2FDZQwp2H4V77Vc0LgO3lwLmtX%2FnM
> > ceu0i4NB7HSN0%3D=0

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] PLEASE PROPOSE SLIDES - Re: Primary ANIMA agenda uploaded

[Fries, Steffen]

Hi Toerless, hi Sheng,

I just looked at the agenda. 
For JWS Voucher, 5-7 Minutes should be fine as it is merely a status update. 
I would propose to make BRSKI-PRM the next presentation as it relies on JWS 
voucher and it would make sense to have these presentations adjacent. BTW, I 
changed the version of BRSKI-PRM in the agenda from 7 to 8.
Letting it follow by BRSKI-AE would keep the context to BRSKI enhancements. 

Thanks and best regards
Steffen 

> -Original Message-
> From: Anima  On Behalf Of Toerless Eckert
> Sent: Sonntag, 26. März 2023 08:54
> To: Sheng Jiang 
> Cc: anima ; anima-chairs ;
> rwil...@cisco.com
> Subject: [Anima] PLEASE PROPOSE SLIDES - Re: Primary ANIMA agenda uploaded
> 
> Thanks Sheng!
> 
> We have now also uploaded the agenda on the notes page, so it's easier to
> collaboratively edit, and we will take notes on it during the meeting as we 
> did
> during the last meetings as well:
> 
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fnotes.iet
> f.org%2Fnotes-ietf-116-
> anima=05%7C01%7Csteffen.fries%40siemens.com%7C817e0ba44f5f487f
> 012408db2dc6e38a%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C6
> 38154104460396726%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi
> LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C
> ata=VYs4%2FVt6PWX75mCS9stE1BK1yHeyzEOPs4UKNTwG3SQ%3D=0
> 
> Please check if the session you requested is captured correctly, if not, 
> please talk
> to use. Also: if you see a "SLIDES MISSING" for your session, please "propose"
> your slides on DataTracker as usual.
> 
> Thanks & see you on wednesday in color and hopefully as many of you as
> possible also in person!
> 
> Cheers
> Toerless
> 
> On Sun, Mar 26, 2023 at 02:04:26PM +0800, Sheng Jiang wrote:
> > Hi, Animaers,
> >
> >
> > The chairs has updated a primary version of ANIMA agenda for IETF116, as
> below link.
> >
> >
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
> > tracker.ietf.org%2Fmeeting%2F116%2Fmaterials%2Fagenda-116-anima-
> 00
> >
> a=05%7C01%7Csteffen.fries%40siemens.com%7C817e0ba44f5f487f012408db2
> dc6
> >
> e38a%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C6381541044603
> 96726%7
> >
> CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI
> 6Ik1
> >
> haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=mNCCoHYM2VNBfzib3F
> Wnpc1EtXTF
> > EMmqJ61WhN5P2es%3D=0
> >
> >
> > It is still an objective for changing. If you have any questions, please do
> contact the chairs.
> >
> >
> > Regards,
> >
> >
> > Sheng
> 
> ___
> Anima mailing list
> Anima@ietf.org
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf
> .org%2Fmailman%2Flistinfo%2Fanima=05%7C01%7Csteffen.fries%40siem
> ens.com%7C817e0ba44f5f487f012408db2dc6e38a%7C38ae3bcd95794fd4adda
> b42e1495d55a%7C1%7C0%7C638154104460396726%7CUnknown%7CTWFpbGZ
> sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0
> %3D%7C3000%7C%7C%7C=hk%2FDZQwp2H4V77Vc0LgO3lwLmtX%2FnM
> ceu0i4NB7HSN0%3D=0

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

[Anima] FW: New Version Notification for draft-ietf-anima-brski-prm-08.txt

[Fries, Steffen]

Dear all,

We just posted an update of BRSKI-PRM with changes based on 
- resolved editorial issues discovered after WGLC (note that issues #79 - #84) 
have been created on the ANIMA github 
(https://github.com/anima-wg/anima-brski-prm/issues) and are currently worked 
on 
- resolved first comments from the Shepherd review as discussed in PR #85 on 
the ANIMA github (https://github.com/anima-wg/anima-brski-prm/pull/85)

We will provide an update on the draft during IETF 116

Best regards
Steffen

-Original Message-
From: internet-dra...@ietf.org  
Sent: Freitag, 10. März 2023 18:24
To: Michael C. Richardson ; Eliot Lear ; 
Michael Richardson ; Fries, Steffen (T CST) 
; Werner, Thomas (T CST SEA-DE) 

Subject: New Version Notification for draft-ietf-anima-brski-prm-08.txt


A new version of I-D, draft-ietf-anima-brski-prm-08.txt has been successfully 
submitted by Steffen Fries and posted to the IETF repository.

Name:   draft-ietf-anima-brski-prm
Revision:   08
Title:  BRSKI with Pledge in Responder Mode (BRSKI-PRM)
Document date:  2023-03-10
Group:  anima
Pages:  83
URL:
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-anima-brski-prm-08.txt=05%7C01%7Csteffen.fries%40siemens.com%7Cb5f112a0fe09430847c508db218c2df9%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C63814065817134%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=9BNudVJnmRxdVSDMnUlA1n21TvHDfmfYnpujwFoG4WQ%3D=0
Status: 
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-anima-brski-prm%2F=05%7C01%7Csteffen.fries%40siemens.com%7Cb5f112a0fe09430847c508db218c2df9%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C63814065817134%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=M4b8LQ2FJxeTA2BucVgTAbkOyg8c9dcJ8mOQ3DhCIoI%3D=0
Htmlized:   
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-anima-brski-prm=05%7C01%7Csteffen.fries%40siemens.com%7Cb5f112a0fe09430847c508db218c2df9%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C63814065817134%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=H5ETTK1GJdGZuB243h9UWtULdXVfbJqcth6AJbc6BiI%3D=0
Diff:   
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthor-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-anima-brski-prm-08=05%7C01%7Csteffen.fries%40siemens.com%7Cb5f112a0fe09430847c508db218c2df9%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638140658171933974%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=7hdKBO9AzP0FalT7tUjYo0F%2BsshuhKY0SiBciTgLqSE%3D=0

Abstract:
   This document defines enhancements to Bootstrapping a Remote Secure
   Key Infrastructure (BRSKI) [RFC8995] to enable bootstrapping in
   domains featuring no or only limited connectivity between a pledge
   and the domain registrar.  It specifically changes the interaction
   model from a pledge-initiated mode, as used in BRSKI, to a pledge-
   responding mode, where the pledge is in server role.  For this, BRSKI
   with Pledge in Responder Mode (BRSKI-PRM) introduces a new component,
   the registrar-agent, which facilitates the communication between
   pledge and registrar during the bootstrapping phase.  To establish
   the trust relation between pledge and registrar, BRSKI-PRM relies on
   object security rather than transport security.  The approach defined
   here is agnostic to the enrollment protocol that connects the domain
   registrar to the domain CA.


  


The IETF Secretariat


___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Shepherd review of draft-ietf-anima-brski-prm

[Fries, Steffen]

Dear Matthias, all

Thank you for your review and the proposals on making the draft more readable. 
I will go ahead an incorporate as much as possible from your suggestions to 
submit an update before the deadline on Monday.
I will keep track on commenting by using the ANIMA github:
[1] 
https://github.com/anima-wg/anima-brski-prm/pull/85
[2] 
https://github.com/anima-wg/anima-brski-prm/tree/shepherd-review

BTW, I'm still working on Toerless feedback and see if more issues need to be 
created. For the main issues raised, there are already issues created with 
respective proposals:
#79 discovery of registrar with BRSKI-PRM function 
set
#80 pledge discovery using 
GRASP?
#81 Additional text to explain usage of agent-signed data 

#82 Include text related to TLS library 
issues
#83 Clarify re-enrollment support in 
BRSKI-PRM
#84  use of registrar endpoints for responder vs. initiator 
mode

Best regards
Steffen

From: Matthias Kovatsch 
Sent: Mittwoch, 8. März 2023 17:30
To: anima ; anima-chairs ; 
draft-ietf-anima-brski-prm 
Subject: Shepherd review of draft-ietf-anima-brski-prm

Dear Anima WG, co-chairs, and authors

I started my shepherd review of draft-ietf-anima-brski-prm. I currently see the 
need for some restructuring to make the draft clearer to the reader and easier 
to implement. Hence my review is done as work-in-progress pull request in the 
GitHub repo of the draft [1].

Comments by Toerless have been captured as issues by the draft authors and will 
be resolved after the pull request is merged; where possible, they can be 
addressed in iterations going into the shepherd-review branch [2].

Best wishes,
Matthias

[1] 
https://github.com/anima-wg/anima-brski-prm/pull/85
[2] 
https://github.com/anima-wg/anima-brski-prm/tree/shepherd-review
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] ANIMA@IETF116: Call for agenda items

[Fries, Steffen]

Hi Toerless,

Two requests for the agenda:

Topic/Title Status Update on JWS Voucher
Name of Presenter(s)Steffen Fries
Length of time requested5-7 min
Draft name: draft-ietf-anima-jws-voucher-06 (or 
later), https://datatracker.ietf.org/doc/html/draft-ietf-anima-jws-voucher

Topic/Title Status Update on BRSKI-PRM
Name of Presenter(s)Steffen Fries
Length of time requested10-12 min
Draft name: draft-ietf-anima-brski-prm-07 (or 
later), https://datatracker.ietf.org/doc/draft-ietf-anima-brski-prm/

Best regards
Steffen

> -Original Message-
> From: Anima  On Behalf Of Toerless Eckert
> Sent: Dienstag, 28. Februar 2023 22:29
> To: anima@ietf.org
> Cc: anima-cha...@ietf.org
> Subject: [Anima] ANIMA@IETF116: Call for agenda items
> 
> Dear ANIMA WG
> 
> The preliminary IETF116 agenda is on the web.
> ANIMA WG will meet at IETF116 for one 2 hour slot:
> Thursday March 30th, 09:30-11:30 (Session I), Room G317, MEETING TIMEZONE
> (Japan).
> 
> [ Unfortunately, this means that those of you attending remotely from  Europe
> will have to wake up at 1:30 AM in the morning to participate.
>  So, sorry for the middle-of-the-night shift this time around.
>  I think we where quite lucky with our IETF115 time slot, but had the  same 
> issue
> of "dead-of-night (1-5AM slot) also in IETF114 London for the  remote 
> attendees
> from AsiaPac - so the pain goes around, but not even  every IETF! ]
> 
> On the counter side, i hope we will see many of you who have not been able to
> go in person to the last few IETFs since Covid in person in Yokohama!
> 
> With this said:
> 
> Please submit your requests for Agenda items in reply to this email, as soon 
> as
> possible.
> The WG draft agenda deadline is at the end of 3/15/2023, so would be great if
> you could submit your agenda requests in before!
> 
> Note that you do not need to have the slides by the time you're asking for the
> slot!
> 
> Please send requests to anima-cha...@ietf.org.
> Copy anima@ietf.org if you like.
> 
> Topic/Title
> Name of Presenter(s)
> Length of time requested
> If applicable: name of draft(s) discussed
> 
> Also: Once you have your slides, go to:
> 
> 
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatrac
> ker.ietf.org%2Fmeeting%2F116%2Fsession%2Fanima=05%7C01%7Csteffe
> n.fries%40siemens.com%7C40813d1068aa46ef5ab508db19d2dc92%7C38ae3bc
> d95794fd4addab42e1495d55a%7C1%7C0%7C638132165663117663%7CUnkno
> wn%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha
> WwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=ZcdrdQcKxxge3bN4AqgZxk
> cKSmTBenzuSRzo9yo25jE%3D=0
> 
> and upload your slides via the "Propose Slides" Button (pick either of the two
> slots as you see fit).
> 
> Please also remember to (re-)start discussing any non-WG adopted work also on
> the anima@ietf.org mailing list to encourage WG members to read your work
> and comment!
> 
> More details about the IETF 116 will be found at:
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf
> .org%2Fhow%2Fmeetings%2F116%2F=05%7C01%7Csteffen.fries%40siem
> ens.com%7C40813d1068aa46ef5ab508db19d2dc92%7C38ae3bcd95794fd4adda
> b42e1495d55a%7C1%7C0%7C638132165663117663%7CUnknown%7CTWFpbGZ
> sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0
> %3D%7C3000%7C%7C%7C=s4jK3S36yVQTjgMQ0VFIC1b2fiEu8RChNXl%2
> BBZ0Hs9E%3D=0
> 
> Thank you so much!
> ANIMA WG Chairs, Sheng/Toerless
> 
> ___
> Anima mailing list
> Anima@ietf.org
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf
> .org%2Fmailman%2Flistinfo%2Fanima=05%7C01%7Csteffen.fries%40siem
> ens.com%7C40813d1068aa46ef5ab508db19d2dc92%7C38ae3bcd95794fd4adda
> b42e1495d55a%7C1%7C0%7C638132165663273883%7CUnknown%7CTWFpbGZ
> sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0
> %3D%7C3000%7C%7C%7C=JmaqHqnL9zDATnJiUVwM8uJzPoFj7K%2BIcE
> dd70t%2BdVQ%3D=0

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

[Anima] FW: New Version Notification for draft-ietf-anima-brski-prm-07.txt

[Fries, Steffen]

Hi all,

This update mainly comprises the comment (and PULL request) to remove all YANG 
definitions for the voucher-request as they are handled in RFC 8366bis. Besides 
this the references have been updated and some editorial nits have been 
removed. 

With that the draft is ready for the Shepherds review.

Best regards
Steffen

-Original Message-
From: internet-dra...@ietf.org  
Sent: Dienstag, 21. Februar 2023 13:06
To: Michael C. Richardson ; Eliot Lear ; 
Michael Richardson ; Fries, Steffen (T CST) 
; Werner, Thomas (T CST SEA-DE) 

Subject: New Version Notification for draft-ietf-anima-brski-prm-07.txt


A new version of I-D, draft-ietf-anima-brski-prm-07.txt has been successfully 
submitted by Steffen Fries and posted to the IETF repository.

Name:   draft-ietf-anima-brski-prm
Revision:   07
Title:  BRSKI with Pledge in Responder Mode (BRSKI-PRM)
Document date:  2023-02-21
Group:  anima
Pages:  83
URL:
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-anima-brski-prm-07.txt=05%7C01%7Csteffen.fries%40siemens.com%7C60eea67db7934cefa66208db1403fa2f%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638125779529183024%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=LQF7T6wEWNjksQS6UUkdHAYfti5%2BRAdfLftUOTgwpdo%3D=0
Status: 
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-anima-brski-prm%2F=05%7C01%7Csteffen.fries%40siemens.com%7C60eea67db7934cefa66208db1403fa2f%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638125779529339241%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=ztngVoObXKQ6xByuXAtBN5Sy6%2B1sxLrtfRH%2Fm3M4bwY%3D=0
Htmlized:   
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-anima-brski-prm=05%7C01%7Csteffen.fries%40siemens.com%7C60eea67db7934cefa66208db1403fa2f%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638125779529339241%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=R5kyThQWCZw2Q8HB3dJMOcsH5kf86qg%2FX%2BpqKBQUqQY%3D=0
Diff:   
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthor-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-anima-brski-prm-07=05%7C01%7Csteffen.fries%40siemens.com%7C60eea67db7934cefa66208db1403fa2f%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638125779529339241%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=9RKomufZ4m7DcjYYBLN8EyFPs%2Fy9cbXrfGkIo7z%2F6fM%3D=0

Abstract:
   This document defines enhancements to bootstrapping a remote secure
   key infrastructure (BRSKI, RFC8995) to facilitate bootstrapping in
   domains featuring no or only time limited connectivity between a
   pledge and the domain registrar.  It specifically targets situations
   in which the interaction model changes from a pledge-initiated-mode,
   as used in BRSKI, to a pledge-responding-mode as described in this
   document.  To support the pledge-responding mode, BRSKI-PRM
   introduces a new component, the registrar-agent, which facilitates
   the communication between pledge and registrar during the
   bootstrapping phase.  To establish the trust relation between pledge
   and domain registrar, BRSKI-PRM relies on object security rather than
   transport security.

   The approach defined here is agnostic with respect to the underlying
   enrollment protocol which connects the pledge and the domain
   registrar to the Domain CA.


  


The IETF Secretariat


___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

[Anima] Result//RE: WGLC for draft-ietf-anima-brski-prm-06, ends Feb. 15th, 2023

[Fries, Steffen]

Hi Sheng,

I will provide an updated version by tomorrow, incorporating the proposed 
changes. 

Best regards
Steffen

> -Original Message-
> From: Sheng Jiang 
> Sent: Montag, 20. Februar 2023 04:42
> To: anima ; Toerless Eckert ; anima-chairs
> ; draft-ietf-anima-brski-prm  p...@ietf.org>; ietf 
> Cc: ietf 
> Subject: Re: WGLC for draft-ietf-anima-brski-prm-06, ends Feb. 15th, 2023
> 
> During the WGLC period, this drafts has received no objections, but comments.
> Therefore, the chairs would draw on a passed conclusion . The WG discussed the
> authors' suggestion that move the YANG components of this to rfc8366bis and
> reach the consensus to respect the authors' choice. The authors please submit
> an update version. Then, the document shepherd can move it forward.
> 
> Regards,
> 
> 
> --
> 
> 
> 
> Sheng Jiang
> 
> 
> 
> >Dear ANIMAers,
> 
> 
> 
> >
> 
> 
> 
> >This message starts the two-week (*) ANIMA Working Group Last Call to
> advance draft-ietf-anima-brski-prm-06, which specifies enhancements to BRSKI
> (RFC8995) to facilitate bootstrapping in domains featuring no or only time
> limited connectivity between apledge and the domain registrar. This
> document's intended status is Standards Track. At present, there is no IPR 
> filed
> against this document. This document has been ANIMA WG document since
> October, 2021 and has received a lot of feedback from the WG and work from
> its authors. The authors therefore think is ready for WGLC. Please send your
> comments by Feb. 15th 2023. If you do not feel this document should advance,
> please state your reasons why.Matthias Kovatschis the assgined
> document shepherd.
> 
> 
> 
> >
> 
> 
> 
> >
> 
> 
> 
> >Regards,
> 
> 
> 
> >
> 
> 
> 
> >
> 
> 
> 
> >Sheng
> 

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] WGLC for draft-ietf-anima-brski-prm-06, ends Feb. 15th, 2023

[Fries, Steffen]

Hi Sheng,

“All known for now” would be the approach to my understanding. As I understood 
Michael’s current experiences, there is no easy way to provide extensibility to 
the voucher, which lead to the proposal to include the current state of known 
requirements into RFC 8366bis. Note that this document describes the voucher 
and the voucher request. That said, it does not necessarily require an update 
to one of the current BRSKI documents, assumed, that the syntax is backward 
compatible if new changes/additions are made to the voucher or voucher request.

Best regards
Steffen

From: Sheng Jiang 
Sent: Donnerstag, 2. Februar 2023 10:41
To: Fries, Steffen (T CST) ; Michael Richardson 

Cc: anima ; Toerless Eckert ; anima-chairs 
; draft-ietf-anima-brski-prm 
; ietf 
Subject: Re: [Anima] WGLC for draft-ietf-anima-brski-prm-06, ends Feb. 15th, 
2023

> collect all known requirements for vouchers in RFC8366bis hoping that
> we covered all to avoid increasing complexity during augmentation of the 
> voucher.

I do not prefer the "all-covered" model. As you stated, all has to be "known" 
for now. What if another unknown requirement appeared？ Another bis, BRSKI v3? I 
think it is better that rfc8366bis covers an extensible generic framework and 
rules for future extensions. So, the future requirements and their mechanism 
can be developed independently without update BRSKI fundamental specification.

However, by saying the above, I can also accept your abovementioned model as if 
this rfc8366bis is BRSKI-final.

Regards,

Sheng

-- Original ----------
From:  "Fries, 
Steffen"mailto:steffen.fr...@siemens.com>>;
Date:  Thu, Feb 2, 2023 03:29 PM
To:  "Sheng Jiang"mailto:shengji...@bupt.edu.cn>>; 
"Michael Richardson"mailto:mcr+i...@sandelman.ca>>;
Cc:  "anima"mailto:anima@ietf.org>>; "Toerless 
Eckert"mailto:t...@cs.fau.de>>; 
"anima-chairs"mailto:anima-cha...@ietf.org>>; 
"draft-ietf-anima-brski-prm"mailto:draft-ietf-anima-brski-...@ietf.org>>;
 "ietf"mailto:i...@kovatsch.net>>;
Subject:  Re: [Anima] WGLC for draft-ietf-anima-brski-prm-06, ends Feb. 15th, 
2023

Hi Sheng,

Just to chime in here, my understanding was that we collect all known 
requirements for vouchers in RFC8366bis hoping that we covered all to avoid 
increasing complexity during augmentation of the voucher. That said, I see a 
normative reference of BRSKI-PRM to RFC 8366bis but not necessarily vice versa. 
RFC 8366bis would describe the voucher and also the voucher request with all 
currently known fields and would leave the usage of these field up too the 
referring RFCs.
With that, as Michael pointed out, we would get rid of the voucher specific 
details in BRSKI-PRM. The technical concept of BRSKI-PRM can be reviewed 
independent of this. I assumed this was the target of the WGLC.
BTW, we have another normative dependency on JWS-Voucher, which to my 
understanding is also ready for WGLC.

Best regards
Steffen




From: Sheng Jiang mailto:shengji...@bupt.edu.cn>>
Sent: Donnerstag, 2. Februar 2023 08:13
To: Michael Richardson mailto:mcr+i...@sandelman.ca>>
Cc: anima mailto:anima@ietf.org>>; Toerless Eckert 
mailto:t...@cs.fau.de>>; anima-chairs 
mailto:anima-cha...@ietf.org>>; 
draft-ietf-anima-brski-prm 
mailto:draft-ietf-anima-brski-...@ietf.org>>;
 ietf mailto:i...@kovatsch.net>>
Subject: Re: WGLC for draft-ietf-anima-brski-prm-06, ends Feb. 15th, 2023

> Hi, please be aware that the YANG components of this will be moved to

> rfc8366bis.   They are already in the rfc8366bis-05, but I don't yet feel

> that we have *WG* Consensus to do this.

In general, I don't have preference whether this document of rfc8366bis defines 
YANG components. The major differency would be rfc8366bis would depend on the 
brski-prm document. That could means rfc8366bis could not  be published as RFC 
until brshi-prm published. I think an independent rfc8366bis could move faster. 
However, as I said, I don't have personal preference. I am fine either way。 I 
would leave this to authors‘’ choice.

Regards,

Sheng


-- Original --
From:  "Michael 
Richardson"mailto:mcr+i...@sandelman.ca>>;
Date:  Thu, Feb 2, 2023 03:34 AM
To:  "Sheng Jiang"mailto:shengji...@bupt.edu.cn>>;
Cc:  "anima"mailto:anima@ietf.org>>; "Toerless 
Eckert"mailto:t...@cs.fau.de>>; 
"anima-chairs"mailto:anima-cha...@ietf.org>>; 
"draft-ietf-anima-brski-prm"mailto:draft-ietf-anima-brski-...@ietf.org>>;
 "ietf"mailto:i...@kovatsch.net>>;
Subject:  Re: WGLC for draft-ietf-anima-brski-prm-06, ends Feb. 15th, 2023


Sheng Jiang mailto:shengji...@bupt.edu.cn>> wrote:
> This message starts the two-week (*) ANIMA W

Re: [Anima] WGLC for draft-ietf-anima-brski-prm-06, ends Feb. 15th, 2023

[Fries, Steffen]

Hi Sheng,

Just to chime in here, my understanding was that we collect all known 
requirements for vouchers in RFC8366bis hoping that we covered all to avoid 
increasing complexity during augmentation of the voucher. That said, I see a 
normative reference of BRSKI-PRM to RFC 8366bis but not necessarily vice versa. 
RFC 8366bis would describe the voucher and also the voucher request with all 
currently known fields and would leave the usage of these field up too the 
referring RFCs.
With that, as Michael pointed out, we would get rid of the voucher specific 
details in BRSKI-PRM. The technical concept of BRSKI-PRM can be reviewed 
independent of this. I assumed this was the target of the WGLC.
BTW, we have another normative dependency on JWS-Voucher, which to my 
understanding is also ready for WGLC.

Best regards
Steffen




From: Sheng Jiang 
Sent: Donnerstag, 2. Februar 2023 08:13
To: Michael Richardson 
Cc: anima ; Toerless Eckert ; anima-chairs 
; draft-ietf-anima-brski-prm 
; ietf 
Subject: Re: WGLC for draft-ietf-anima-brski-prm-06, ends Feb. 15th, 2023

> Hi, please be aware that the YANG components of this will be moved to

> rfc8366bis.   They are already in the rfc8366bis-05, but I don't yet feel

> that we have *WG* Consensus to do this.

In general, I don't have preference whether this document of rfc8366bis defines 
YANG components. The major differency would be rfc8366bis would depend on the 
brski-prm document. That could means rfc8366bis could not  be published as RFC 
until brshi-prm published. I think an independent rfc8366bis could move faster. 
However, as I said, I don't have personal preference. I am fine either way。 I 
would leave this to authors‘’ choice.

Regards,

Sheng


-- Original --
From:  "Michael 
Richardson"mailto:mcr+i...@sandelman.ca>>;
Date:  Thu, Feb 2, 2023 03:34 AM
To:  "Sheng Jiang"mailto:shengji...@bupt.edu.cn>>;
Cc:  "anima"mailto:anima@ietf.org>>; "Toerless 
Eckert"mailto:t...@cs.fau.de>>; 
"anima-chairs"mailto:anima-cha...@ietf.org>>; 
"draft-ietf-anima-brski-prm"mailto:draft-ietf-anima-brski-...@ietf.org>>;
 "ietf"mailto:i...@kovatsch.net>>;
Subject:  Re: WGLC for draft-ietf-anima-brski-prm-06, ends Feb. 15th, 2023


Sheng Jiang mailto:shengji...@bupt.edu.cn>> wrote:
> This message starts the two-week (*) ANIMA Working Group Last Call to
> advance draft-ietf-anima-brski-prm-06, which specifies enhancements to
> BRSKI (RFC8995) to facilitate bootstrapping in domains featuring no or
> only time limited connectivity between apledge and the domain

Hi, please be aware that the YANG components of this will be moved to
rfc8366bis.   They are already in the rfc8366bis-05, but I don't yet feel
that we have *WG* Consensus to do this.

Toerless has asked me to regurgitate the entire discussion, again, which I
think that I won't do.

> If you do not feel this document should advance, please state
> your reasons why

So, as much as I'd like it to advance, I don't think it can advance until we
agree what to do with the YANG.


--
Michael Richardson mailto:mcr+i...@sandelman.ca>>, 
Sandelman Software Works
 -= IPv6 IoT consulting =-



___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] changes for CORE-SID and SX:structure in draft-ietf-anima-rfc8366bis-04 and -05

[Fries, Steffen]

Hi Michael 

> -Original Message-
> Sent: Dienstag, 24. Januar 2023 15:58
> Subject: [Anima] changes for CORE-SID and SX:structure in draft-ietf-anima-
> rfc8366bis-04 and -05
> 
> 
> Did I post this already?
> 
> I have just posted -04, which includes some, but not all, of the BRSKI-PRM
> changes.  I missed the assertion changes in -04, but they are in -05.
Yes, I realized the enhancement in the assertions in section 5.4. 
I was thinking if it would be helpful to also explain the assertion types in 
the text, but this would somehow replicate the text in the voucher description, 
which is also part of RFC 8366. 
For assertion types, which are motivated/defined by other documents, I would 
propose to add a reference to the originating document, also for the handling 
(agent-proximity would then reference BRSKI-PRM)

The YANG definition of the voucher request (ietf-voucher-request.yang) looks 
fine from a BRSKI-PRM perspective. The parameters defined are contained. While 
BRSKI-PRM does not specify further values, I was thinking if equivalent values 
for the constraint case for 
- agent-provided-proximity-registrar-cert: for constraint also 
agent-provided-proximity-registrar-pubk and 
agent-provided-proximity-registrar-pubk-sha256
- agent-sign-cert: for constraint also agent-sign-pubk and 
agent-sign-pubk-sha256
would make sense to avoid transporting the complete certificates. In BRSKI-PRM 
we have the agent-sign-cert as optional for the pledge and mandatory for the 
registrar to address these cases for constraint pledges. But including just 
pubk or pubk-sha256 would also be an option.
 
> 
> -04:
> In fixing the SID allocations to be consistent (and fixing pyang/sid.py to 
> always
> dump .sid files and list output in SID order.
> The augment mechanism results in a change the leaf path for the voucher-
> request, from:
> 
> /ietf-voucher-request-constrained:voucher/nonce
> to:
> /ietf-voucher-request:voucher/voucher/nonce
> 
> The change from request-constrained to request is anticipated, and I think
> acceptable. (This affects the JSON serialization) But, the additional of an 
> extra
> "voucher" in the path concerns me.
> I tried "augment-structure" as described in RFC 8791, but pyang didn't like 
> it.
> 
> 
> I tried to hack on things with yanglint, but I think it doesn't work.
> 
> rfc8366bis-05:
> * I've also fixed the wrapping in the description so there are no rfc8792
>   wrapped lines. (Kudos to kramdown: it doesn't tell you about 8792 if it
>   doesn't use them)
> 
> * Table 1 is now down up in markdown format.  I'm not sure how to make cells
>   span rows.  I would appreciate someone else to verify the new table 1
>   against RFC8366's version.
I double checked the content of both tables and the one in the PR looks fine. 
It reflects, what is currently stated in RFC 8366
Format wise, centering the associated cells in a row would increase readability.


> 
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co
> m%2Fanima-
> wg%2Fvoucher%2Fpull%2F22%2Ffiles=05%7C01%7Csteffen.fries%40siem
> ens.com%7C96b155c5218c4639287008dafe1b6fb0%7C38ae3bcd95794fd4adda
> b42e1495d55a%7C1%7C0%7C638101691038757391%7CUnknown%7CTWFpbGZ
> sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0
> %3D%7C3000%7C%7C%7C=EF3rsQs8zKv0IpglR68zoXdfWMs9b2%2FAPy3
> SDBizoqQ%3D=0
> I'm not going to merge this PR until I get some additional review on the
> differences, and the overall approach to the YANG.
Some observations in addition to the ones above (unsorted regarding 
importance): 
- section 1 and section 5: jws-voucher may be stated as alternative to the 
utilized CMS structure in RFC8366
- section 2: proposal to also state the registrar-agent with a reference to 
BRSKI-PRM
- section 7.2: just food for thought, would it make sense to also allow a 
nonceless voucher with a list of device serial numbers? This would limit the 
exchange with the MASA to just one or may be a mean for a pre-provisioned 
voucher. This would require an array in the voucher definition for the serial 
number (currently a string). In addition, it may also lead to an enhancement of 
section 2 regarding voucher-types. 

Observations from ietf-voucher.yang (I'm not a YANG expert):
- the created-on time has been changed to optional? At least this is what I 
gather from mandatory=false. It is mandatory in the current voucher definition. 
Not sure regrading the change and if it is necessary to state it explicitly. 
- the expires-on is optional (which is fine) but mandatory=false is not stated. 
According to RFC 6020, the semantic is the same as not stating it. So we may 
remove the mandatory=false for the created-on leaf.
- the pinned-domain-cert has been changed to optional (mandatory=false ) as 
created-on

Best regards
Steffen


> 
> **I AM ASKING FOR A WG CHAIR CONSENSUS CALL**
> 
> --
> ]   Never tell me the odds! | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman 

Re: [Anima] I-D Action: draft-ietf-anima-brski-prm-06.txt

[Fries, Steffen]

Hi all,

I just uploaded the updated version of BRSKI-PRM with the following changes:
   *  Update of list of reviewers
   *  Issue #67, shortened the pledge endpoints to prepare for  constraint 
deployments
   *  Included table for new endpoints on the registrar in the overview of the 
registrar-agent
   *  addressed review comments from SECDIR early review
   *  addressed review comments from IOTDIR early review

The remaining issue relates to the YANG module and the augmentation of the 
voucher. Based on Michaels analysis, this issue may be solved in the context of 
a RFC 8366bis, which has been discussed already to address the enumeration 
issue in the assertion of the voucher. 

Besides this, we have a proof of concept implementation available, for which we 
would be happy to do interop testing. The authors think the draft is 
technically sound and may go into WGLC soon. 

Best regards
Steffen


> -Original Message-
> From: Anima  On Behalf Of internet-
> dra...@ietf.org
> Sent: Mittwoch, 11. Januar 2023 16:26
> To: i-d-annou...@ietf.org
> Cc: anima@ietf.org
> Subject: [Anima] I-D Action: draft-ietf-anima-brski-prm-06.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Autonomic Networking Integrated Model and
> Approach WG of the IETF.
> 
> Title   : BRSKI with Pledge in Responder Mode (BRSKI-PRM)
> Authors : Steffen Fries
>   Thomas Werner
>   Eliot Lear
>   Michael C. Richardson
>   Filename: draft-ietf-anima-brski-prm-06.txt
>   Pages   : 86
>   Date: 2023-01-11
> 
> Abstract:
>This document defines enhancements to bootstrapping a remote secure
>key infrastructure (BRSKI, RFC8995) to facilitate bootstrapping in
>domains featuring no or only time limited connectivity between a
>pledge and the domain registrar.  It specifically targets situations
>in which the interaction model changes from a pledge-initiated-mode,
>as used in BRSKI, to a pledge-responding-mode as described in this
>document.  To support the pledge-responding mode, BRSKI-PRM
>introduces a new component, the registrar-agent, which facilitates
>the communication between pledge and registrar during the
>bootstrapping phase.  To establish the trust relation between pledge
>and domain registrar, BRSKI-PRM relies on object security rather than
>transport security.
> 
>The approach defined here is agnostic with respect to the underlying
>enrollment protocol which connects the pledge and the domain
>registrar to the Domain CA.
> 
> 
> The IETF datatracker status page for this draft is:
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatat
> racker.ietf.org%2Fdoc%2Fdraft-ietf-anima-brski-
> prm%2F=05%7C01%7Csteffen.fries%40siemens.com%7C1389d0a4f00d
> 43c780f208daf3e81ef2%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%
> 7C638090475535201376%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw
> MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%
> 7C=JetQcFlwiWWaD%2F9fUzgzCcXVMmE3OxSxgWrJ4e4sGuc%3D
> served=0
> 
> There is also an htmlized version available at:
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatat
> racker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-anima-brski-prm-
> 06=05%7C01%7Csteffen.fries%40siemens.com%7C1389d0a4f00d43c78
> 0f208daf3e81ef2%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C63
> 8090475535201376%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD
> AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C
> =hXzsyeRPNhsT1s2sXuMz1bnr2gGavtr6ZDVwvNl8%2BSA%3D
> ed=0
> 
> A diff from the previous version is available at:
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauth
> or-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-anima-brski-prm-
> 06=05%7C01%7Csteffen.fries%40siemens.com%7C1389d0a4f00d43c78
> 0f208daf3e81ef2%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C63
> 8090475535201376%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD
> AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C
> =SEjrqfPXmk4%2Fbbhp%2FLMP5y6LRcxomkUCmZLGFq7C%2BMI%3D
> =0
> 
> 
> Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts
> 
> 
> ___
> Anima mailing list
> Anima@ietf.org
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> .ietf.org%2Fmailman%2Flistinfo%2Fanima=05%7C01%7Csteffen.fries%
> 40siemens.com%7C1389d0a4f00d43c780f208daf3e81ef2%7C38ae3bcd95794f
> d4addab42e1495d55a%7C1%7C0%7C638090475535201376%7CUnknown%7CT
> WFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLC
> JXVCI6Mn0%3D%7C3000%7C%7C%7C=FFgFtgo3U6BwvGBVvLgfjtSJPx
> LiLL9Xg5U8QclFKVQ%3D=0

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

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

[Fries, Steffen]

Hi Reshad,

A while ago you did the early YANGDOCTORS review of BRSKI-AE. You identified 
some issues to be addressed. Meanwhile we have split the draft to better focus 
on distinct functionality. The result is BRSKI-AE 
(https://datatracker.ietf.org/doc/draft-ietf-anima-brski-ae/) and BRSKI-PRM 
(https://datatracker.ietf.org/doc/draft-ietf-anima-brski-prm/).
After the split all YANG related module definitions were moved into BRSKI-PRM, 
as there was no further need in BRSKI-AE to define own YANG modules. 
RSKI-PRM meanwhile had a YANGDOCTORS early review which resulted in "Ready with 
Nits"

What I wanted to ask is if there is any possibility to update the YANGDOCTORS 
early review for BRSKI-AE to "not applicable" or similar to avoid the 
impression it defines a YANG module in the first place and that it needs 
further work based on the review results? 
We are currently in the preparation of WGLC. Hence the question.

Best regards
Steffen

> -Original Message-
> From: Anima  On Behalf Of Reshad Rahman via
> Datatracker
> Sent: Sonntag, 15. August 2021 17:23
> To: yang-doct...@ietf.org
> Cc: draft-ietf-anima-brski-async-enroll@ietf.org; anima@ietf.org
> Subject: [Anima] Yangdoctors early review of draft-ietf-anima-brski-async-
> enroll-03
> 
> Reviewer: Reshad Rahman
> Review result: Not Ready
> 
> Major comments on this document:
> - The YANG module has errors. Please validate it first e.g. by using
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fyangvalid
> ator.com%2Fyangvalidatordata=04%7C01%7Ccef9763c-149c-4881-b9c2-
> 5fedc277663a%40ad011.siemens.com%7C7e6d34307a3642d99cd208d9600095
> 14%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637646377883255
> 602%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=qZYcLcbndcMuCb77Zj
> sWzaXAhcLQTqYixESNNN4h%2BcA%3Dreserved=0 or local tools. Also if
> you follow guidelines @
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatrac
> ker.ietf.org%2Fdoc%2Fhtml%2Frfc8407%23section-
> 3.2data=04%7C01%7Ccef9763c-149c-4881-b9c2-
> 5fedc277663a%40ad011.siemens.com%7C7e6d34307a3642d99cd208d9600095
> 14%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637646377883255
> 602%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=kynl2GRBX1uCdL8hvU
> %2BZVqkHKdTMrp%2B4u5ZsYZWzcLE%3Dreserved=0, you will see errors
> present, if any, on datatracker. See below for the modified YANG module which
> is valid, please check whether it is correct. Changes consist of removing 
> extra ";
> in author list, adding a revision date and replacing augment "voucher-request"
> by augment voucher. - Include a tree diagram as per
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatrac
> ker.ietf.org%2Fdoc%2Fhtml%2Frfc8407%23section-
> 3.4data=04%7C01%7Ccef9763c-149c-4881-b9c2-
> 5fedc277663a%40ad011.siemens.com%7C7e6d34307a3642d99cd208d9600095
> 14%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637646377883255
> 602%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=cnmkIb3STbSR5BHuwI
> GWxsj2lMYMs7AmlbMtF8euKhU%3Dreserved=0 - For the security
> considerations, please add information as requested in
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatrac
> ker.ietf.org%2Fdoc%2Fhtml%2Frfc8407%23section-
> 3.7data=04%7C01%7Ccef9763c-149c-4881-b9c2-
> 5fedc277663a%40ad011.siemens.com%7C7e6d34307a3642d99cd208d9600095
> 14%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637646377883255
> 602%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=yGzdefsWVH2Hh2%2
> B5IPJiCplkkQ82KQgsPpKLjOV%2BlrI%3Dreserved=0
> 
> New assertion-type:
> This is regarding issue #18, i.e.
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co
> m%2Fanima-wg%2Fanima-brski-async-
> enroll%2Fissues%2F18data=04%7C01%7Ccef9763c-149c-4881-b9c2-
> 5fedc277663a%40ad011.siemens.com%7C7e6d34307a3642d99cd208d9600095
> 14%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637646377883255
> 602%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=a7GFxdMxFfZ65hYCa3
> dWR8VR7apcwUeTtudUppFFysw%3Dreserved=0, the need for 8366bis
> etc. Email threads:
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchi
> ve.ietf.org%2Farch%2Fmsg%2Fnetmod%2FOm6QOZL-
> bupgEblNLDL3S0PnaPY%2Fdata=04%7C01%7Ccef9763c-149c-4881-b9c2-
> 5fedc277663a%40ad011.siemens.com%7C7e6d34307a3642d99cd208d9600095
> 14%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637646377883265
> 554%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=CCOwD%2Bah2tRbrw
> zENSiREVaiFV2wpZqwjosP5LFCi9E%3Dreserved=0 and
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchi
> ve.ietf.org%2Farch%2Fmsg%2Fnetmod%2FOrJYk01en82VVG-
> 

Re: [Anima] Iotdir early review of draft-ietf-anima-brski-prm-05

[Fries, Steffen]

Hi Marco,

Thank you for the early review, I made my comments to yours inline. 

> -Original Message-
> From: Marco Tiloca via Datatracker 
> Sent: Donnerstag, 22. Dezember 2022 14:33
> To: iot-director...@ietf.org
> Cc: anima@ietf.org; draft-ietf-anima-brski-prm@ietf.org
> Subject: Iotdir early review of draft-ietf-anima-brski-prm-05
> 
> Reviewer: Marco Tiloca
> Review result: Ready with Nits
> 
> [Section 3.1]
> 
> * "Once a pledge with such combined functionality has been bootstrapped, it
> may act as client for enrollment or re-enrollment of further certificates
> needed, e.g., using the enrollment protocol of choice."
> 
>Considering the normative words used in the previous paragraph for a
> pledge
>with combined functionalities, I would have expected the use of "MAY"
> here
>about a pledge-initiated enrollment. Is the use of the non-normative "may"
>intentional?
Yes you are right. We should consequently to the preceding paragraph also use 
MAY here. Will adapt this. 

> [Section 3.2]
> 
> * "The mechanism described in this document presume the availability of the
> pledge to communicate with the registrar-agent."
> 
>The last sentence in the paragraph says that "the registrar-agent is
>similarly presumed to be unavailable for certain periods of time".
>Consistently, the first sentence quoted above can already suggest that
>point, instead of focusing on the pledge only. E.g., it can say:
> 
>"The mechanism described in this document presumes the availability of
> the
>pledge and the registrar-agent to communicate with one another."
Yes, taken. 


> [Section 4]
> 
> * "A POI is also required for the certification request and therefore needs to
> be additionally bound to the existing credential of the pledge (IDevID)."
> 
>The subject of "needs" is the certification request, right?
Yes, enhanced the sentence for clarity to: 
" A POI is also required for the certification request and therefore the 
certification request needs to be additionally bound to the existing credential 
of the pledge (IDevID)."

> * "This binding supports the authorization decision for the certification
> request may be provided directly with the certification request."
> 
>I am not sure how to parse this sentence. It think you mean "... for the
>certification request and may be provided ...". Correct?
Yes, updated as suggested

> 
> * "... based on COSE [RFC9052]"
> 
>I think it is appropriate to cite also RFC 9053.
Yes, certainly. Included in the text and as additional reference.


> [Section 5.1]
> 
> * "enhances existing with new supported media types, e.g., for JWS
> voucher"
> 
>What is existing and enhanced? Data exchanges and messages, or instead
>endpoints again?
Yes, it was intended to enhance the endpoints. 
Corrected accordingly to " enhances existing endpoints with new supported media 
types, e.g., for JWS voucher "


> 
> [Section 5.1]
> 
> * "The registrar-agent may provide additional data to the pledge in the
> context of the voucher triggering request, to make itself visible to the
> domain registrar."
> 
>Could you elaborate on this, perhaps through an example? How does this
> help
>the registrar-agent to make itself visible to the domain registrar?
Okay, after rereading the sentence, it may be misleading. The intention was to 
allow the registrar to realize with which registrar-agent the pledge was in 
contact. 
I will reformulate that sentence to make that clearer and also make the may 
normative. Updated bullet:
" The registrar-agent MAY provide additional data to the pledge in the context 
of the voucher triggering request, that the pledge includes into the PVR. This 
allows the registrar to identify, with which registrar-agent the pledge was in 
contact."

> 
>Isn't visibility a general issue between Registrar Agent and Domain
>Registrar, for which the specific Pledge does not play a role?
Yes, as stated above, the intention was to allow the registrar to know, with 
which registrar agent the pledge was in contact.
 
> 
> * "The registrar-agent may be implemented as an integrated functionality of
> a commissioning tool or be co-located with the registrar itself."
> 
>This feels like something quite important to say already in Section 1
>"Introduction".
Good point. I moved that sentence to the first bullet in the introduction.

> 
> [Section 6.2]
> 
> * "Registrar-agent: possesses ... In addition, it may possess the IDevID CA
> certificate of the pledge vendor/manufacturer to verify the pledge certificate
> in the received request messages."
> 
>Consistently with what is said later on about the MASA, I think that the
>sentence above should also better use the normative "MAY".
Agreed, changed to "MAY"

> 
> [Section 6.2.2]
> 
> * "If the validation fails the registrar SHOULD respond with HTTP 404 Not
> Found status code to the registrar-agent."
> 
>Why 404? The registrar has been processing the 

Re: [Anima] Secdir review of draft-ietf-anima-brski-prm-05

[Fries, Steffen]

Hi Charlie,

I'm resending the message as I realized it did not go to the ANIMA WG list.

Thank you for the review of BRSKI-PRM. I addressed the points you identified.  
All of them were easy to address. 
By rereading the review comments, I thought about your  statement "The protocol 
is more elaborate that I would have thought necessary, but I could
find no problems with it.". Is there anything we could improve in the approach 
itself or the description, which caught your eye? 

We restructured the document a while ago to make it better readable and aligned 
it with experiences gained from the implementation. If there is anything we can 
improve in the specification, which you feel would help better understanding, 
please let us know. Also, if you think that optimizations in the protocol 
itself could be done to reduce complexity, would also be interesting.  Based on 
the current state of the document (before WGLC), changes could still be done.

Best regards
Steffen

> -Original Message-
> From: Charlie Kaufman 
> Sent: Montag, 5. Dezember 2022 08:22
> To: sec...@ietf.org; i...@ietf.org; draft-ietf-anima-brski-prm@ietf.org
> Subject: Secdir review of draft-ietf-anima-brski-prm-05
> 
> Reviewer: Charlie Kaufman
> Review result: Has nits
> 
> I have reviewed this document as part of the security directorate's ongoing
> effort to review all IETF documents being processed by the IESG.  These
> comments were written primarily for the benefit of the security area
> directors.  Document editors and WG chairs should treat these comments just
> like any other last call comments.
> 
> This Standards Track ID extends a family of protocols for limited function
> devices to obtain certificates from their surrounding environment with the
> assistance of an on-line manufacturer's authority that can authenticate
> information as coming from their device. It extends the BRSKI (RFC8995)
> protocol to deal with devices that prefer to accept incoming initialization
> requests rather than initiating outbound requests. It does this be defining a 
> new
> node called a "registrar-agent" that acts as a client to both the 
> to-be-registered
> "pledge" and the domain registrar.
> 
> The protocol is more elaborate that I would have thought necessary, but I 
> could
> find no problems with it.
> 
> Typos:
> p1 "To establishment the" -> "To establish the"
> p4 "In this scenarios it is" -> "In this scenario it is"
> p5 "defined i this" -> "defined in this"
> p8 "as describe in" -> "as described in"
> p8 "it SHOULD initiate to that Registrar" --- initiate what? a request? a
> connection?
> p9 "This operational parameters" -> "These operational parameters"
> p9 "presume the" -> "presumes the"
> p11 "constraint environments" -> "constrained environments"
> p12 "endpoints were the" -> "endpoints where the"
> p12 "endpoints were additional" -> "endpoints where additional"
> p45 "a manufactures pledge" -> "a manufacturer's pledge"
> p64 "on misusage" -> "of misuse"
> p64 "an registrar-agent" -> "a registrar-agent"
> p64 "rouge" -> "rogue"
> 
> 
> 
> 

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Yangdoctors early review of draft-ietf-anima-brski-prm-05

[Fries, Steffen]

Hi Martin,

Thank your for your effort to come up with the concrete example. This certainly 
illustrates the approach better. I made some inline note to your points

> -Original Message-
> From: Martin Björklund 
> Sent: Mittwoch, 7. Dezember 2022 08:50
> To: mcr+i...@sandelman.ca
> Cc: yang-doct...@ietf.org; anima@ietf.org; draft-ietf-anima-brski-
> prm@ietf.org
> Subject: Re: Yangdoctors early review of draft-ietf-anima-brski-prm-05
> 
> Michael Richardson  wrote:
> >
> > Thank you very much for the review.
> >
> > Martin Björklund via Datatracker  wrote:
> > > From a YANG perspective, this module is quite simple and looks good.  
> > The
> only
> > > thing you should change is to use sx:structure (from RFC 8791) 
> > instead of
> > > rc:yang-data.
> >
> > yes, but we need to do this across the entire set of documents.
> 
> I don't think this is necessary.
> 
> > We have an RFC8366bis in progress anyway, so the timing is right.
> 
> Ok, if you do 8366bis, then it makes sense to change it to use sx:structure.  
> (Side
> note: if you do this, I would also suggest you look into splitting the 
> grouping into
> several groupings; it seems 8995 wanted to reuse parts of the current 
> grouping).
> 
> 
> >
> > > However, you wrote in the request for the review "we would want to use
> this
> > > document as the spearhead for resolving our issue of augmenting 
> > rfc8366
> YANG".
> > > I have read the thread on the netmod mailing list, but I am not sure I
> > > understand the problem correctly.  In the ML thread, there was the
> example of
> > > two independent modules that augmented RFC8366:
> >
> > > module B adds some leafs to RFC8366
> > > module C adds some leafs to RFC8366
> >
> > And then Module D wishes to inherit from B and C :-)
> 
> "inherit from" is quite generic; I would need to see a detailed example of the
> definitions you envision in B, C and D to give guidelines.
> 
> > In practical terms, this would be a constrained version of PRM.
> > (combining draft-ietf-anima-constrained-voucher +
> > draft-ietf-anima-brski-prm)
> >
> > > But if the intention is to add leafs to the *existing* structure 
> > defined in RFC
> > > 8366 ("voucher-artifact"), then this approach doesn't work.
> >
> > We do this today in RFC8995 with augment.
> 
> No, 8995 defines a *new* structure; it doens't add to the existing one.
> 
> Perhaps an example can clarify what what I mean.  Here's an example of some
> instance data as modelled by RFC 8366:
> 
>{
>  "ietf-voucher:voucher": {
>"created-on": "2016-10-07T19:31:42Z",
>"assertion": "logged",
>"serial-number": "JADA123456789",
>"idevid-issuer": "base64encodedvalue==",
>"pinned-domain-cert": "base64encodedvalue==",
>"nonce": "base64encodedvalue=="
>  }
>}
> 
> An eample of instance data that matches the RFC 8995 style of defining a *new*
> strucure could look like this:
> 
>{
>  "ietf-voucher-request:voucher": {
>"created-on": "2016-10-07T19:31:42Z",
>"assertion": "proximity",
>"serial-number" : "JADA123456789",
>"nonce": "base64encodedvalue==",
>"proximity-registrar-cert": "base64encodedvalue=="
> }
>   }
> 
> If instead we wanted to *add* to the exisitng structure in RFC 8366, it could
> have looked like this:
> 
>{
>  "ietf-voucher:voucher": {
>"created-on": "2016-10-07T19:31:42Z",
>"assertion": "proximity",
>"serial-number" : "JADA123456789",
>"nonce": "base64encodedvalue==",
>"ietf-voucher-request:proximity-registrar-cert": "base64encodedvalue=="
> }
>   }
> 
> (Note that this is hypothetical; it is not possible to do this with the 
> current RFC
> 8366, since it uses rc:yang-data).
This is important to know, as the intention with the augmentation was to extend 
the voucher with additional values as you did in the example above. 
> 
> Now, lets assume we have antother module "ietf-B", which is independent of
> "ietf-voucher-request", that also wants to add a leaf (say "contact") to the
> voucher.  An example of instance data could look like this:
> 
>{
>  "ietf-voucher:voucher": {
>"created-on": "2016-10-07T19:31:42Z",
>"assertion": "proximity",
>"serial-number" : "JADA123456789",
>"nonce": "base64encodedvalue==",
>"ietf-voucher-request:proximity-registrar-cert": 
> "base64encodedvalue==",
>"ietf-b:contact": "j...@example.com"
> }
>   }
One question here regarding the voucher-request. In BRSKI-PRM, we have an 
extension of the voucher-request, which should be used additionally to the 
definitions in RFC 8995. In the structure above,  you added  
"ietf-voucher-request:proximity-registrar-cert": "base64encodedvalue=="
which is defined in RFC 8995. 
In BRSKI we have enhancements of the voucher-request with further parameters. 
Lets take "agent-provided-proximity-registrar-cert". 

Re: [Anima] ANIMA agenda for IETF115 posted

[Fries, Steffen]

Hi Toerless,

It would be good to have JWS-Voucher and BRSKI-PRM next to each other as 
BRSKI-PRM utilizes JWS-Voucher.

Thank you,
Steffen

From: Anima  on behalf of Toerless Eckert 

Sent: Thursday, October 27, 2022 4:26:30 AM
To: anima@ietf.org 
Cc: anima-cha...@ietf.org 
Subject: [Anima] ANIMA agenda for IETF115 posted

As usual, i have used notes.ietf.org for the agenda, please see:

https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fnotes.ietf.org%2Fs%2Fnotes-ietf-115-animadata=05%7C01%7Csteffen.fries%40siemens.com%7C28d13ff77a1c4a99610408dab7c2b0ca%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638024344075773350%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=3n7ZTWlSGGqCfgWN9TfV66pU5A%2BqHJSYdRH%2FkdXlEj0%3Dreserved=0

Pls. check if your request for a slot was correctly honored, if not, please get 
back to us chairs immediately.

I have sent a separate email to those with WG drafts for which no slot has been 
requested.

Toerless - for the chairs

___
Anima mailing list
Anima@ietf.org
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fanimadata=05%7C01%7Csteffen.fries%40siemens.com%7C28d13ff77a1c4a99610408dab7c2b0ca%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638024344075773350%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=%2BSlHgVqfzxuo8trLfK16I5P2kkO13wBMJCQ%2FiB6AwWY%3Dreserved=0
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

[Anima] FW: New Version Notification for draft-ietf-anima-brski-prm-05.txt

[Fries, Steffen]

Hello all, 

We just uploaded an updated version of BRSKI-PRM (05). This version addresses 
the issues raised during several reviews on the anima github, specifically:

- Restructured document to have a distinct section for the object flow and 
handling and shortened introduction, issue #72
- Added security considerations for using mDNS without a specific 
product-serial-number, issue #75
- Clarified pledge-status responses are cumulative, issue #73
- Removed agent-sign-cert from trigger data to save bandwidth and remove 
complexity through options, issue #70
- Changed terminology for LDevID(Reg) certificate to registrar EE certificate, 
as it does not need to be an LDevID, issue #66
- Added new protected header parameter (created-on) in PER to support freshness 
validation, issue #63
- Removed reference to CAB Forum as not needed for BRSKI-PRM specifically, 
issue #65
- Enhanced error codes in section 5.5.1, issue #39, #64
- Enhanced security considerations and privacy considerations, issue #59
- Issue #50 addressed by referring to the utilized enrollment protocol
- Issue #47 MASA verification of LDevID(RegAgt) to the same registrar EE 
certificate domain CA
- Reworked terminology of "enrollment object", "certification object", 
"enrollment request object", etc., issue #27
- Reworked all message representations to align with encoding
- Added explanation of MASA requiring domain CA cert in section 5.5.1 and 
section 5.5.2, issue #36
- Defined new endpoint for pledge bootstrapping status inquiry, issue #35 in 
section Section 6.4, IANA considerations and section Section 5.3
- Included examples for several objects in section Appendix A including message 
example sizes, issue #33
- PoP for private key to registrar certificate included as mandatory, issues 
#32 and #49
- Issue #31, clarified that combined pledge may act as client/server for 
further (re)enrollment
- Issue #42, clarified that Registrar needs to verify the status responses with 
and ensure that they match the audit log response from the MASA, otherwise it 
needs drop the pledge and revoke the certificate
- Issue #43, clarified that the pledge shall use the create time from the 
trigger message if the time has not been synchronized, yet.
- Several editorial changes and enhancements to increasing readability.

It is planned to discuss the latest status during IETF 115 and to determine the 
next steps. Technically it is stable and implemented as PoC. 

Best regards
Steffen



-Original Message-
From: internet-dra...@ietf.org  
Sent: Montag, 24. Oktober 2022 18:08
To: Michael C. Richardson ; Eliot Lear ; 
Michael Richardson ; Fries, Steffen (T CST) 
; Werner, Thomas (T CST SEA-DE) 

Subject: New Version Notification for draft-ietf-anima-brski-prm-05.txt


A new version of I-D, draft-ietf-anima-brski-prm-05.txt has been successfully 
submitted by Steffen Fries and posted to the IETF repository.

Name:   draft-ietf-anima-brski-prm
Revision:   05
Title:  BRSKI with Pledge in Responder Mode (BRSKI-PRM)
Document date:  2022-10-24
Group:  anima
Pages:  86
URL:
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-anima-brski-prm-05.txtdata=05%7C01%7Csteffen.fries%40siemens.com%7Cfa1af9d28b494243d26108dab5da2fe5%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638022245956985418%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=gKBTkm9SA1r4cGbYVXx8m2C3Pl6Pq2bGAbnbSGiKNNQ%3Dreserved=0
Status: 
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-anima-brski-prm%2Fdata=05%7C01%7Csteffen.fries%40siemens.com%7Cfa1af9d28b494243d26108dab5da2fe5%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638022245956985418%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=yFbYJ48gaQuTZ2ijjpalcFZmDOedu%2Fpb9AzwSMA0RqI%3Dreserved=0
Htmlized:   
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-anima-brski-prmdata=05%7C01%7Csteffen.fries%40siemens.com%7Cfa1af9d28b494243d26108dab5da2fe5%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638022245956985418%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=hAn%2BbXrb2ZTU8sk6MlQYq5I%2BOq3aJlkRz9cJ%2FFspD9E%3Dreserved=0
Diff:   
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-anima-brski-prm-05data=05%7C01%7Csteffen.fries%40siemens.com%7Cfa1af9d28b494243d26108dab5da2fe5%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638022245956985418%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=kxxEe%2F1hpShd7k0Q3U0eeQZpqa%2Br2RsHSpTFQB0vCb8%3Dreserved=0

Abstract:
   This

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

[Fries, Steffen]

Hi Toerless, hi Sheng,

We would like to give an update on the following drafts (in that order):
 
Topic/Title: JWS signed Voucher Artifacts for Bootstrapping Protocols
Name of Presenter(s): Thomas Werner
Length of time requested: 5 Minutes
If applicable: name of draft(s) discussed: draft-ietf-anima- jws-voucher-05 
(will be provided before deadline)

Topic/Title: BRSKI with Pledge in Responder Mode (BRSKI-PRM) 
Name of Presenter(s): Steffen Fries
Length of time requested: 10 Minutes
If applicable: name of draft(s) discussed: draft-ietf-anima-brski-prm-05 (will 
be provided before deadline)

Best regards
Steffen

> -Original Message-
> From: Anima  On Behalf Of Toerless Eckert
> Sent: Montag, 17. Oktober 2022 16:40
> To: anima@ietf.org; anima-cha...@ietf.org
> Subject: [Anima] Call for agenda items/attendance ANIMA @ IETF 115
> 
> Dear ANIMA WG
> 
> With IETF115 agenda being finalized on friday, ANIMA WG will meet at IETF115
> for one 2 hour slot:
> Thursday November 10th, 13:00-15:00 (Session II), Mezzanine 10-11, UTC (this
> time TZ is easy, UTC = local! ;-)
> 
> Please submit your requests for Agenda items in reply to this email, as soon 
> as
> possible.
> official IETF goal is to have agenda available on Octover 26th!
> 
> Note that you do not need to have the slides by the time you're asking for the
> slot!
> 
> Please send requests to anima-cha...@ietf.org.
> Copy anima@ietf.org if you like.
> 
> Topic/Title
> Name of Presenter(s)
> Length of time requested
> If applicable: name of draft(s) discussed
> 
> Also: Once you have your slides, go to:
> 
> 
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatrac
> ker.ietf.org%2Fmeeting%2F115%2Fsession%2Fanimadata=05%7C01%7Cs
> teffen.fries%40siemens.com%7C2a4d126a43894a6e41e608dab04d8cf6%7C38a
> e3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638016144517280024%7CUn
> known%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1
> haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7Csdata=uIJltn%2BvQ88qPu
> z1LkaJA7zyCjMAtTDV5vn9jPuOZwg%3Dreserved=0
> 
> and upload your slides via the "Propose Slides" Button (pick either of the two
> slots as you see fit).
> 
> Please also remember to (re-)start discussing any non-WG adopted work also on
> the anima@ietf.org mailing list to encourage WG members to read your work
> and comment!
> 
> More details about the IETF 115 will be found at:
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf
> .org%2Fhow%2Fmeetings%2F115%2Fdata=05%7C01%7Csteffen.fries%40
> siemens.com%7C2a4d126a43894a6e41e608dab04d8cf6%7C38ae3bcd95794fd4
> addab42e1495d55a%7C1%7C0%7C638016144517280024%7CUnknown%7CTWF
> pbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6
> Mn0%3D%7C2000%7C%7C%7Csdata=do5glSQCZUiEz7lJRT5mXnBTgYuZ%
> 2BFe5AOJ1ZqXjy6Q%3Dreserved=0
> as soon as the agenda requests fill up.
> 
> ANIMA WG Chairs, Toerless/Sheng
> 
> ___
> Anima mailing list
> Anima@ietf.org
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf
> .org%2Fmailman%2Flistinfo%2Fanimadata=05%7C01%7Csteffen.fries%4
> 0siemens.com%7C2a4d126a43894a6e41e608dab04d8cf6%7C38ae3bcd95794fd
> 4addab42e1495d55a%7C1%7C0%7C638016144517280024%7CUnknown%7CTW
> FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI
> 6Mn0%3D%7C2000%7C%7C%7Csdata=hZG6%2BgCongoi8UBW7PPz%2B
> Nsn8xP1RiZV9ynk%2B4%2Bx0lM%3Dreserved=0

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] comments on anima-brski-prm

[Fries, Steffen]

Hi Michael,

Thank you again for the review and the proposed changes. I meanwhile included 
your proposed changes and also addressed most of the issues you raised. The 
results have been captured n the github discussion of open issues 
(https://github.com/anima-wg/anima-brski-prm/issues). The newest version is 
also available in this github.
The remaining open issues are for discussion tomorrow in the Design Team. Most 
of them are already prepared. 

Best regards
Steffen

> -Original Message-
> From: Anima  On Behalf Of Fries, Steffen
> Sent: Dienstag, 20. September 2022 15:08
> To: Michael Richardson ; anima@ietf.org
> Subject: Re: [Anima] comments on anima-brski-prm
> 
> Hi Michael,
> 
> I put my comments inline.
> 
> Best regards
> Steffen
> 
> > -Original Message-
> > From: Anima  On Behalf Of Michael Richardson
> > Sent: Montag, 19. September 2022 17:50
> > Subject: [Anima] comments on anima-brski-prm
> >
> > I should remind people that git hates trailing whitespace, and please
> > configure your editors to remove.  I use emacs, and I have some code I
> > use, but most editors now have an option.  So some diffs you may see
> > are just trailing space removal, which I guess I could have done on
> main/master.
> I'll keep this in mind ;-)
> 
> >
> > I made a whole bunch of small editorial fixes, which I collected at:
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> >
> ub.co%2Fdata=05%7C01%7Csteffen.fries%40siemens.com%7C28dece81
> 9008
> >
> 432aa88508da9b091efb%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%
> 7C6379
> >
> 92760717697707%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ
> QIjoiV2l
> >
> uMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=c
> %2B%2FP
> > pAIGKEXRss90QdiDk%2BoLYwnJ8ewkdtpF6IOXyLw%3Dreserved=0
> > m%2Fanima-wg%2Fanima-brski-
> >
> prm%2Fpull%2F76data=05%7C01%7Csteffen.fries%40siemens.com%7C1
> >
> e3b4e1da3b64d7c39c608da9a56a8c2%7C38ae3bcd95794fd4addab42e1495d55
> >
> a%7C1%7C0%7C637991995576757266%7CUnknown%7CTWFpbGZsb3d8eyJWIj
> >
> oiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C200
> >
> 0%7C%7C%7Csdata=BInW0h%2BcDEGeYEKXrsPC9bH5lulIeO3NFsC7fiRSO
> > Eo%3Dreserved=0
> > (I didn't make all those changes on the 18th, there was a rebase in
> > the middle) You may find that the rich diff at:
> >
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> >
> ub.co%2Fdata=05%7C01%7Csteffen.fries%40siemens.com%7C28dece81
> 9008
> >
> 432aa88508da9b091efb%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%
> 7C6379
> >
> 92760717697707%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ
> QIjoiV2l
> >
> uMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=c
> %2B%2FP
> > pAIGKEXRss90QdiDk%2BoLYwnJ8ewkdtpF6IOXyLw%3Dreserved=0
> > m%2Fanima-wg%2Fanima-brski-
> > prm%2Fpull%2F76%2Ffiles%3Fshort_path%3D39089b2%23diff-
> >
> 39089b29400b74ce53b0f9b46cc0e8c08434b3518372da2bb356646768a1d56e&
> >
> amp;data=05%7C01%7Csteffen.fries%40siemens.com%7C1e3b4e1da3b64d7c39
> >
> c608da9a56a8c2%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637
> >
> 991995576757266%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLC
> >
> JQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C
> >
> sdata=D8HognvCph6bT2gaA9FyNfTV%2BBLO0Mgg5uBakmVGbgc%3Dres
> > erved=0
> > provides for easier review.
> > In many cases I just split up long paragraphs into more digestable parts.
> >
> Thanks, that definitely increases readability.
> 
> > ** If it would help discussion for me to split these up into a bunch
> > of separate
> > ** pull requests, I can do that.
> >
> > I tweaked many of the diagrams so that aasvg would produce beautiful
> > HTML/PDF.
> Didn't know that, but it definitely looks better.
> 
> >
> > I also opened the following issues:
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> >
> ub.co%2Fdata=05%7C01%7Csteffen.fries%40siemens.com%7C28dece81
> 9008
> >
> 432aa88508da9b091efb%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%
> 7C6379
> >
> 92760717697707%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ
> QIjoiV2l
> >
> uMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=c
> %2B%2FP
> > pAIGKEXRss90QdiDk%2BoLYwnJ8ewkdtpF6IOXyLw%3Dreserved=0
> > m%2Fanima-wg%2Fanima-brski-
> >
> prm%2Fissues%2F75data=05%7C01%7Csteffen.fries%40siemens.com%7
> >
> C1e3b4e1da3b64d7c39c608da9a56a8c2%7C38ae3bcd95794fd4addab42e1495d
> > 55a%7C1%7C0%7C637991995576913478%7CUnknown%7CTWFp

Re: [Anima] comments on anima-brski-prm

[Fries, Steffen]

Hi Michael,

I put my comments inline.

Best regards
Steffen

> -Original Message-
> From: Anima  On Behalf Of Michael Richardson
> Sent: Montag, 19. September 2022 17:50
> Subject: [Anima] comments on anima-brski-prm
> 
> I should remind people that git hates trailing whitespace, and please 
> configure
> your editors to remove.  I use emacs, and I have some code I use, but most
> editors now have an option.  So some diffs you may see are just trailing space
> removal, which I guess I could have done on main/master.
I'll keep this in mind ;-)

> 
> I made a whole bunch of small editorial fixes, which I collected at:
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co
> m%2Fanima-wg%2Fanima-brski-
> prm%2Fpull%2F76data=05%7C01%7Csteffen.fries%40siemens.com%7C1
> e3b4e1da3b64d7c39c608da9a56a8c2%7C38ae3bcd95794fd4addab42e1495d55
> a%7C1%7C0%7C637991995576757266%7CUnknown%7CTWFpbGZsb3d8eyJWIj
> oiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C200
> 0%7C%7C%7Csdata=BInW0h%2BcDEGeYEKXrsPC9bH5lulIeO3NFsC7fiRSO
> Eo%3Dreserved=0
> (I didn't make all those changes on the 18th, there was a rebase in the 
> middle)
> You may find that the rich diff at:
> 
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co
> m%2Fanima-wg%2Fanima-brski-
> prm%2Fpull%2F76%2Ffiles%3Fshort_path%3D39089b2%23diff-
> 39089b29400b74ce53b0f9b46cc0e8c08434b3518372da2bb356646768a1d56e&
> amp;data=05%7C01%7Csteffen.fries%40siemens.com%7C1e3b4e1da3b64d7c39
> c608da9a56a8c2%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637
> 991995576757266%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLC
> JQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C
> sdata=D8HognvCph6bT2gaA9FyNfTV%2BBLO0Mgg5uBakmVGbgc%3Dres
> erved=0
> provides for easier review.
> In many cases I just split up long paragraphs into more digestable parts.
> 
Thanks, that definitely increases readability.

> ** If it would help discussion for me to split these up into a bunch of 
> separate
> ** pull requests, I can do that.
> 
> I tweaked many of the diagrams so that aasvg would produce beautiful
> HTML/PDF.
Didn't know that, but it definitely looks better. 

> 
> I also opened the following issues:
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co
> m%2Fanima-wg%2Fanima-brski-
> prm%2Fissues%2F75data=05%7C01%7Csteffen.fries%40siemens.com%7
> C1e3b4e1da3b64d7c39c608da9a56a8c2%7C38ae3bcd95794fd4addab42e1495d
> 55a%7C1%7C0%7C637991995576913478%7CUnknown%7CTWFpbGZsb3d8eyJ
> WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C
> 2000%7C%7C%7Csdata=kIownLfpv8NHsWec0QlDX6JGe%2BSYY7LPKwDx
> XIV%2BPoE%3Dreserved=0: misuse of mDNS
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co
> m%2Fanima-wg%2Fanima-brski-
> prm%2Fissues%2F74data=05%7C01%7Csteffen.fries%40siemens.com%7
> C1e3b4e1da3b64d7c39c608da9a56a8c2%7C38ae3bcd95794fd4addab42e1495d
> 55a%7C1%7C0%7C637991995576913478%7CUnknown%7CTWFpbGZsb3d8eyJ
> WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C
> 2000%7C%7C%7Csdata=b3kAxL1qQi9869RrZI9KGxQ7rD6cDBkBJXwT4ACo
> o7k%3Dreserved=0: what is the threat for registrar-agent mis-use
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co
> m%2Fanima-wg%2Fanima-brski-
> prm%2Fissues%2F73data=05%7C01%7Csteffen.fries%40siemens.com%7
> C1e3b4e1da3b64d7c39c608da9a56a8c2%7C38ae3bcd95794fd4addab42e1495d
> 55a%7C1%7C0%7C637991995576913478%7CUnknown%7CTWFpbGZsb3d8eyJ
> WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C
> 2000%7C%7C%7Csdata=PiIO9RNg6aYPgBScPHL%2BqNiyllVtTg9kgGfwL%
> 2F8UTjI%3Dreserved=0: pledge-status responses are cumullative right?
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co
> m%2Fanima-wg%2Fanima-brski-
> prm%2Fissues%2F72data=05%7C01%7Csteffen.fries%40siemens.com%7
> C1e3b4e1da3b64d7c39c608da9a56a8c2%7C38ae3bcd95794fd4addab42e1495d
> 55a%7C1%7C0%7C637991995576913478%7CUnknown%7CTWFpbGZsb3d8eyJ
> WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C
> 2000%7C%7C%7Csdata=lPJkOeKI%2FrMTIT3kdwoYH09opqZzcGWP19zPZ
> EgzEzc%3Dreserved=0: section 5.5 is foreshadowed/repeated
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co
> m%2Fanima-wg%2Fanima-brski-
> prm%2Fissues%2F71data=05%7C01%7Csteffen.fries%40siemens.com%7
> C1e3b4e1da3b64d7c39c608da9a56a8c2%7C38ae3bcd95794fd4addab42e1495d
> 55a%7C1%7C0%7C637991995576913478%7CUnknown%7CTWFpbGZsb3d8eyJ
> WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C
> 2000%7C%7C%7Csdata=o4ofsd6h0Ee8o7FTSTCjw0oqRMNChuttyUyot%2
> BkzdyU%3Dreserved=0: more tweaks need for ts diagram
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co
> m%2Fanima-wg%2Fanima-brski-
> prm%2Fissues%2F70%3Awhydata=05%7C01%7Csteffen.fries%40siemens.
> com%7C1e3b4e1da3b64d7c39c608da9a56a8c2%7C38ae3bcd95794fd4addab42
> 

Re: [Anima] [netmod] mcr's YANG question raised during the ANIMA WG session

[Fries, Steffen]

Hi Jan,

Thank you for the help. Based on your example I crafted another version of the 
BRSKI-PRM voucher request with a grouping containing only the additional 3 
fields needed in BRSKI-PRM, which is then used to augment the original voucher. 

We have to do some further testing to see if it works out.

Best regards
Steffen

> -Original Message-
> From: Anima  On Behalf Of Jan Lindblad
> Sent: Freitag, 5. August 2022 10:41
> To: Michael Richardson 
> Cc: Anima@ietf.org; net...@ietf.org
> Subject: Re: [Anima] [netmod] mcr's YANG question raised during the ANIMA
> WG session
> 
> Michael,
> 
> Comments inline.
> 
> > On 5 Aug 2022, at 01:01, Michael Richardson  wrote:
> >
> > Thank you for very much for the reply.
> >
> > Jan Lindblad  wrote:
> >> I had a look at your test example. The example is invalid, but pyang
> >> fails to detect the error and overwrites some internal structures,
> >> with the result below. The root cause of the problem is this:
> >
> > ...
> >
> >> Each one of the two uses statement brings in a "container voucher"
> >> (with partly different content) at this point in the schema. That is
> >> an attempt at a duplicate definition of voucher, which is an error.
> >
> > okay, so it partly works, which is an error, and I'll see if I can
> > make that into a test case for pyang.
> 
> Very good.
> 
> > BUT:
> >   The goal is exactly to be able to combine two extensions to RFC8366 into a
> >   new module that has both extensions.  Is there another way to do this?
> >
> > Puting them into two containers does not accomplish the goal, because
> > now you have two expires-on, ...
> 
> Of course. I just added the containers to show that pyang could understand the
> modules once the modeling error was removed. Just to clarify what was going
> on.
> 
> >> Pyang
> >> misses this, and overwrites one voucher object with the next, losing
> >> some of the content.
> >
> >> By placing the two uses statements into separate containers, pyang is
> >> able to successfully make a tree:
> >
> > ...
> >
> >> Normally in YANG, it wouldn't be hard to to let modules "B" and "C"
> >> augment module "A" independently. But here you are working with
> >> groupings in such a way that both "B" and "C" build up a complete
> >> grouping with everything in "A". When "D" tries to use both "B" and
> >> "C", there is inevitably unwanted duplication.
> >
> >> If instead, "B" and "C"
> >> just defined their little contributions, "D" could import groupings
> >> from "A", "B" and "C" and compose them as desired.
> >
> > The reason I am asking this question now, and proposing this example
> > now, is so that if there is a better way to build "B" and "C" then we
> > need to know about that *now*
> >
> > I see that you have proposed a different way, which I will attempt to
> > work through.  Fortunately, we still have time to fix some things.
> 
> Feel free to reach out offline for discussion and review.
> 
> Best Regards,
> /jan
> 
> ___
> Anima mailing list
> Anima@ietf.org
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf
> .org%2Fmailman%2Flistinfo%2Fanimadata=05%7C01%7Csteffen.fries%4
> 0siemens.com%7Cc6d32de3502f4fb9a11d08da76be46cc%7C38ae3bcd95794fd4
> addab42e1495d55a%7C1%7C0%7C637952856978140952%7CUnknown%7CTWF
> pbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6
> Mn0%3D%7C3000%7C%7C%7Csdata=6RbTSa19uWUc8EqPVSiGCmkEjLwj
> Y8eq18K1uXn5kn0%3Dreserved=0

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] [netmod] mcr's YANG question raised during the ANIMA WG session

[Fries, Steffen]

Hi Jan,

Thank you for the test.


From: Anima  On Behalf Of Jan Lindblad
Sent: Donnerstag, 4. August 2022 12:23
To: Michael Richardson 
Cc: Anima@ietf.org; net...@ietf.org
Subject: Re: [Anima] [netmod] mcr's YANG question raised during the ANIMA WG 
session

Michael,

I had a look at your test example. The example is invalid, but pyang fails to 
detect the error and overwrites some internal structures, with the result 
below. The root cause of the problem is this:

module ietf-voucher-D {
...
  uses b:voucher-request-prm-grouping {
augment "voucher" { }
  }

  uses c:voucher-request-constrained-grouping {
augment "voucher" { }
  }
}
Each one of the two uses statement brings in a "container voucher" (with partly 
different content) at this point in the schema. That is an attempt at a 
duplicate definition of voucher, which is an error. Pyang misses this, and 
overwrites one voucher object with the next, losing some of the content.

By placing the two uses statements into separate containers, pyang is able to 
successfully make a tree:

module: ietf-voucher-D
  +--rw x1
  |  +--rw voucher
  | +--rw created-on?yang:date-and-time
  | +--rw expires-on?yang:date-and-time
  | +--rw assertion? enumeration
  | +--rw serial-number  string
  | +--rw idevid-issuer? binary
  | +--rw pinned-domain-cert?binary
  | +--rw domain-cert-revocation-checks? boolean
  | +--rw nonce? binary
  | +--rw last-renewal-date? yang:date-and-time
  | +--rw prior-signed-voucher-request?  binary
  | +--rw proximity-registrar-cert?  binary
  | +--rw agent-signed-data? binary
  | +--rw agent-provided-proximity-registrar-cert?   binary
  | +--rw agent-sign-cert*   binary
  +--rw x2
 +--rw voucher
+--rw created-on?yang:date-and-time
+--rw expires-on?yang:date-and-time
+--rw assertion  enumeration
+--rw serial-number  string
+--rw idevid-issuer? binary
+--rw pinned-domain-cert?binary
+--rw domain-cert-revocation-checks? boolean
+--rw nonce? binary
+--rw last-renewal-date? yang:date-and-time
+--rw proximity-registrar-pubk?  binary
+--rw proximity-registrar-pubk-sha256?   binary
+--rw proximity-registrar-cert?  binary
+--rw prior-signed-voucher-request?  binary

Normally in YANG, it wouldn't be hard to to let modules "B" and "C" augment 
module "A" independently. But here you are working with groupings in such a way 
that both "B" and "C" build up a complete grouping with everything in "A". When 
"D" tries to use both "B" and "C", there is inevitably unwanted duplication. If 
instead, "B" and "C" just defined their little contributions, "D" could import 
groupings from "A", "B" and "C" and compose them as desired.

[stf] Just to be sure, you said you would recommend to avoid the "use" 
statement, which leads to duplication when creating "D". I understand this for 
the inclusion case.
If we use voucher B stand alone without the "use" statement wouldn't we miss  a 
part of the voucher? Or would you recommend to move the use out of the grouping?

Regards
Steffen


Best Regards,
/jan

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] mcr's YANG question raised during the ANIMA WG session

[Fries, Steffen]

Hi Toerless

> -Original Message-
> From: Toerless Eckert 
> Sent: Dienstag, 2. August 2022 02:09
> Let me rephrase to make clear i understand.
> 
> We've got (A) BRSKI, and (B) and (C) two "independent" amendmentds
> driven as independent RFCs. And neither (B) has (C) as reference, nor vice
> versa, but both refer only to (A).
No, the current status of the voucher/voucher request amends like this for 
BRSKI-PRM:
RFC8366 (base voucher definition) -> (A) RFC 8995 (BRSKI definition of voucher 
request)  -> (B) BRSKI-PRM (includes additional fields for the registrar-agent)

> 
> When a user wants to build product incorporating (A), (B), (C), i am sure
> there is something we could have done wrong in (B), (C) so you can not build
> an (A) amended by both (B) and (C). Worst case
> (B) and (C) do conflicting amendmends by amending with the same names.
At least for BRSKI-PRM we initially had reproduced what was stated in RFC 8995, 
but after the review comments we changed it to directly use RFC8995 defined 
voucher request and only amend the additional fields. So we have a clear 
dependency on RFC 8995, which is fine in general, as BRSKI-PRM was intended as 
enhancement.

> Which i guess we can safely exclude, but is that really the only thing that 
> can
> go awry ?
> 
> But lets assume we're past the "conflict" stage, and know the right way to
> amend without conflict:
> 
> How much value is then in duplicating these amendmends into rfc8366bis ?
I did not assume that the amendments would go into RFC8366bis. The main point 
for the RFC8366bis changes from may understanding were reasoned by the enum 
used for the assertions. There was a proposal to change it. 

> I guess we could amend (A), (B) and (C) in it if we wanted to, without
> changing the semantic (and optional aspects) of what was added in (A), (B)
> (C) ? And if we can do it, we should do it after (B), (C) became (RFC, just to
> pull all stuff together ?
At least BRSKI-PRM depends on the changes in RFC8366bis to be able to use the 
assertion "agent-proximity". Regarding the amendments I currently don't see a 
value in pulling it all together as they are specified in different documents. 

Best regards
Steffen



> 
> Cheers
> Toerless
> 
> On Fri, Jul 29, 2022 at 10:03:05AM -0400, Michael Richardson wrote:
> >
> > Fries, Steffen  wrote:
> > > Thank you for the clarification. This means we don't have to change
> > > anything in either BRSKI-PRM and constraint voucher, resp. in the
> > > general approach we use the voucher.
> >
> > Yes!
> > I was worred that there were dragons in the future, but seems not.
> >
> > --
> > Michael Richardson , Sandelman Software
> Works
> > -= IPv6 IoT consulting =-
> >
> >
> >
> 
> 
> 
> --
> ---
> t...@cs.fau.de

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] mcr's YANG question raised during the ANIMA WG session

[Fries, Steffen]

Hi Michael,

Thank you for the clarification. This means we don't have to change anything in 
either BRSKI-PRM and constraint voucher, resp. in the general approach we use 
the voucher.

Best regards
Steffen

> -Original Message-
> From: Anima  On Behalf Of Michael Richardson
> Sent: Donnerstag, 28. Juli 2022 20:46
> To: Anima@ietf.org
> Cc: net...@ietf.org
> Subject: Re: [Anima] mcr's YANG question raised during the ANIMA WG
> session
> 
> 
> A-> B
>  \  .
>   \  .
>\  .
> V  V
> C . . . . > D
> 
> 
> I had lunch with Rob today and explained the situation.
> There are two answers!
> 
> If D is a new YANG module (/RFC) that wants to
>  augment B
> and  augment C
> 
> then it just works, and it's okay to say:
>  augment "B" {}
>  augment "C" {}
> 
> I was worried that this would *not* allowed.
> 
> i.e. D might not even add anything, although maybe it refines existing
>  things.
> 
> There is, however, another way to build a "D" that does not add anything,
> which is using
> 
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatat
> racker.ietf.org%2Fdoc%2Fdraft-ietf-netmod-yang-
> packages%2Fdata=05%7C01%7Csteffen.fries%40siemens.com%7C2f6
> a2caab69a45c5813308da70c97c84%7C38ae3bcd95794fd4addab42e1495d55a%
> 7C1%7C0%7C637946307930928893%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi
> MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C300
> 0%7C%7C%7Csdata=WIU6YlA2s%2BXi9%2FBOH3qvTq7R4f2JYAdXh8p5
> P%2BKXDVQ%3Dreserved=0
> 
> In the context of ANIMA, A=>rfc8366, B=>brski-prm, C=>constrained-
> voucher.
> D=>a mythical constrianed-brski-prm.  Whether or not D needs an RFC
> because it creates new semantics is a different question.  {It might need an
> RFC for trade agreement reasons though}
> 
> 
> --
> Michael Richardson , Sandelman Software Works
> -= IPv6 IoT consulting =-
> 
> 

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] mcr's YANG question raised during the ANIMA WG session

[Fries, Steffen]

Hi Michael,

> -Original Message-
> From: Michael Richardson 
> Sent: Mittwoch, 27. Juli 2022 16:50
> To: Fries, Steffen (T CST) ; Anima@ietf.org
> Subject: Re: [Anima] mcr's YANG question raised during the ANIMA WG
> session
> 
> 
> Fries, Steffen  wrote:
> > I've got a question to the YANG question you raised in the ANIMA WG
> > meeting yesterday. You said you would like to have some expert review
> > on the usage of YANG in the BRSKI related documents regarding data at
> > rest. Are you targeting the usage of YANG modules in BRSKI in general
> 
> I'm asking a high-level question about how we are augmenting things.
> I will prepare a better email for Benoit and/or Rob and netmod... but the
> short of it:
> 
> We have created RFC8366 yang voucher
> We have then derived RFC8995 voucher request.
> We then have derived brski-prm voucher.
> 
> At the same time, we have constrained-voucher voucher derived from
> RFC8366.
> 
> If we want to have a brski-prm+constrained-voucher, are we doing that the
> right way?
> 
> Here is a diagram:
> 
>A->B
>\  .
> \  .
>  \  .
>   V  V
>   C . . . . > D
> 
> If we want D to augment from two origins (B and C), does that even work?
> Or does D have to augment A again, repeating the additions that B and C did?
Okay, understood. Valid question. With addressing the comment from Esko we were 
getting rid of the redo from RFC 8995, but that does not prevent others from 
doing it. So yes, important point. 

> I will see if I can have this conversation in person using the technology of
> back-of-napkins.
Looking forward 
Best regards
Steffen
> 
> 
> --
> Michael Richardson , Sandelman Software Works
> -= IPv6 IoT consulting =-
> 
> 

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

[Anima] mcr's YANG question raised during the ANIMA WG session

[Fries, Steffen]

Hi Michael,

I've got a question to the YANG question you raised in the ANIMA WG meeting 
yesterday. You said you would like to have some expert review on the usage of 
YANG in the BRSKI related documents regarding data at rest. Are you targeting 
the usage of YANG modules in BRSKI in general or was it more directed in the 
way we utilize and combine the YANG modules in the different drafts, like RFC 
8995 defines an enhancement of the voucher defined in RFC 8366. BRSKI-PRM 
utilizes the RFC 8995 voucher (request) and augments it further?
My understanding was the later but maybe the question was more general.

Best regards
Steffen
--
Steffen Fries
Siemens AG


___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

[Anima] FW: New Version Notification for draft-ietf-anima-brski-prm-04.txt

[Fries, Steffen]

Hi all, 

I just submitted an update of BRSKI-PRM (04). It addresses several of the 
comments we received from Esko's review and some more: 
   * addressed  #41, #48, #49, #32
   * addressed issue #40, 58, 57, 56, 52
* addressed issues #60, 30, 29, 38, 37, 34, 30, 24, 25, 26, 28, 53
   *  Simplified YANG definition by augmenting the voucher request from RFC 
8995 instead of redefining it.
   *  Added explanation for terminology "endpoint" used in this document, issue 
#16
   *  Added clarification that registrar-agent may collect PVR or PER or both 
in one run, issue #17
   *  Added a statement that nonceless voucher may be accepted, issue #18
   *  Simplified structure in section Section 3.1, issue #19
   *  Removed join proxy in Figure 1 and added explanatory text, issue #20
   *  Added description of pledge-CAcerts endpoint plus further handling
  of providing a wrapped CA certs response to the pledge in section
  Section 5.5.3; also added new required registrar endpoint (section
  Section 5.5.2 and IANA considerations) for the registrar to
  provide a wrapped CA certs response, issue #21
   *  utilized defined abbreviations in the document consistently, issue#22
   *  Reworked text on discovery according to issue #23 to clarify scope and 
handling
   *  Added several clarifications based on review comments

We will address the remaining issues in the next version of the document. 

Best regards
Steffen
-Original Message-
From: internet-dra...@ietf.org  
Sent: Freitag, 8. Juli 2022 17:21
To: Michael C. Richardson ; Eliot Lear ; 
Michael Richardson ; Fries, Steffen (T CST) 
; Werner, Thomas (T CST SEA-DE) 

Subject: New Version Notification for draft-ietf-anima-brski-prm-04.txt


A new version of I-D, draft-ietf-anima-brski-prm-04.txt has been successfully 
submitted by Steffen Fries and posted to the IETF repository.

Name:   draft-ietf-anima-brski-prm
Revision:   04
Title:  BRSKI with Pledge in Responder Mode (BRSKI-PRM)
Document date:  2022-07-08
Group:  anima
Pages:  61
URL:
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-anima-brski-prm-04.txtdata=05%7C01%7Csteffen.fries%40siemens.com%7C99e6df4cdb294b1a50ba08da60f57a12%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637928904745433420%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=PwQR0lY%2FglpGlvUjmQY6sWHXOj9ZygM0VPqwN87VP0o%3Dreserved=0
Status: 
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-anima-brski-prm%2Fdata=05%7C01%7Csteffen.fries%40siemens.com%7C99e6df4cdb294b1a50ba08da60f57a12%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637928904745433420%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=zSqZkfcbIYoBFgv3GYXwr7Ds6sZCbAJfDUWezexVCWg%3Dreserved=0
Htmlized:   
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-anima-brski-prmdata=05%7C01%7Csteffen.fries%40siemens.com%7C99e6df4cdb294b1a50ba08da60f57a12%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637928904745433420%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=8UnQMS9eh1WN0yJHWtw%2Bex7e%2BKQrAiJ3FYlms13IYPE%3Dreserved=0
Diff:   
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-anima-brski-prm-04data=05%7C01%7Csteffen.fries%40siemens.com%7C99e6df4cdb294b1a50ba08da60f57a12%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637928904745433420%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=INvov4I0Dy83Zj04QH2uTlbKmzQeyqsmRqKEv4I%2BBs8%3Dreserved=0

Abstract:
   This document defines enhancements to bootstrapping a remote secure
   key infrastructure (BRSKI, [RFC8995]) to facilitate bootstrapping in
   domains featuring no or only timely limited connectivity between a
   pledge and the domain registrar.  It specifically targets situations,
   in which the interaction model changes from a pledge-initiator-mode,
   as used in BRSKI, to a pledge-responder-mode as described in this
   document.  To support both, BRSKI-PRM introduces a new registrar-
   agent component, which facilitates the communication between pledge
   and registrar during the bootstrapping phase.  For the establishment
   of a trust relation between pledge and domain registrar, BRSKI-PRM
   relies on the exchange of authenticated self-contained objects
   (signature-wrapped objects).  The defined approach is agnostic
   regarding the utilized enrollment protocol, deployed by the domain
   registrar to communicate with the Domain CA.


  


The IETF S

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

[Fries, Steffen]

Hi Sheng, hi Toerless,

I would like to ask for slots for a status update for the following WG 
documents:


Topic/TitleBRSKI-AE

Name of Presenter(s)Steffen Fries / David von Oheimb

Length of time requested10 Minutes

If applicable: name of draft(s) discussed: BRSKI-AE: Alternative Enrollment 
Protocols in BRSKI,

 https://datatracker.ietf.org/doc/html/draft-ietf-anima-brski-async-enroll



Topic/TitleJWS-voucher

Name of Presenter(s)Steffen Fries / Thomas Werner

Length of time requested5 Minutes

If applicable: name of draft(s) discussed: JWS signed Voucher Artifacts for 
Bootstrapping Protocols, 
https://datatracker.ietf.org/doc/html/draft-ietf-anima-jws-voucher



Topic/TitleBRSKI-PRM

Name of Presenter(s)Steffen Fries

Length of time requested10 Minutes

If applicable: name of draft(s) discussed: BRSKI with Pledge in Responder 
Mode (BRSKI-PRM), https://datatracker.ietf.org/doc/draft-ietf-anima-brski-prm/

Best regards
Steffen

From: Anima  On Behalf Of Sheng Jiang
Sent: Donnerstag, 7. Juli 2022 14:29
To: anima@ietf.org; anima-cha...@ietf.org
Subject: [Anima] Call for agenda items/attendance ANIMA @ IETF 114


Dear ANIMA WG



As you may know, ANIMA WG will meet at IETF114 for one 2 hour slot:

  July 25th, 15:00-17:00 Monday Session III, in Philadelphia local time, UTC 
-4. .





Please submit your requests for Agenda items in reply to this email,

as early as possible, so that we can upload an agenda as early as we can.



Note that you do not need to have the slides by the time you're

asking for the slot!



Please send requests to anima-cha...@ietf.org.

Copy anima@ietf.org if you like.



Topic/Title

Name of Presenter(s)

Length of time requested

If applicable: name of draft(s) discussed



Also: Once you have your slides, go to:



  
https://datatracker.ietf.org/meeting/114/session/anima



and upload your slides via the "Propose Slides" Button

(pick either of the two slots as you see fit).



Please also remember to (re-)start discussing any non-WG adopted

work also on the anima@ietf.org mailing list to 
encourage WG

members to read your work and comment!



More details about the IETF 114 can be found at:

https://www.ietf.org/how/meetings/114/



ANIMA WG Chairs, Toerless/Sheng
Sheng Jiang
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] BRSKI-PRM first review comments / remaining review comments

[Fries, Steffen]

Hi Esko,

Thank you for the careful review. We will address as most as possible of the 
comments before the cutoff date before IETF114 and will discuss the more 
technical items via the mailing list/github.

Thank you also for the offer to support with Pull requests. Highly appreciated.

Best regards
Steffen

From: Anima  On Behalf Of Esko Dijk
Sent: Mittwoch, 29. Juni 2022 11:41
To: Fries, Steffen (T CST) ; Anima@ietf.org
Subject: Re: [Anima] BRSKI-PRM first review comments / remaining review comments

Hi everyone,

In the past weeks I've continued my review and now created more Github issues 
(#22 - #60, see 
https://github.com/anima-wg/anima-brski-prm/issues?q=is%3Aissue+author%3AEskoDijk<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fanima-wg%2Fanima-brski-prm%2Fissues%3Fq%3Dis%253Aissue%2Bauthor%253AEskoDijk=05%7C01%7Csteffen.fries%40siemens.com%7Cde0f23de120d47b89f3508da59b391ed%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637920925780180544%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=8IV%2B%2BtzDoS3o80CYSozyKFhS1RLSt%2BFEgfeS2er11hs%3D=0>)
 for items that may require discussion.
Thanks to Steffen and Thomas for starting to resolve these already before I 
manage to announce my own review :)

Overall, the PRM approach looks good & useful although a sort of "reality 
check" would be good to do for using the protocol over low-data links like BLE 
/ NFC. For that I've created issue #33 
(https://github.com/anima-wg/anima-brski-prm/issues/33<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fanima-wg%2Fanima-brski-prm%2Fissues%2F33=05%7C01%7Csteffen.fries%40siemens.com%7Cde0f23de120d47b89f3508da59b391ed%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637920925780180544%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=%2FiT2jaVp3pxH37mtRdxLY%2B0FDZ4%2B2hKPEUd%2BaJJLPdA%3D=0>).
Will the waiting times for the operator of the hand-held registrar-agent be 
still roughly acceptable, given the data sizes of the multiple messages that 
need to be exchanged?

When the issues are resolved I can also contribute a Pull Request with some 
readability improvements and nit fixes.

Best regards
Esko


IoTconsultancy.nl  |  Email/Teams: 
esko.d...@iotconsultancy.nl<mailto:esko.d...@iotconsultancy.nl>


From: Anima mailto:anima-boun...@ietf.org>> On Behalf 
Of Fries, Steffen
Sent: Thursday, June 9, 2022 08:58
To: Anima@ietf.org<mailto:Anima@ietf.org>
Subject: [Anima] BRSKI-PRM first review comments

Hi all,

We've got the first comments from the BRSKI-PRM peer review from Esko. Thanks 
for doing the review.
I've included them as issue #16-21 on the anima github 
(https://github.com/anima-wg/anima-brski-prm/issues<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fanima-wg%2Fanima-brski-prm%2Fissues=05%7C01%7Csteffen.fries%40siemens.com%7Cde0f23de120d47b89f3508da59b391ed%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637920925780180544%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=5SWos%2FOuDWtcNLwPE5pQgPzp%2BsCHBKmfYFs7ht3rM98%3D=0>).
Some of them relate to clarifications of the BRSKI-PRM functionality (e.g., 
usage of nonceless voucher to support offline MASA) and the architectural 
clarifications (e.g., Join Proxy not necessary) They will be addressed in the 
next version of the draft. We will continue using githab to collect the 
comments and also the resolution discussion and provide the information via the 
mailing list.

Best regards
Steffen
--
Steffen Fries
Siemens AG

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

[Anima] BRSKI-PRM first review comments

[Fries, Steffen]

Hi all,

We've got the first comments from the BRSKI-PRM peer review from Esko. Thanks 
for doing the review.
I've included them as issue #16-21 on the anima github 
(https://github.com/anima-wg/anima-brski-prm/issues).
Some of them relate to clarifications of the BRSKI-PRM functionality (e.g., 
usage of nonceless voucher to support offline MASA) and the architectural 
clarifications (e.g., Join Proxy not necessary) They will be addressed in the 
next version of the draft. We will continue using githab to collect the 
comments and also the resolution discussion and provide the information via the 
mailing list.

Best regards
Steffen
--
Steffen Fries
Siemens AG


___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

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

[Fries, Steffen]

Hi all,

We just submitted an update to BRSKI-PRM. The main changes include the 
following:
* Updated examples to state "base64encodedvalue==" for x5c occurrences
* reference to external PNG graphic as general overview (was recommended in the 
last IETF meeting)
* Restructuring of section 5 to flatten hierarchy
* Enhanced requirements and motivation in Section 4
* Several editorial improvements based on review comments

Feedback to the submitted version is appreciated. The draft is technically 
stable and needs further commenting.

Best regards
Steffen

-Original Message-
From: internet-dra...@ietf.org  
Sent: Freitag, 29. April 2022 13:16
To: Michael C. Richardson ; Eliot Lear ; 
Michael Richardson ; Fries, Steffen (T CST) 
; Werner, Thomas (T CST SEA-DE) 

Subject: New Version Notification for draft-ietf-anima-brski-prm-03.txt


A new version of I-D, draft-ietf-anima-brski-prm-03.txt has been successfully 
submitted by Steffen Fries and posted to the IETF repository.

Name:   draft-ietf-anima-brski-prm
Revision:   03
Title:  BRSKI with Pledge in Responder Mode (BRSKI-PRM)
Document date:  2022-04-29
Group:  anima
Pages:  59
URL:
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-anima-brski-prm-03.txtdata=05%7C01%7Csteffen.fries%40siemens.com%7Ca352eede1a0446d4eeff08da29d1a736%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637868278601261155%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=laV%2FL3TR3v9U3Nf0gy84rOlmiEfeO2ciMUtFwuXiU%2FI%3Dreserved=0
Status: 
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-anima-brski-prm%2Fdata=05%7C01%7Csteffen.fries%40siemens.com%7Ca352eede1a0446d4eeff08da29d1a736%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637868278601261155%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=iXzW2SptHamSawpQsYpDHMOyuEkW8xdIhwXUYC7UBsI%3Dreserved=0
Htmlized:   
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-anima-brski-prmdata=05%7C01%7Csteffen.fries%40siemens.com%7Ca352eede1a0446d4eeff08da29d1a736%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637868278601261155%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=UKfyxSUnGKQf9Y4b9XZCaQ%2B%2F0o3FZZUMLr0VtNNv0LY%3Dreserved=0
Diff:   
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-anima-brski-prm-03data=05%7C01%7Csteffen.fries%40siemens.com%7Ca352eede1a0446d4eeff08da29d1a736%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637868278601261155%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=xFe1UiZvknlt5wyLvBmgJtZ1DHx9%2FqmOEp6c7RRYj%2Bw%3Dreserved=0

Abstract:
   This document defines enhancements to bootstrapping a remote secure
   key infrastructure (BRSKI, [RFC8995]) to facilitate bootstrapping in
   domains featuring no or only timely limited connectivity between a
   pledge and the domain registrar.  It specifically targets situations,
   in which the interaction model changes from a pledge-initiator-mode,
   as used in BRSKI, to a pledge-responder-mode as described in this
   document.  To support both, BRSKI-PRM introduces a new registrar-
   agent component, which facilitates the communication between pledge
   and registrar during the bootstrapping phase.  For the establishment
   of a trust relation between pledge and domain registrar, BRSKI-PRM
   relies on the exchange of authenticated self-contained objects
   (signature-wrapped objects).  The defined approach is agnostic
   regarding the utilized enrollment protocol, deployed by the domain
   registrar to communicate with the Domain CA.


  


The IETF Secretariat


___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

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

[Fries, Steffen]

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 provisional accept 
ending.  The
  verification of multiple signatures is described in Section 5.1.4.3
   *  Included representation for General JWS JSON Serialization for examples
   *  Included error responses from pledge if it is not able to create a 
pledge-voucher request or an enrollment request in Section 5.1.4.1
   *  Removed open issue regarding handling of multiple CSRs and enrollment 
responses during the bootstrapping as the initial target it the provisioning of 
a generic LDevID certificate.  The defined endpoint on the pledge may also be 
used for management of further certificates.

Best regards
Steffen

-Original Message-
From: I-D-Announce  On Behalf Of 
internet-dra...@ietf.org
Sent: Freitag, 4. März 2022 14:14
To: i-d-annou...@ietf.org
Cc: anima@ietf.org
Subject: I-D Action: draft-ietf-anima-brski-prm-02.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Autonomic Networking Integrated Model and 
Approach WG of the IETF.

Title   : BRSKI with Pledge in Responder Mode (BRSKI-PRM)
Authors : Steffen Fries
  Thomas Werner
  Eliot Lear
  Michael C. Richardson
Filename: draft-ietf-anima-brski-prm-02.txt
Pages   : 57
Date: 2022-03-04

Abstract:
   This document defines enhancements to bootstrapping a remote secure
   key infrastructure (BRSKI, [RFC8995]) to facilitate bootstrapping in
   domains featuring no or only timely limited connectivity between a
   pledge and the domain registrar.  It specifically targets situations,
   in which the interaction model changes from a pledge-initiator-mode,
   as used in BRSKI, to a pledge-responder-mode as described in this
   document.  To support both, BRSKI-PRM introduces a new registrar-
   agent component, which facilitates the communication between pledge
   and registrar during the bootstrapping phase.  For the establishment
   of a trust relation between pledge and domain registrar, BRSKI-PRM
   relies on the exchange of authenticated self-contained objects
   (signature-wrapped objects).  The defined approach is agnostic
   regarding the utilized enrollment protocol, deployed by the domain
   registrar to communicate with the Domain CA.


The IETF datatracker status page for this draft is:
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-anima-brski-prm%2Fdata=04%7C01%7Csteffen.fries%40siemens.com%7Cd5127a0257fc4e2558d608d9fde0e3fa%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637819964623940923%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=z0kkQqKEu711mK3dwIxdeEXrKw1BFk0lRL5%2FyHDWb8Q%3Dreserved=0

There is also an htmlized version available at:
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-anima-brski-prm-02data=04%7C01%7Csteffen.fries%40siemens.com%7Cd5127a0257fc4e2558d608d9fde0e3fa%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637819964623940923%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=d5A848R0egE%2FDhL0LVXdOomcc22aBFWEnLtxsQv3cOY%3Dreserved=0

A diff from the previous version is available at:
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-anima-brski-prm-02data=04%7C01%7Csteffen.fries%40siemens.com%7Cd5127a0257fc4e2558d608d9fde0e3fa%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637819964623940923%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=285sfbrqPhVZL5SpEdKHyeRlX9luTF3SBl6R68GAOnk%3Dreserved=0


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


___
I-D-Announce mailing list
i-d-annou...@ietf.org
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fi-d-announcedata=04%7C01%7Csteffen.fries%40siemens.com%7Cd5127a0257fc4e2558d608d9fde0e3fa%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637819964623940923%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=Ca2uw1kYwfNrH2Nsw7ikTbfE7VoIHS2RM43MZAbhPEk%3Dreserved=0
Internet-Draft directories: 

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

[Fries, Steffen]

Hi Toreless,

Here also the request for the second BRSKI related slot:

Topic/Title: Status Update on BRSKI-AE
Name of Presenter(s): Steffen Fries/David von Oheimb
Length of time requested: 10 minutes
name of draft(s): draft-ietf-anima-brski-async-enroll-04 (will be version 05 as 
we plan 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/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 the deadline)
> 
> Best regards
> Steffen
> 
> 
> > -Original Message-
> > From: Anima  On Behalf Of t...@cs.fau.de
> > Sent: Dienstag, 22. Februar 2022 17:38
> > To: anima@ietf.org
> > Cc: anima-cha...@ietf.org
> > Subject: [Anima] Call for agenda items/attendance ANIMA @ IETF 113
> >
> > Dear ANIMA WG
> >
> > It is this time of year again!  IETF 113 is coming.
> >
> > ANIMA WG will meet at IETF113 hybrid for one 2 hour slot:
> >   Friday, March 25th, 12:30 - 14:30 Vienna local time (UTC+1).
> >
> > Given how this is the first IETF with an in-person option after two
> > years, it would be great to see many of you in person.
> >
> > Please submit your requests for Agenda items in reply to this email,
> > as early as possible, so that we can upload an agenda more timely than we
> typically do.
> >
> > Note that you do not need to have the slides by the time you're asking
> > for the slot !
> >
> > Please send requests to anima-cha...@ietf.org.
> > Copy anima@ietf.org if you like.
> >
> > Topic/Title
> > Name of Presenter(s)
> > Length of time requested
> > If applicable: name of draft(s) discussed
> >
> > Also: Once you have your slides, go to:
> >
> >
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
> > trac
> >
> ker.ietf.org%2Fmeeting%2F113%2Fsession%2Fanimadata=04%7C01%7Cs
> >
> teffen.fries%40siemens.com%7C274c0803b12d4b343c8708d9f621b8e6%7C38a
> >
> e3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637811447529082984%7CUn
> >
> known%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1
> >
> haWwiLCJXVCI6Mn0%3D%7C3000sdata=%2F8jI%2FhtuN2kIr%2FFd2fzt9
> > %2F2MqzEODEOd2MFiK1l9EtM%3Dreserved=0
> >
> > and upload your slides via the "Propose Slides" Button (pick either of
> > the two slots as you see fit).
> >
> > Please also remember to (re-)start discussing any non-WG adopted work
> > also on the anima@ietf.org mailing list to encourage WG members to
> > read your work and comment!
> >
> > More details about the IETF 113 can be found at:
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> > ietf
> >
> .org%2Fhow%2Fmeetings%2F113%2Fdata=04%7C01%7Csteffen.fries%40
> >
> siemens.com%7C274c0803b12d4b343c8708d9f621b8e6%7C38ae3bcd95794fd4
> >
> addab42e1495d55a%7C1%7C0%7C637811447529082984%7CUnknown%7CTWF
> >
> pbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6
> >
> Mn0%3D%7C3000sdata=ARtxp8RCQDiwwUg44to0nV0FdItvKatSCUc8DxE
> > wJYM%3Dreserved=0
> >
> > ANIMA WG Chairs, Toerless/Sheng
> >
> > ___
> > Anima mailing list
> > Anima@ietf.org
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> > ietf
> >
> .org%2Fmailman%2Flistinfo%2Fanimadata=04%7C01%7Csteffen.fries%4
> >
> 0siemens.com%7C274c0803b12d4b343c8708d9f621b8e6%7C38ae3bcd95794fd
> >
> 4addab42e1495d55a%7C1%7C0%7C637811447529082984%7CUnknown%7CTW
> >
> FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI
> >
> 6Mn0%3D%7C3000sdata=mXxnC7KlVpZsuvUcPmmRf7U8c4i%2BtOQPfo5
> > QIjGMXDc%3Dreserved=0

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

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

[Fries, Steffen]

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 the deadline)

Best regards
Steffen


> -Original Message-
> From: Anima  On Behalf Of t...@cs.fau.de
> Sent: Dienstag, 22. Februar 2022 17:38
> To: anima@ietf.org
> Cc: anima-cha...@ietf.org
> Subject: [Anima] Call for agenda items/attendance ANIMA @ IETF 113
> 
> Dear ANIMA WG
> 
> It is this time of year again!  IETF 113 is coming.
> 
> ANIMA WG will meet at IETF113 hybrid for one 2 hour slot:
>   Friday, March 25th, 12:30 - 14:30 Vienna local time (UTC+1).
> 
> Given how this is the first IETF with an in-person option after two years, it 
> would
> be great to see many of you in person.
> 
> Please submit your requests for Agenda items in reply to this email, as early 
> as
> possible, so that we can upload an agenda more timely than we typically do.
> 
> Note that you do not need to have the slides by the time you're asking for the
> slot !
> 
> Please send requests to anima-cha...@ietf.org.
> Copy anima@ietf.org if you like.
> 
> Topic/Title
> Name of Presenter(s)
> Length of time requested
> If applicable: name of draft(s) discussed
> 
> Also: Once you have your slides, go to:
> 
> 
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatrac
> ker.ietf.org%2Fmeeting%2F113%2Fsession%2Fanimadata=04%7C01%7Cs
> teffen.fries%40siemens.com%7C274c0803b12d4b343c8708d9f621b8e6%7C38a
> e3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637811447529082984%7CUn
> known%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1
> haWwiLCJXVCI6Mn0%3D%7C3000sdata=%2F8jI%2FhtuN2kIr%2FFd2fzt9
> %2F2MqzEODEOd2MFiK1l9EtM%3Dreserved=0
> 
> and upload your slides via the "Propose Slides" Button (pick either of the two
> slots as you see fit).
> 
> Please also remember to (re-)start discussing any non-WG adopted work also on
> the anima@ietf.org mailing list to encourage WG members to read your work
> and comment!
> 
> More details about the IETF 113 can be found at:
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf
> .org%2Fhow%2Fmeetings%2F113%2Fdata=04%7C01%7Csteffen.fries%40
> siemens.com%7C274c0803b12d4b343c8708d9f621b8e6%7C38ae3bcd95794fd4
> addab42e1495d55a%7C1%7C0%7C637811447529082984%7CUnknown%7CTWF
> pbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6
> Mn0%3D%7C3000sdata=ARtxp8RCQDiwwUg44to0nV0FdItvKatSCUc8DxE
> wJYM%3Dreserved=0
> 
> ANIMA WG Chairs, Toerless/Sheng
> 
> ___
> Anima mailing list
> Anima@ietf.org
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf
> .org%2Fmailman%2Flistinfo%2Fanimadata=04%7C01%7Csteffen.fries%4
> 0siemens.com%7C274c0803b12d4b343c8708d9f621b8e6%7C38ae3bcd95794fd
> 4addab42e1495d55a%7C1%7C0%7C637811447529082984%7CUnknown%7CTW
> FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI
> 6Mn0%3D%7C3000sdata=mXxnC7KlVpZsuvUcPmmRf7U8c4i%2BtOQPfo5
> QIjGMXDc%3Dreserved=0

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

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

[Fries, Steffen]

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 
forwarding to the registrar-agent to support verification of POP of the 
registrars private key in section Section 5.1.4.2 and Section 5.1.4.3.
*   Based on issue #11, a new endpoint was defined for the registrar to 
enable delivery of the wrapped enrollment request from the pledge (in contrast 
to plain PKCS#10 in simple enroll).
*   Decision on issue #8 to not provide an additional signature on the 
enrollment-response object by the registrar.  As the enrollment response will 
only contain the generic LDevID EE certificate. This credential builds the base 
for further configuration outside the initial enrollment.
*   Decision on issue #7 to not support multiple CSRs during the 
bootstrapping, as based on the generic LDevID EE certificate the pledge may 
enroll for further certificates.
*   Closed open issue #5 regarding verification of ietf-ztp-types usage as 
verified via a proof-of-concept in section {#exchanges_uc2_1}.
*   Housekeeping: Removed already addressed open issues stated in the draft 
directly.
*   Reworked text in from introduction to section pledge-responder-mode
*   Fixed "serial-number" encoding in PVR/RVR
*   Added prior-signed-voucher-request in the parameter description of the 
registrar-voucher-request in Section 5.1.4.2.
*   Note added in Section 5.1.4.2 if sub-CAs are used, that the 
corresponding information is to be provided to the MASA.
*   Inclusion of limitation section (pledge sleeps and needs to be waken 
up.  Pledge is awake but registrar-agent is not available) (Issue #10).
*   Assertion-type aligned with voucher in RFC8366bis, deleted related open 
issues.  (Issue #4)
*   Included table for endpoints in Section 5.1.2 for better readability.
*   Included registrar authorization check for registrar-agent during TLS 
handshake in section Section 5.1.4.2.  Also enhanced Figure 10 with the 
authorization step on TLS level.
*   Enhanced description of registrar authorization check for 
registrar-agent based on the agent-signed-data in section Section 5.1.4.2.  
Also enhanced figure Figure 10 with the authorization step on 
pledge-voucher-request level.
*   Changed agent-signed-cert to an array to allow for providing further 
certificate information like the issuing CA cert for the LDevID(RegAgt) EE 
certificate in case the registrar and the registrar-agent have different 
issuing CAs in Figure 10 (issue #12).  This also required changes in the YANG 
module in Section 6.1.2
*   Addressed YANG warning (issue #1)
*   Inclusion of examples for a trigger to create a pledge-voucher-request 
and an enrollment-request.

We will work further on aligning the draft with the JWS voucher draft for the 
change in the JSON serialization. This will be included in the next update.

Best regards
Steffen 

-Original Message-
From: Anima  On Behalf Of internet-dra...@ietf.org
Sent: Freitag, 11. Februar 2022 16:45
To: i-d-annou...@ietf.org
Cc: anima@ietf.org
Subject: [Anima] I-D Action: draft-ietf-anima-brski-prm-01.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Autonomic Networking Integrated Model and 
Approach WG of the IETF.

Title   : BRSKI with Pledge in Responder Mode (BRSKI-PRM)
Authors : Steffen Fries
  Thomas Werner
  Eliot Lear
  Michael C. Richardson
Filename: draft-ietf-anima-brski-prm-01.txt
Pages   : 54
Date: 2022-02-11

Abstract:
   This document defines enhancements to bootstrapping a remote secure
   key infrastructure (BRSKI, [RFC8995]) to facilitate bootstrapping in
   domains featuring no or only timely limited connectivity between a
   pledge and the domain registrar.  It specifically targets situations,
   in which the interaction model changes from a pledge-initiator-mode,
   as used in BRSKI, to a pledge-responder-mode as described in this
   document.  To support both, BRSKI-PRM introduces a new registrar-
   agent component, which facilitates the communication between pledge
   and registrar during the bootstrapping phase.  For the establishment
   of a trust relation between pledge and domain registrar, BRSKI-PRM
   relies on the exchange of authenticated self-contained objects
   (signature-wrapped objects).  The defined approach is agnostic
   regarding the utilized enrollment protocol, deployed by the domain
   registrar to communicate with the Domain CA.


The IETF datatracker status page for this draft is:

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

[Fries, Steffen]

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: draft-richardson-anima-rfc8366bis, ends 
December 19th, 2021

Hi, all ANIMAer,

This message starts a two-week adoption call for 
draft-richardson-anima-rfc8366bis, which we have traced a few discussion and 
think the WG is interested in. The adoption call ends December 19th, 2021.


Title:   A Voucher Artifact for Bootstrapping Protocols

Name: draft-richardson-anima-rfc8366bis-04



Authors:  K. Watsen, M. Richardson, M. Pritikin and T. Eckert

URL:  https://datatracker.ietf.org/doc/draft-richardson-anima-rfc8366bis/

IPR:  No IPR disclosures have been submitted directly on 
draft-richardson-anima-voucher-delegation



This document is intended to become a standards track ANIMA WG document.



Please express your support or rejection. If you think this document should 
_not_ be adopted, please also explicitly indicate the reasons.



Regards,


Sheng
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

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

[Fries, Steffen]

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 the 
voucher-request. To my understanding we do not need an augmentation for the 
voucher, as agent-proximity is already included in draft RFC 8366bis.

Did I miss something?

Best regards
Steffen


> -Original Message-
> From: Anima  On Behalf Of Michael Richardson
> Sent: Donnerstag, 2. Dezember 2021 02:05
> To: anima@ietf.org
> Cc: net...@ietf.org
> Subject: Re: [Anima] New Version Notification for draft-richardson-anima-
> rfc8366bis-04.txt
> 
> 
> Name: draft-richardson-anima-rfc8366bis
> 
> Diff:
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf
> .org%2Frfcdiff%3Furl1%3Ddraft-richardson-anima-rfc8366bis-
> 00%26url2%3Ddraft-richardson-anima-rfc8366bis-
> 04data=04%7C01%7Csteffen.fries%40siemens.com%7Ce31fb7323d1949
> a349e208d9b52fd8f7%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C
> 637740039811249891%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD
> AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000sdata=y9
> fmZnQrHPXMIwGCM8uZaV4x5Yg2kdy2LoUjUqxIelY%3Dreserved=0
> 
> I uploaded -01, found some yang errors... I did -02/-03 before I figured out 
> how
> to run the right pyang command myself to determine the source of the error.
> 
> This version has a new iana-voucher-assertion-type which is intended to be
> handed to IANA to maintain.
> I don't think that our IANA Considerations are correct as yet.
> I think that we need a FAQ somewhere.
> 
> In the meantime, I would really like some YANG Doctor help here.
> 
> Toerless: I think that this is the major change.
> 
> Qiufang Ma did the bulk of the YANG work here, and with the blessing of the WG
> chairs, I'd like to add her as a co-author.

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

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

[Fries, Steffen]

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), 
https://datatracker.ietf.org/doc/html/draft-ietf-anima-brski-async-enroll-04
- BRSKI with Pledge in Responder Mode (BRSKI-PRM), 
https://datatracker.ietf.org/doc/html/draft-ietf-anima-brski-prm-00.html

Best regards
Steffen

> -Original Message-
> From: Anima  On Behalf Of t...@cs.fau.de
> Sent: Mittwoch, 27. Oktober 2021 16:59
> To: anima@ietf.org
> Subject: [Anima] Call for agenda items ANIMA @ IETF 112
> 
> Dear ANIMA WG
> 
> It is this time of year again!  The pre-christmas ANIMA session!
> 
> ANIMA WG will meet at IETF112 online for one 2 hour slot:
>   Wednesday November 10, Session 32, 16:00 - 18:00 UTC
> 
> Please submit your requests for Agenda items in reply to this email, as early 
> as
> possible (before next monday really), so that we can upload an agenda more
> timely than we typically do.
> 
> (uploading slides does not need to happen at same time as asking  for slot. 
> Early
> bird slot requester benefits expanded ;-)
> 
> Please send requests to anima-cha...@ietf.org.
> Copy anima@ietf.org if you like.
> 
> Topic/Title
> Name of Presenter(s)
> Length of time requested
> If applicable: name of draft(s) discussed
> 
> Also: Once you have your slides, go to:
> 
> 
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatrac
> ker.ietf.org%2Fmeeting%2F112%2Fsession%2Fanimadata=04%7C01%7Cs
> teffen.fries%40siemens.com%7C1b197fd094264260a5ec08d9995a6110%7C38a
> e3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637709436934803418%7CUn
> known%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1
> haWwiLCJXVCI6Mn0%3D%7C3000sdata=QplQ%2BkaqZ4qdDbuetGi41ZMI
> gK8EuC8iEpjGywDjwpk%3Dreserved=0
> 
> and upload your slides via the "Propose Slides" Button (pick either of the two
> slots as you see fit).
> 
> Please also remember to (re-)start discussing any non-WG adopted work also on
> the anima@ietf.org mailing list to encourage WG members to read your work
> and comment!
> 
> More details about the IETF 112 can be found at:
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf
> .org%2Fhow%2Fmeetings%2F112%2Fdata=04%7C01%7Csteffen.fries%40
> siemens.com%7C1b197fd094264260a5ec08d9995a6110%7C38ae3bcd95794fd4
> addab42e1495d55a%7C1%7C0%7C637709436934803418%7CUnknown%7CTWF
> pbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6
> Mn0%3D%7C3000sdata=RAj%2F8tKnZ8DQu5AqyTURtafCMZWq6XXvz%2B
> x%2FU5MDgV8%3Dreserved=0
> 
> ANIMA WG Chairs, Toerless/Sheng
> 
> ___
> Anima mailing list
> Anima@ietf.org
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf
> .org%2Fmailman%2Flistinfo%2Fanimadata=04%7C01%7Csteffen.fries%4
> 0siemens.com%7C1b197fd094264260a5ec08d9995a6110%7C38ae3bcd95794fd
> 4addab42e1495d55a%7C1%7C0%7C637709436934803418%7CUnknown%7CTW
> FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI
> 6Mn0%3D%7C3000sdata=mVSVDj1aq9Z3Bu9fwaTyHLFjeeq4X7BWHhaW
> bpu1tXI%3Dreserved=0

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

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

[Fries, Steffen]

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
  required changes and adaptations in several sections to remove the
  description and references to UC1.

   *  Addressed feedback for voucher-request enhancements from YANG
  doctor early review in Section 6 as well as in the security
  considerations (formerly named ietf-async-voucher-request).

   *  Renamed ietf-async-voucher-request to IETF-voucher-request-prm to
  to allow better listing of voucher related extensions; aligned
  with constraint voucher (#20)

   *  Utilized ietf-voucher-request-async instead of ietf-voucher-
  request in voucher exchanges to utilize the enhanced voucher-
  request.

   *  Included changes from draft-ietf-netconf-sztp-csr-06 regarding the
  YANG definition of csr-types into the enrollment request exchange.

If you have any comments or remarks, please let us know. We plan to present the 
current state during the next IETF meeting.

Best regards
Steffen

-Original Message-
From: I-D-Announce  On Behalf Of 
internet-dra...@ietf.org
Sent: Montag, 25. Oktober 2021 23:19
To: i-d-annou...@ietf.org
Cc: anima@ietf.org
Subject: I-D Action: draft-ietf-anima-brski-prm-00.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Autonomic Networking Integrated Model and 
Approach WG of the IETF.

Title   : BRSKI with Pledge in Responder Mode (BRSKI-PRM)
Authors : Steffen Fries
  Thomas Werner
  Eliot Lear
  Michael C. Richardson
Filename: draft-ietf-anima-brski-prm-00.txt
Pages   : 46
Date: 2021-10-25

Abstract:
   This document defines enhancements to the bootstrapping a remote
   secure key infrastructure (BRSKI, [RFC8995] ) to facilitate
   bootstrapping in domains featuring no or only timely limited
   connectivity between a pledge and the domain registrar.  This
   specifically targets situations, in which the interaction model
   changes from a pledge-initiator-mode as in BRSKI to a pledge-
   responder-mode as desribed here.  To support this functionality
   BRSKI-PRM introduces a new registrar-agent component, which
   facilitates the communication between pledge and registrar during the
   bootstrapping phase.  To support the establishment of a trust
   relation between a pledge and the domain registrar, BRSKI-PRM relies
   on the exchange of authenticated self-contained objects (signature-
   wrapped objects).  The defined approach is agnostic regarding the
   utilized enrollment protocol, deployed by the registrar to
   communicate with the Domain CA.


The IETF datatracker status page for this draft is:
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-anima-brski-prm%2Fdata=04%7C01%7Csteffen.fries%40siemens.com%7Cb346cd09911e4fa6d6c808d997fd1cac%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637707935638989592%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=JBk1ktTM0RellAqrjba%2Bp1RBqbDn8FkD6pcJrkjTq%2Fk%3Dreserved=0

There is also an htmlized version available at:
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-anima-brski-prm-00data=04%7C01%7Csteffen.fries%40siemens.com%7Cb346cd09911e4fa6d6c808d997fd1cac%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637707935638989592%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=t0Yw9AoZJV5htAtmrkaY8%2FVjLLTiUtCUWnr3JuXhkIY%3Dreserved=0


Internet-Drafts are also available by anonymous FTP at:
https://eur01.safelinks.protection.outlook.com/?url=ftp%3A%2F%2Fftp.ietf.org%2Finternet-drafts%2Fdata=04%7C01%7Csteffen.fries%40siemens.com%7Cb346cd09911e4fa6d6c808d997fd1cac%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637707935638989592%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=%2FOEE0EKSZ%2BVx8lN8oY%2B64mFAUok6Ewc4Tc11KXR%2BbDM%3Dreserved=0


___
I-D-Announce mailing list
i-d-annou...@ietf.org
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fi-d-announcedata=04%7C01%7Csteffen.fries%40siemens.com%7Cb346cd09911e4fa6d6c808d997fd1cac%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637707935638989592%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=1e6EBV3iv97wfNmtV0ub84XU3g0DfeWo58LGBTU6u0o%3Dreserved=0
Internet-Draft directories: 

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

[Fries, Steffen]

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 will provide an overview and the way forward during the upcoming IETF 112

Best regards
Steffen

-Original Message-
From: I-D-Announce  On Behalf Of 
internet-dra...@ietf.org
Sent: Montag, 25. Oktober 2021 11:49
To: i-d-annou...@ietf.org
Cc: anima@ietf.org
Subject: I-D Action: draft-ietf-anima-brski-async-enroll-04.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Autonomic Networking Integrated Model and 
Approach WG of the IETF.

Title   : Support of Asynchronous Enrollment in BRSKI (BRSKI-AE)
Authors : Steffen Fries
  Hendrik Brockhaus
  David von Oheimb
  Eliot Lear
Filename: draft-ietf-anima-brski-async-enroll-04.txt
Pages   : 27
Date: 2021-10-25

Abstract:
   This document describes enhancements of bootstrapping a remote secure
   key infrastructure (BRSKI, [RFC8995] ) to also operate in domains
   featuring no or only timely limited connectivity between involved
   components.  To support such use cases, BRSKI-AE relies on the
   exchange of authenticated self-contained objects (signature-wrapped
   objects) also for requesting and distributing of domain specific
   device certificates.  The defined approach is agnostic regarding the
   utilized enrollment protocol allowing the application of existing and
   potentially new certificate management protocols.


The IETF datatracker status page for this draft is:
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-anima-brski-async-enroll%2Fdata=04%7C01%7Csteffen.fries%40siemens.com%7C5dd0e564c17e42e6700608d9979ccf58%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637707522025390216%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=wHsMcqBIYrj3Z9%2FN0jTfg91pWxFCO91oPDgNgvfkgDM%3Dreserved=0

There is also an htmlized version available at:
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-anima-brski-async-enroll-04data=04%7C01%7Csteffen.fries%40siemens.com%7C5dd0e564c17e42e6700608d9979ccf58%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637707522025390216%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=U5AXotLIb7ukJcMtVlnqCPiCYFjxYEyI%2Bmn5oG893hY%3Dreserved=0

A diff from the previous version is available at:
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-anima-brski-async-enroll-04data=04%7C01%7Csteffen.fries%40siemens.com%7C5dd0e564c17e42e6700608d9979ccf58%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637707522025390216%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=EgvCiI%2FDvq5zzek7LYxX2CZ1E59ThnXWBVzKIM8DMb0%3Dreserved=0


Internet-Drafts are also available by anonymous FTP at:
https://eur01.safelinks.protection.outlook.com/?url=ftp%3A%2F%2Fftp.ietf.org%2Finternet-drafts%2Fdata=04%7C01%7Csteffen.fries%40siemens.com%7C5dd0e564c17e42e6700608d9979ccf58%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637707522025390216%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=FycpxnmKtpFEEmGrSdMfZipfPkFwkYyzr%2F4g%2B%2BI5m1Y%3Dreserved=0


___
I-D-Announce mailing list
i-d-annou...@ietf.org
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fi-d-announcedata=04%7C01%7Csteffen.fries%40siemens.com%7C5dd0e564c17e42e6700608d9979ccf58%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637707522025390216%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=nrlHxf1uBd%2Fekt4nv5eANDBtHQs1%2BIUWFWaLCDnaPs8%3Dreserved=0
Internet-Draft directories: 
https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.ietf.org%2Fshadow.htmldata=04%7C01%7Csteffen.fries%40siemens.com%7C5dd0e564c17e42e6700608d9979ccf58%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637707522025390216%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=QdMONK7aYpf2fDjpAanYhnPANyjSA78Z47s502%2F%2FBa8%3Dreserved=0
or 

Re: [Anima] BRSKI-AE document split discussion

[Fries, Steffen]

Hello,

After the discussion in the design team meeting today, we agreed in this round 
on the naming of the two documents which aligns with the proposal sent in the 
previous email. This would result in
-  "Support of asynchronous Enrollment in BRSKI (BRSKI-AE)": covering the 
application of alternative enrollment protocols as this was the initially 
described use case 1. It will cover the description of utilizing other 
enrollment protocol than EST in general and using Lightweight CMP specifically.
- "BRSKI with Pledge in Responder Mode (BRSKI-PRM)", covering the communication 
between the pledge and the registrar by reversing the initiator and responder 
role of the pledge (compared to RFC 8995). It will reflect UC2 f the original 
document with the registrar-agent as facilitator for the communication.

Are there any objections regarding these names for the two documents?

We also discussed about proposed authors for the two documents. 
The following authors are on the current draft (version 03):
  - S. Fries, H. Brockhaus, T. Werner, Siemens
  - E. Lear, Cisco Systems

There are changes proposed  based on the involvement into the single use cases. 
Proposed authors 
- BRSKI-AE: 
- D.v. Oheimb, S. Fries, H. Brockhaus, Siemens
- E. Lear, Cisco Systems
- BRSKI-RPM:
- S. Fries, T. Werner, Siemens
- E. Lear, Cisco Systems
- M. Richardson, Sandelman Software Works

Are there any objections regarding the changes in the list of authors?

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-
> From: Fries, Steffen (T RDA CST)
> Sent: Donnerstag, 14. Oktober 2021 09:05
> To: anima@ietf.org
> Cc: Michael Richardson ; Eliot Lear
> ; Werner, Thomas (T RDA CST SEA-DE)  wer...@siemens.com>; Brockhaus, Hendrik (T RDA CST SEA-DE)
> 
> Subject: RE: [Anima] BRSKI-AE document split discussion
> 
> Hello,
> 
> Based on the split discussion we started with the naming of the two resulting
> documents. I put the current proposals under issue #19
> (https://github.com/anima-wg/anima-brski-async-enroll/issues/19) on the
> github. The proposal there is as following:
> 
> - UC1 is proposed to stay as "BRSKI-AE" covering the application of
> alternative enrollment protocols as this was the initially described use case 
> .
> It will cover the description of utilizing other enrollment protocol than EST 
> in
> general and using Lightweight CMP specifically.
> - UC2 is proposed to become "BRSKI with Pledge in Responder Mode (BRSKI-
> PRM)", as it addresses the communication between the pledge and the
> registrar by reversing the initiator and responder role (compared to RFC
> 8995) also introducing the registrar-agent as facilitator for the
> communication.
> 
> We would like to discuss this in the 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
> > Cc: Michael Richardson ; anima@ietf.org; Eliot
> > Lear ; Werner, Thomas (T RDA CST SEA-DE)  > wer...@siemens.com>; Brockhaus, Hendrik (T RDA CST SEA-DE)
> > 
> > Subject: Re: [Anima] BRSKI-AE document split discussion
> >
> > Hi Toerless,
> >
> > Thank you for the positive info regarding the draft split and your
> > concrete proposal about the way forward with the documents and the
> > concrete questions to be answered. That also helps to identify
> > potential missing information.
> >
> > We will go ahead and discuss the split (content, authors, ...) in the
> > round of current authors and will also provide proposals regarding the
> > naming. The plan is to have separate issues in gitlab per draft and
> > send them both to the mailing list once created for further discussion.
> >
> > We still think the approach with two documents is sufficient as also
> > the informative part about the use cases can be clearly separated. As
> > UC2 reverses the role of the pledge from initiator to responder the
> > application can be motivated using different examples. That said,
> > working on both in parallel should be possible. We will try to keep
> > the informative part 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
> >
> >
&g

Re: [Anima] BRSKI-AE document split discussion

[Fries, Steffen]

Hello,

Based on the split discussion we started with the naming of the two resulting 
documents. I put the current proposals under issue #19 
(https://github.com/anima-wg/anima-brski-async-enroll/issues/19) on the github. 
The proposal there is as following:

- UC1 is proposed to stay as "BRSKI-AE" covering the application of alternative 
enrollment protocols as this was the initially described use case . It will 
cover the description of utilizing other enrollment protocol than EST in 
general and using Lightweight CMP specifically.
- UC2 is proposed to become "BRSKI with Pledge in Responder Mode (BRSKI-PRM)", 
as it addresses the communication between the pledge and the registrar by 
reversing the initiator and responder role (compared to RFC 8995) also 
introducing the registrar-agent as facilitator for the communication.

We would like to discuss this in the 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
> Cc: Michael Richardson ; anima@ietf.org; Eliot
> Lear ; Werner, Thomas (T RDA CST SEA-DE)  wer...@siemens.com>; Brockhaus, Hendrik (T RDA CST SEA-DE)
> 
> Subject: Re: [Anima] BRSKI-AE document split discussion
> 
> Hi Toerless,
> 
> Thank you for the positive info regarding the draft split and your concrete
> proposal about the way forward with the documents and the concrete
> questions to be answered. That also helps to identify potential missing
> information.
> 
> We will go ahead and discuss the split (content, authors, ...) in the round of
> current authors and will also provide proposals regarding the naming. The
> plan is to have separate issues in gitlab per draft and send them both to the
> mailing list once created for further discussion.
> 
> We still think the approach with two documents is sufficient as also the
> informative part about the use cases can be clearly separated. As UC2
> reverses the role of the pledge from initiator to responder the application
> can be motivated using different examples. That said, working on both in
> parallel should be possible. We will try to keep the informative part 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) 
> > Cc: Michael Richardson ; Werner, Thomas (T
> RDA
> > CST
> > SEA-DE) ; anima@ietf.org
> > Subject: Re: [Anima] BRSKI-AE document split discussion
> >
> > Steffen, *:
> >
> > AFAIK, we should not need any new adoption call for splitting up the
> > document as long as we do not change the scope of the new documents to
> > be in summary not different to what the WG has already agreed to work on
> for BRSKI-AE.
> > And i think all work is within that WG adopted scope. But i've reached
> > out to others to check if this statement is correc.
> >
> > I think splitting up makes a lot of sense to help accelerate the process.
> >
> > The split into one draft for use-case 1 and anothrer for use-case 2 is
> > fine, but not the only option you could consier (see below). If you
> > want to do that split, i think both resulting drafts should be standards 
> > track.
> >
> > For example for use-case 1:
> >
> > I) the normative part (if i understand your target right) is really
> > the requirements for pledges and registrars to support
> >   a) the pre-EST part of BRSKI (but no need to support the EST part,
> >  and likely also not some other details like ACP requirements...
> > TBD detail work).
> >   b) lightweight CMP according to (draft-lamps - probably multiple)
> >   c) transfering state from a) to b) (aka: using the keying material from
> >  a) for b). Figure out which option is MTI, e.g.: same https connection,
> >  or rather https for BRSKI then http for lightweight CMP (probably thats
> >  the safest/easiest requirement ?).
> >   d) likely a specific profile for the discovery part between pledge and
> >  registrar (you just want mDNS ? forgot...).
> >   e) transport: Are we fine with MUST-ONLY IPv6, no IPv4 ?
> >
> > The core output is that client/registrars that implemen ONLY the MUST
> > parts of this spec MUST interoperate ;-)
> >
> > So this is actually good and hopefully logically simple, but in thre
> > deteals of MUST/SHOULD/MAY good p

Re: [Anima] BRSKI-AE document split discussion

[Fries, Steffen]

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 provide proposals regarding the
> > naming. The plan is to have separate issues in gitlab per draft and
> > send them both to the mailing list once created for further discussion.
> 
> The MT makefiles support having multiple drafts in the same github repo, but
> you could also just fork the repo.
> I suggest that it may be simpler to fork the repo, because then we'll be more
> clear about which issue is for which document.
> 
> But, you could go the other way too if you thought that many issues would be
> cross-document.
Forking the repo is probably the best way forward.

Best regards
Steffen

> 
> 
> --
> Michael Richardson. o O ( IPv6 IøT consulting )
>Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
> 

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] BRSKI-AE document split discussion

[Fries, Steffen]

Hi Toerless, 

Thank you for the positive info regarding the draft split and your concrete 
proposal about the way forward with the documents and the concrete questions to 
be answered. That also helps to identify potential missing information.

We will go ahead and discuss the split (content, authors, ...) in the round of 
current authors and will also provide proposals regarding the naming. The plan 
is to have separate issues in gitlab per draft and send them both to the 
mailing list once created for further discussion. 

We still think the approach with two documents is sufficient as also the 
informative part about the use cases can be clearly separated. As UC2 reverses 
the role of the pledge from initiator to responder the application can be 
motivated using different examples. That said, working on both in parallel 
should be possible. We will try to keep the informative part 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) 
> Cc: Michael Richardson ; Werner, Thomas (T RDA CST
> SEA-DE) ; anima@ietf.org
> Subject: Re: [Anima] BRSKI-AE document split discussion
> 
> Steffen, *:
> 
> AFAIK, we should not need any new adoption call for splitting up the document
> as long as we do not change the scope of the new documents to be in summary
> not different to what the WG has already agreed to work on for BRSKI-AE.
> And i think all work is within that WG adopted scope. But i've reached out to
> others to check if this statement is correc.
> 
> I think splitting up makes a lot of sense to help accelerate the process.
> 
> The split into one draft for use-case 1 and anothrer for use-case 2 is fine, 
> but not
> the only option you could consier (see below). If you want to do that split, 
> i think
> both resulting drafts should be standards track.
> 
> For example for use-case 1:
> 
> I) the normative part (if i understand your target right) is really the 
> requirements
> for pledges and registrars to support
>   a) the pre-EST part of BRSKI (but no need to support the EST part,
>  and likely also not some other details like ACP requirements... TBD 
> detail
> work).
>   b) lightweight CMP according to (draft-lamps - probably multiple)
>   c) transfering state from a) to b) (aka: using the keying material from
>  a) for b). Figure out which option is MTI, e.g.: same https connection,
>  or rather https for BRSKI then http for lightweight CMP (probably thats
>  the safest/easiest requirement ?).
>   d) likely a specific profile for the discovery part between pledge and
>  registrar (you just want mDNS ? forgot...).
>   e) transport: Are we fine with MUST-ONLY IPv6, no IPv4 ?
> 
> The core output is that client/registrars that implemen ONLY the MUST parts of
> this spec MUST interoperate ;-)
> 
> So this is actually good and hopefully logically simple, but in thre deteals 
> of
> MUST/SHOULD/MAY good profiling work for the draft.
> 
> This normative part can be driven purely by the requirement to support BRSKI 
> for
> clients that already support CMP and therefore will easily be able to support 
> the
> lightweight CMP profile and should not also have to implement EST.
> 
> The information part of the document would be the larger picture showing the
> framework picture and explaining how one can
>a) in general replace BRSKI-EST to the client by other protocols,
>   and that this spec is specifying one particular instance of that
>   relying on a lightweight CMP-profile.
> 
>b) describing that a specific set of features for the
>   pledge-registrars protocol are required or beneficial
>   to support asynchronous operastions in the backend well,
>   and that this document specification for pledge-brski with CMP does
>   meet those requirements but does NOT specify any new
>   backend protocol for backend AE (but that that is subject to
>   other documents).
> 
> Aka: In my opinion i would then title that document as something like "BRSKI 
> for
> pledges with lightweight CMP (BRSKI-plCMP)"
> 
> And as you suggested in the DT meeting, feel free to ask the titling question 
> on
> the list pointing to a github issue.
> 
> Very much the same approach of spllitting use-case 2 into information
> framework aspects and the normative protocol spec.
> 
> Now, alternatively, you could go for 3 documents, where you keep the
> informational parts of both use-case 1 and use-case 2 together in a single
> informational framework document and simply split out the normative p

Re: [Anima] BRSKI-AE document split discussion

[Fries, Steffen]

Hello Toerless, hello Michael, 

Sorry for not being able to react earlier. Based on the response from Michael, 
would that be your view as well Toerless? 
We just want to ensure that we can go forward with the split under the 
assumption that beside the split as technically described in Thomas' last email 
(https://mailarchive.ietf.org/arch/msg/anima/ydPpdwGC4sJ3GY5Tq44nK1hZ4MU/),  we 
should come up with names for the drafts reflecting the target and potential 
adaptations in the authors list. I would assume that the two resulting drafts 
can be submitted as WG documents, as they basically reflect the current WG 
draft content in separate documents. 

Toerless, can we proceed in that way?

Best regards
Steffen

> -Original Message-
> From: Michael Richardson 
> Sent: Donnerstag, 23. September 2021 00:36
> To: Werner, Thomas (T RDA CST SEA-DE) ;
> anima@ietf.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.
> 
> --
> Michael Richardson. o O ( IPv6 IøT consulting )
>Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
> 

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] BRSKI-AE document split discussion

[Fries, Steffen]

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
> > Internet (== scenario 1) AND pledges want to be of the type defined
> > via Scenario 2.
> 
> Will we be able to avoid normative cross-references? Probably not.
> So the documents will progress together.
The problem space that we had in mind regarding the split should address this 
by: 
A: An informative document outlining the use of alternative enrollment 
protocols in BRSKI. As BRSKI already distinguishes between the endpoints for 
voucher handling and enrolment handling, the introduction of an alternative 
enrollment should be straight forward as outlined in the latest async draft. 
BRSKI is not prescriptive regarding the protocol used from the Registrar (as 
RA) to the CA. Handling of offline situation with respect to enrollment could 
thus also be part of an operational considerations document. Offline voucher 
exchanges are already considered in BRSKI by using nonceless vouchers. 

B: A normative document specifying responder mode of pledges. This is what use 
case 2 addresses by introducing the registrar-agent. Depending on the 
deployment, the registrar-agent may be part of a commissioning tool, to provide 
support when there is no connectivity to the registrar. Alternatively, the 
registrar-agent may be part of the registrar itself. This enables (online) 
interactions with pledges in initiator mode and pledges in responder mode.

> 
> I think that where we will benefit will be in the review/reader point of view.
> 
> > Meaning: I would not exclude the option yet, to split the document in
> > 3: One that is the inclusive "reference/architecture" document that
> > we keep alive and extend with whatever we need to keep in common,
> > and then 2 or maybe over time more protocol specification parts of
> > the pieces we are adding.
> 
> I would call the third document the applicability statement for uses in 
> industry
> FOO.
Or it may be part of an operational considerations document that addresses 
different architecture deployment options. 

Regards
Steffen
> 
> 
> --
> Michael Richardson. o O ( IPv6 IøT consulting )
>Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
> 

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] BRSKI-AE document split discussion

[Fries, Steffen]

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: Robert Wilton ; anima@ietf.org
> Subject: Re: [Anima] BRSKI-AE document split discussion
> 
> 
> Dear Area Director and WG Chairs,
> 
> While I am in favour of splitting the document into two, the number of
> documents that the IESG is willing to process is not infinite.
> One advantage of the split is that products can more clearly articulate which 
> RFC
> they support.
> (RFC vs RFC, or RFC section A, or RFC section B)
> 
> Can you comment on this thread about splitting things up?
> 
> I also have not heard very clearly about whether or not RFC8366bis will
> be adopted and worked on.   If reducing number of documents is important,
> then one possibility is to merge draft-ietf-anima-jws-voucher into RFC8366bis.
> 
> Plus: fewer documents.
> Negative: potentially opens up RFC8366bis to new semantics?
> 
> --
> Michael Richardson. o O ( IPv6 IøT consulting )
>Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
> 

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

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

[Fries, Steffen]

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 module 
ietf-ztp-types can now be used directly.
This should enable the direct application in BRSKI-AE, which we were looking 
for to avoid double definition. Thanks for the incorporation. While we are 
currently using only the PKCS#10 approach, the module provides also the option 
to switch to cmp-csr or cmc-csr. So were are open also for other formats.

Best regards
Steffen
--
Steffen Fries
Siemens AG


___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

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

[Fries, Steffen]

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 it
>reshad> is not possible with yang-data. However, you could use
>reshad> "structure" and (eventually) "augment-structure" from RFC8791 for
>reshad> this.
>
> I am probably the guilty party that wrote the YANG.
> I guess I missed your email (seeing Steffen's reply only), and I'll go back 
> to the
> list to find it to understand.
 And I didn't receive Michael's response to Steffen. Not in my Junk folder 
either.
[stf] Michael also just received my response to your email. ANIMA WG was in cc 
so I’m not sure what happened.


I saw that the constraint voucher follows the same approach.
 Where is the constraint voucher defined?
[stf] https://datatracker.ietf.org/doc/draft-ietf-anima-constrained-voucher/

> We do want to mix and match the various extensions.
> It is not clear to me how to do that.
Maybe related to this, would it be better to augment the voucher than as 
requested by Reshad or the voucher-request as we currently do it. I also had a 
look into the constraint voucher as there are also enhancements defined. So I 
guess I should go with the augmented voucher?
 I didn't see a voucher-request node but I'm probably looking for the wrong 
thing.
[stf] You answered this already with your hint in the previous email. We cant 
augment the yang-data is what I understood as it does not allow augmentation.


Best regards
Steffen

>> We will discuss this point. Currently there is no explicit need for
>> enhancements.
>
>reshad> - Prefix "ivr" is used for ietf-voucher-request although RFC8995 
> has
>reshad> "vcr". While this is valid, I am curious why.
>
> I didn't think the prefix had relevance outside of the module, but I don't 
> know a
> lot here.
 It doesn't. It's just usually people use the same prefix as defined in the 
module. No big deal if you want to use a different one, I was just curious why.

Regards,
Reshad.

I meanwhile changed it to vcr. If it has no relevance outside the module, it 
should not be a problem

Regards
Steffen

>
> --
> ]  Never tell me the odds!| ipv6 mesh networks [
> ]  Michael Richardson, Sandelman Software Works|IoT architect  [
> ]m...@sandelman.ca  http://www.sandelman.ca/ 
> 
>|  ruby on rails[

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

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

[Fries, Steffen]

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 extended in the future, my understanding is that it
> reshad> is not possible with yang-data. However, you could use
> reshad> "structure" and (eventually) "augment-structure" from RFC8791 for
> reshad> this.
> 
> I am probably the guilty party that wrote the YANG.
> I guess I missed your email (seeing Steffen's reply only), and I'll go back 
> to the
> list to find it to understand.
I saw that the constraint voucher follows the same approach.

> We do want to mix and match the various extensions.
> It is not clear to me how to do that.
Maybe related to this, would it be better to augment the voucher than as 
requested by Reshad or the voucher-request as we currently do it. I also had a 
look into the constraint voucher as there are also enhancements defined. So I 
guess I should go with the augmented voucher?


> > We will discuss this point. Currently there is no explicit need for
> > enhancements.
> 
> reshad> - Prefix "ivr" is used for ietf-voucher-request although RFC8995 
> has
> reshad> "vcr". While this is valid, I am curious why.
> 
> I didn't think the prefix had relevance outside of the module, but I don't 
> know a
> lot here.
I meanwhile changed it to vcr. If it has no relevance outside the module, it 
should not be a problem

Regards
Steffen 

> 
> --
> ]   Never tell me the odds! | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works|IoT architect   [
> ] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails
> [

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

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

[Fries, Steffen]

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 recommendations for RFC 8366bis 
I have some remarks to the other comments:

> See below for the modified YANG module which
> is valid, please check whether it is correct. Changes consist of removing 
> extra ";
> in author list, adding a revision date and replacing augment "voucher-request"
> by augment voucher. 
I'm not sure about the last statement, as we would like to enhance the existing 
voucher-request definition from RFC 8995 in BRSKI-AE. Does this comment means 
we cannot augment the voucher-request as it already augments the voucher and 
therefore have to use the voucher  and only describe the leafs added?

> Other comments:
> - rc:yang-data (RFC8040) is used. While this seems to be fine, if the voucher-
> request-async-artifact template needs to be extended in the future, my
> understanding is that it is not possible with yang-data. However, you could 
> use
> "structure" and (eventually) "augment-structure" from RFC8791 for this. 
We will discuss this point. Currently there is no explicit need for 
enhancements.

>- Prefix
> "ivr" is used for ietf-voucher-request although RFC8995 has "vcr". While this 
> is
> valid, I am curious why. 
Changed to match the definition in RFC 8995. Also changed for the "uses" 
statement in the grouping.

Best regards
Steffen



- Please take a look at
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatrac
> ker.ietf.org%2Fdoc%2Fhtml%2Frfc8407%23appendix-
> Bdata=04%7C01%7Ccef9763c-149c-4881-b9c2-
> 5fedc277663a%40ad011.siemens.com%7C7e6d34307a3642d99cd208d9600095
> 14%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637646377883265
> 554%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=oyAUYIKQZSQxxURiRc
> j0RTlM6kiupsa6PqRs0hb86jg%3Dreserved=0 for a module remplate.
> e.g. data definition statements usualy go after grouping definitions.
> 
> Valid YANG module:
> 
>module ietf-async-voucher-request {
>  yang-version 1.1;
> 
>  namespace
>"urn:ietf:params:xml:ns:yang:ietf-async-voucher-request";
>  prefix "constrained";
> 
>  import ietf-restconf {
>prefix rc;
>description
>  "This import statement is only present to access
>   the yang-data extension defined in RFC 8040.";
>reference "RFC 8040: RESTCONF Protocol";
>  }
> 
>  import ietf-voucher-request {
>prefix ivr;
>description
>  "This module defines the format for a voucher request,
>  which is produced by a pledge as part of the RFC8995
>  onboarding process.";
>reference
>  "RFC 8995: Bootstrapping Remote Secure Key Infrastructure";
>  }
> 
>  organization
>   "IETF ANIMA Working Group";
> 
>  contact
>   "WG Web:
>  .org%2Fwg%2Fanima%2Fdata=04%7C01%7Ccef9763c-149c-4881-b9c2-
> 5fedc277663a%40ad011.siemens.com%7C7e6d34307a3642d99cd208d9600095
> 14%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637646377883265
> 554%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=7BDzJ4MjL%2BaCAAh
> v4A2PZLl2pB0b7WoNM19qAEGVICU%3Dreserved=0>
>WG List:  
>Author:   Steffen Fries
>  
>Author:   Hendrik Brockhaus
>  
>Author:   Eliot Lear
>  
>Author:   Thomas Werner
>  ";
>  description
>   "This module defines an extension of the RFC8995 voucher
>request to permit a registrar-agent to convey the adjacency
>relationship from the registrar-agent to the registrar.
> 
>The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
>'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY',
>and 'OPTIONAL' in the module text are to be interpreted as
>described in RFC 2119.";
>  revision 2021-08-13 {
>description
> "Initial version";
>reference
> "RFC : Voucher Request for Asynchronous Enrollment";
>  }
>  rc:yang-data voucher-request-async-artifact {
>// YANG data template for a voucher.
>uses voucher-request-async-grouping;
>  }
>  // Grouping defined for future usage
>  grouping voucher-request-async-grouping {
>description
>  "Grouping to allow reuse/extensions in future work.";
>uses ivr:voucher-request-grouping {
> 
>  augment voucher {
>description "Base the constrained voucher-request upon the
>  regular one";
>leaf agent-signed-data 

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

[Fries, Steffen]

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' ; Brockhaus, Hendrik (T RDA CST SEA-DE) 
; 'Michael Richardson' ; 
t...@cs.fau.de; Werner, Thomas (T RDA CST SEA-DE) ; 
anima@ietf.org; yang-doct...@ietf.org
Subject: Re: [yang-doctors] Timeline for BRSKI-AE Review

All, apologies for the delay. Striving to have it done by the end of this week. 
If I can't have it done soon and since the review seems to be urgently needed, 
should we consider assigning another YD?

Regards,
Reshad.

On Monday, August 9, 2021, 10:15:24 AM EDT, Mehmet Ersue 
mailto:mer...@gmail.com>> wrote:



Hi Steffen,



AFAIK Reshad is back from vacation and will do the review in the next days.

Thank you for your patience.



Cheers,

Mehmet



From: yang-doctors 
mailto:yang-doctors-boun...@ietf.org>> On Behalf 
Of Fries, Steffen
Sent: Monday, August 9, 2021 8:07 AM
To: yang-doct...@ietf.org<mailto:yang-doct...@ietf.org>
Cc: Eliot Lear mailto:l...@cisco.com>>; Brockhaus, Hendrik 
mailto:hendrik.brockh...@siemens.com>>; Michael 
Richardson mailto:mcr+i...@sandelman.ca>>; 
t...@cs.fau.de<mailto:t...@cs.fau.de>; Werner, Thomas 
mailto:thomas-wer...@siemens.com>>; 
anima@ietf.org<mailto:anima@ietf.org>
Subject: [yang-doctors] 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 issue #18  
(https://github.com/anima-wg/anima-brski-async-enroll/issues/18<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fanima-wg%2Fanima-brski-async-enroll%2Fissues%2F18=04%7C01%7Ccef9763c-149c-4881-b9c2-5fedc277663a%40ad011.siemens.com%7C472a25d1514c4ea9386c08d95ba8e4d1%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637641603351489128%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000=VGNMrsW2FwV44lSs9pVBdJIILgOMUC0VQOqrWqvF3G8%3D=0>)
 in the issue tracker of BRSKI-AE.

Besides this, there is a YANG module included in section 6 to enhance the 
voucher-request with additional data to allow a registrar and MASA to verify if 
an authorized registrar-agent was involved in the bootstrapping for which an 
early review would be requested.



Best regards

Steffen



--
Steffen Fries
Siemens AG


___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

[Anima] Timeline for BRSKI-AE Review

[Fries, Steffen]

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 issue #18  
(https://github.com/anima-wg/anima-brski-async-enroll/issues/18) in the issue 
tracker of BRSKI-AE.
Besides this, there is a YANG module included in section 6 to enhance the 
voucher-request with additional data to allow a registrar and MASA to verify if 
an authorized registrar-agent was involved in the bootstrapping for which an 
early review would be requested.

Best regards
Steffen

--
Steffen Fries
Siemens AG


___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] BRSKI-AE document split discussion

[Fries, Steffen]

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 alternative enrollment protocols
> > to achieve a proof-of-identity binding to the certification request
> > directly without relying on TLS to be able to "store and forward
> > "certification requests". For alternative enrollment, use case 1 could
> > use the Lightweight CMP profile
> > 
> https://datatracker.ietf.org/doc/draft-ietf-lamps-lightweight-cmp-profile/
> > to achieve its goal. So this document would have no reference to use
> > case 2.
> 
> > Use case 2, as currently described,  instead reverses the communication
> > flow to let the pledge be a server by introducing the registrar-agent
> > as new component. The communication between the registrar-agent and
> the
> > pledge is defined based on the exchange of JOSE objects, which provide
> > proof-of-identity on a message level to be independent of an underlying
> > TLS connection. This also allows to utilize BTLE for instance as
> > transport. The communication from the registrar-agent to the registrar
> > is kept as close as possible to BRSKI by relying on an enhanced voucher
> > and utilizing EST with enhanced objects for enrollment. Based on that,
> > use case 2 document would not reference use case 1 document.
> 
> I thought that the enrollment objects in use case 2 could be CMP objects.
Yes it could be. What is specified in use case 2 is currently based on JOSE and 
realizes a simple wrapper of  a PKCS#10 to be able to utilize the BRSKI 
enrollment endpoint on a registrar. Different pledges may support different 
enrollment formats. The assumption is that one pledge supports only one 
enrollment format. The pledge-enrollment-request  format can be signaled via 
the content type header in the pledge's response. If other formats for the 
pledge-enrollment-request are used like CMP, it would require additional logic 
at the registrar-agent to be able to select the corresponding endpoints at the 
registrar. We have not included this so far, but if the pledge would support 
CMP, we could reference use case 1 from use case 2 for the communication from 
the registrar-agent to the registrar.

Best regards
Steffen
> 
> --
> Michael Richardson. o O ( IPv6 IøT consulting )
>Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
> 

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] BRSKI-AE document split discussion

[Fries, Steffen]

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, I would like to
> > > proceed with the discussion on the author's proposal to split the
> > > current BRSKI-AE draft
> > >
> (https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
> tracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-anima-brski-async-enroll-
> 03data=04%7C01%7Ccef9763c-149c-4881-b9c2-
> 5fedc277663a%40ad011.siemens.com%7C01cc5c134fa141586f2c08d955f9702
> d%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C6376353520778173
> 88%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM
> zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=VikJIzx0apXELx7
> q8yDp7hVwgHnEU3HwIvPq6nAlZk8%3Dreserved=0)
> > > to separate the contained use cases as they have developed
> > > differently. We did not finish the discussion during the meeting 
> > during
> > > lack of time, but for the way forward I would like to ask for support
> > > from the chairs to find the decision. I included this question also as
> > > open issue in the ANIMA github
> > >
> > (https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit
> > hub.com%2Fanima-wg%2Fanima-brski-async-
> enroll%2Fissues%2F19data=0
> > 4%7C01%7Ccef9763c-149c-4881-b9c2-
> 5fedc277663a%40ad011.siemens.com%7C01
> >
> cc5c134fa141586f2c08d955f9702d%7C38ae3bcd95794fd4addab42e1495d55a%
> 7C1%
> >
> 7C0%7C637635352077817388%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4
> wLjAwMDAiL
> >
> CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=jxU
> xUpv
> > XcTLXNjcXwRMgEUxtA7TlK1RzMyJpOM%2BXWks%3Dreserved=0)
> >
> > > Declaration of conformity to "AE" is difficult, as the use cases have
> > > developed in different directions. Therefore the proposal to split the
> > > draft into two separate documents for use case 1 and use case 2. We
> may
> > > also discuss, what the target for each document would be
> (informational
> > > / standard RFC).
> >
> > ...
> >
> > > If the WG is in favor of the split, the expectation would be that the
> > > resulting document would proceed as WG documents.
> >
> > Are there common parts that would argue for three documents
> > (B--referencing-->A, and C--referencing-->A)
> 
> That was my question too. Splitting the document but having Part 1
> normatively reference Part 2 would be unfortunate.
> 
> > "A" could also be RFC8366bis.
> 
> Then we'd have 3 documents as an AUTH48 cluster, right? But if the result is a
> more logical set of documents for future readers, it's the right thing to do.
> 

The two use cases have technically less in common regarding the specific 
realization. Both are intended for scenarios in which the pledge has no or 
limited connectivity to a backend.
Use Case 1 is relying on RFC 8995 for communication flow and for the voucher 
handling, but targets to use alternative enrollment protocols to achieve a 
proof-of-identity binding to the certification request directly without relying 
on TLS to be able to "store and forward "certification requests". For 
alternative enrollment, use case 1 could use the Lightweight CMP profile 
https://datatracker.ietf.org/doc/draft-ietf-lamps-lightweight-cmp-profile/ to 
achieve its goal. So this document would have no reference to use case 2.

Use case 2, as currently described,  instead reverses the communication flow to 
let the pledge be a server by introducing the registrar-agent as new component. 
The communication between the registrar-agent and the pledge is defined based 
on the exchange of JOSE objects, which provide proof-of-identity on a message 
level to be independent of an underlying TLS connection. This also allows to 
utilize BTLE for instance as transport. The communication from the 
registrar-agent to the registrar is kept as close as possible to BRSKI by 
relying on an enhanced voucher and utilizing EST with enhanced objects for 
enrollment. Based on that, use case 2 document would not reference use case 1 
document. 

So a way forward could be to simply take the use case 2 from the current 
BRSKI-AE document into a new document and add a motivation/use case for 
reversing the call flow as well as the targeted solution approach. From the 
scenarios, currently available in the draft, some could be adopted also for use 
case 2. 
Regarding the existing use case 1, the text is stable for quite a while now, 
and the authors think it should be easi

[Anima] BRSKI-AE document split discussion

[Fries, Steffen]

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 developed differently. We did 
not finish the discussion during the meeting during lack of time, but for the 
way forward I would like to ask for support from the chairs to find the 
decision. I included this question also as open issue in the ANIMA github 
(https://github.com/anima-wg/anima-brski-async-enroll/issues/19)

- Use Case 1 targets the definition of requirements for a communication 
architecture using the existing BRSKI components and call model 
(pledge-initiator-mode, formerly PULL) to enable the use of alternative 
enrollment protocols for certificate enrollment (voucher handling untouched).

- Use Case 2 targets the specification of a reversed call model 
(pledge-responder-mode, formerly PUSH) in which the pledge has no or only 
limited connectivity to a registrar or cannot initiate requests to a registrar. 
To facilitate the interaction between pledge and registrar, the registrar-agent 
component is established. The interaction between pledge and registrar-agent 
results in new or enhanced data objects (voucher-request-trigger, 
voucher-request, voucher, enrollment-request-trigger, enrollment-request). 
Exchanges between registrar-agent and registrar follows BRSKI (RFC8995) and EST 
(RFC7030), with the enhanced objects.

Declaration of conformity to "AE" is difficult, as the use cases have developed 
in different directions. Therefore the proposal to split the draft into two 
separate documents for use case 1 and use case 2. We may also discuss, what the 
target for each document would be (informational / standard RFC).

If the WG is in favor of the split, the expectation would be that the resulting 
document would proceed as WG documents.

Please let us know what you think.

Best regards
Steffen

--
Steffen Fries
Siemens AG
T RDA CST



___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

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

[Fries, Steffen]

Hi Toerless,

Just to clarify the relations of the drafts, draft-ietf-anima-jws-voucher-00 
and draft-ietf-anima-brski-async-enroll-03 are two independent drafts. BRSKI-AE 
utilizes the JWS-voucher and normatively refers to it. 
The split I was referring to relates to the two use cases in BRSKI-AE, which 
developed differently. So we see a benefit in separating them. 

>From that point of view we may handle them as two separate points in the 
>agenda. 
I will upload the slides for BRSKI-AE soon. 

Best regards
Steffen


> -Original Message-
> From: t...@cs.fau.de 
> Sent: 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] Call for agenda items ANIMA @ IETF 111, online
> 
> Steffen, Michael:
> 
> Thursday for BRSKI-AE is fine. I will assume the split-out JWS voucher draft
> (Michael wants to publish it as draft-ietf-anima-jws-voucher-00) should then
> also be discussed.
> 
> Right now i will account that as one slot. But feel free to suggest different
> speaker/slides for both drafts.
> 
> Cheers
> Toerless.
> 
> On Mon, Jul 12, 2021 at 08:35:27AM +, Fries, Steffen wrote:
> > 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  :  draft-ietf-anima-brski-async-enroll-
> 03.txt
> >
> > If possible we would like to discuss the status of BRSKI-AE in the second
> session on Thursday, as the Monday session is in parallel to a LAMPS session.
> >
> > Best regards
> > Steffen
> >
> > > -Original Message-
> > > From: Anima  On Behalf Of t...@cs.fau.de
> > > Sent: Donnerstag, 8. Juli 2021 17:12
> > > To: anima@ietf.org; anima-cha...@ietf.org
> > > Subject: [Anima] Call for agenda items ANIMA @ IETF 111, online
> > >
> > > Dear ANIMA WG
> > >
> > > It is this time again!
> > >
> > > ANIMA WG will meet at IETF111 online for two 1 hour slots:
> > >   Monday   July 26, Session 2, 21:30 - 22:30 UTC
> > >   Thursday July 29, Session 1, 19:00 - 20:00 UTC So we will have
> > > more time for discussions.
> > >
> > > Please submit your requests for Agenda items in reply to this email,
> > > to anima- cha...@ietf.org and copy anima@ietf.org unless you want to
> > > discuss agenda issues in private with the chairs.
> > >
> > > Topic/Title
> > > Nam of Presenter(s)
> > > Length of time requested
> > > If applicable: name of draft(s) discussed
> > >
> > > Please note explicitly if you CAN have the agenda item only
> > > in one of the two slots due to conflicts.
> > >
> > > No need to wait with agenda slots until you have uploaded your (updated)
> draft!
> > >
> > > Especially this time around we would appreciate requests for agenda
> > > slots to be as early as possible so we can try to shuffle them around the 
> > > two
> time slots best.
> > > Of course, by default we would sort as usual by WG adopted items
> > > first, then actively discussed non-WG items and finally new, non-discussed
> work proposals.
> > >
> > > Also: Once you have your slides, go to:
> > >
> > >
> > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fda
> > > tatrac
> > >
> ker.ietf.org%2Fmeeting%2F111%2Fsession%2Fanimadata=04%7C01%7Cc
> > > ef9763c-149c-4881-b9c2-
> > >
> 5fedc277663a%40ad011.siemens.com%7C3cbdd85c0d5942b6f5fb08d94222c82
> > >
> 8%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C6376135394252642
> > >
> 83%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> > >
> CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=50LDy25FpJsDwf7mcT
> > > uzQcPBe3GLG1cYEsB4lHH%2BK7s%3Dreserved=0
> > >
> > > and upload your slides via the "Propose Slides" Button (pick either
> > > of the two slots as you see fit).
> > >
> > > Please also remember to (re-)start discussing any non-WG adopted
> > > work also on the anima@ietf.org mailing list to encourage WG members
> > > to read your work and comment!
> > >
> > > More details about the 

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

[Fries, Steffen]

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  :  
draft-ietf-anima-brski-async-enroll-03.txt   

If possible we would like to discuss the status of BRSKI-AE in the second 
session on Thursday, as the Monday session is in parallel to a LAMPS session.

Best regards
Steffen

> -Original Message-
> From: Anima  On Behalf Of t...@cs.fau.de
> Sent: Donnerstag, 8. Juli 2021 17:12
> To: anima@ietf.org; anima-cha...@ietf.org
> Subject: [Anima] Call for agenda items ANIMA @ IETF 111, online
> 
> Dear ANIMA WG
> 
> It is this time again!
> 
> ANIMA WG will meet at IETF111 online for two 1 hour slots:
>   Monday   July 26, Session 2, 21:30 - 22:30 UTC
>   Thursday July 29, Session 1, 19:00 - 20:00 UTC So we will have more time for
> discussions.
> 
> Please submit your requests for Agenda items in reply to this email, to anima-
> cha...@ietf.org and copy anima@ietf.org unless you want to discuss agenda
> issues in private with the chairs.
> 
> Topic/Title
> Nam of Presenter(s)
> Length of time requested
> If applicable: name of draft(s) discussed
> 
> Please note explicitly if you CAN have the agenda item only
> in one of the two slots due to conflicts.
> 
> No need to wait with agenda slots until you have uploaded your (updated) 
> draft!
> 
> Especially this time around we would appreciate requests for agenda slots to 
> be
> as early as possible so we can try to shuffle them around the two time slots 
> best.
> Of course, by default we would sort as usual by WG adopted items first, then
> actively discussed non-WG items and finally new, non-discussed work proposals.
> 
> Also: Once you have your slides, go to:
> 
> 
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatrac
> ker.ietf.org%2Fmeeting%2F111%2Fsession%2Fanimadata=04%7C01%7Cc
> ef9763c-149c-4881-b9c2-
> 5fedc277663a%40ad011.siemens.com%7C3cbdd85c0d5942b6f5fb08d94222c82
> 8%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C6376135394252642
> 83%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=50LDy25FpJsDwf7mcT
> uzQcPBe3GLG1cYEsB4lHH%2BK7s%3Dreserved=0
> 
> and upload your slides via the "Propose Slides" Button (pick either of the two
> slots as you see fit).
> 
> Please also remember to (re-)start discussing any non-WG adopted work also on
> the anima@ietf.org mailing list to encourage WG members to read your work
> and comment!
> 
> More details about the IETF 111 can be found at:
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf
> .org%2Fhow%2Fmeetings%2F111%2Fdata=04%7C01%7Ccef9763c-149c-
> 4881-b9c2-
> 5fedc277663a%40ad011.siemens.com%7C3cbdd85c0d5942b6f5fb08d94222c82
> 8%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C6376135394252642
> 83%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=12cBiD4Q3nnVBPXLVs
> 5VnAFaKdmKKVMpE7E7cDpp8HI%3Dreserved=0
> 
> ANIMA WG Chairs, Toerless/Sheng
> 
> ___
> Anima mailing list
> Anima@ietf.org
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf
> .org%2Fmailman%2Flistinfo%2Fanimadata=04%7C01%7Ccef9763c-149c-
> 4881-b9c2-
> 5fedc277663a%40ad011.siemens.com%7C3cbdd85c0d5942b6f5fb08d94222c82
> 8%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C6376135394252642
> 83%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=o441I77W%2Fh4FBD6
> 754X9coaQUpM2%2FWhRVttFY2y3i18%3Dreserved=0

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

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

[Fries, Steffen]

> 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 I nuked the 
> draft by
> mistake.
> >>
> >> The short of it:
> >> RFC8366 -> RFC8995 (voucher-request)
> -> constrained-voucher (voucher-request, voucher)
> -> brski-async-enroll (voucher-request)
> 
> > Would it make sense to also state the voucher for BRSKI-AE as it also
> > uses the voucher and tries to argue for a new assertion type
> > (agent-proximity)?
> 
> I am of two feelings here.
> On the one hand, it would be IANA proceedurally simpler to include the new
> assertion type into the 8366bis document.
> 
> On the other hand, this means having some kind of explanation in RFC8366bis
> for the new choice, and that might force a lot of text to enter and get 
> reviewed.
> 
> Once RFC8366bis is published, then async-enroll can make use of the IANA
> Considerations to allocate that new enum value.  That won't slow async-enroll
> down, because either way, it has to wait for RFC8366bis.
Yes true. Having the option doing it via an IANA considerations will be simpler 
for other drafts like async-enroll extending the assertions in the voucher. 

> Where I'm a bit blurry is how stuff like the YANG in RFC8995, which uses
> RFC8366 gets updated when IANA revises the module.  I think, it mostly doesn't
> matter because none of are generating code from YANG... AT THIS TIME.
> 
> --
> Michael Richardson. o O ( IPv6 IøT consulting )
>Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
> 

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

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

[Fries, Steffen]

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: Call for adoption: draft-richardson-anima-jose-
> voucher
> 
> [apologies for mixing up june with july. resending to be formally correct.
> Thanks Bill!]
> 
> This emails starts a two week call for adoption for draft-richardson-anima-
> jose-voucher
> The adoption call does end when July 14 has passed for everyone on planet
> earth.
> 
> Justification:
> 
> This draft is a core normative dependency for the ANIMA WG document
> draft-ietf-anima-brski-async-enroll (BRSKI-AE). It does effectively not
> constitute new work, but was separated out during development of that
> draft so that the jose-signed-voucher can more easily be referenced and
> reused by other work in the IETF that may not need to inherit, refer to the
> whole BRSKI-AE solution.
> 
> Toerless, for the ANIMA chairs.
> 
> On Thu, Jul 01, 2021 at 08:44:08AM +1200, Brian E Carpenter wrote:
> > > The JSON Compact Serialization is examplained in section 3.1 or
> > > section
> > 7.1
> >
> > examplained?? A great word, but not in my dictionary.
> >
> > Mainly I can't understand this draft because it's way outside my expertise,
> but it seems necessary so I would support adoption.
> >
> > Regards
> >Brian
> >
> > On 30-Jun-21 12:30, Michael Richardson wrote:
> > >
> > > I have reposted draft-richardson-anima-jose-voucher.
> > > It's very short.  Most of the document is examples.
> > >
> > > Can we adopt this so that it does not keep brski-async-enroll from
> > > progressing when the time comes?
> > >
> > > internet-dra...@ietf.org wrote:
> > > > Name:   draft-richardson-anima-jose-voucher
> > > > Revision:   01
> > > > Title:  JOSE signed Voucher Artifacts for Bootstrapping
> Protocols
> > > > Document date:  2021-06-23
> > > > Group:  Individual Submission
> > > > Pages:  15
> > > > Html:
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> .ietf.org%2Farchive%2Fid%2Fdraft-richardson-anima-jose-voucher-
> 01.htmldata=04%7C01%7Ccef9763c-149c-4881-b9c2-
> 5fedc277663a%40ad011.siemens.com%7C71f7e76fd85f40dce8cf08d93cae052
> 4%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C6376075403975495
> 87%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM
> zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=7Yt2Vz%2B08zpg
> mqlAyb2QALaDG39BE%2FOhV50LM7TgQI4%3Dreserved=0
> > > > Diff:
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> .ietf.org%2Frfcdiff%3Furl2%3Ddraft-richardson-anima-jose-voucher-
> 01data=04%7C01%7Ccef9763c-149c-4881-b9c2-
> 5fedc277663a%40ad011.siemens.com%7C71f7e76fd85f40dce8cf08d93cae052
> 4%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C6376075403975495
> 87%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM
> zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=uMWeN1Gjlf%2
> Fv85Yzub2Ja028U3XFRTccTOuuhDi%2Bc0o%3Dreserved=0
> > >
> > > > Abstract:
> > > > This document describes a serialiation of the RFC8366 voucher format
> > > > to a JSON format is then signed using the JSON Object Signing and
> > > > Encryption mechanism described in RFC7515.
> > >
> > >
> > > --
> > > Michael Richardson. o O ( IPv6 IøT
> consulting )
> > >Sandelman Software Works Inc, Ottawa and Worldwide
> 
> --
> ---
> t...@cs.fau.de
> 
> ___
> Anima mailing list
> Anima@ietf.org
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> .ietf.org%2Fmailman%2Flistinfo%2Fanimadata=04%7C01%7Ccef9763c-
> 149c-4881-b9c2-
> 5fedc277663a%40ad011.siemens.com%7C71f7e76fd85f40dce8cf08d93cae052
> 4%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C6376075403975495
> 87%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM
> zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=FSFejSDPrB9Ylw
> bPpJy8uXfH6cGkqq9Q3VxDLaBKVwM%3Dreserved=0

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

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

[Fries, Steffen]

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 short of it:
> RFC8366 -> RFC8995 (voucher-request)
> -> constrained-voucher (voucher-request, voucher)
> -> brski-async-enroll (voucher-request)
Would it make sense to also state the voucher for BRSKI-AE as it also uses the 
voucher and tries to argue for a new assertion type (agent-proximity)?

> -> jose-voucher (voucher, voucher-request)

Regards
Steffen



> 
> and my question was a bit about how we manage all their things inherited.
> It's really the classic CS multiple inheritance problem.
> 
> {A Cat is an Mammal
>  A Cat is an Four-legged creature
>  A Cat is Nocturnal.}

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

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

[Fries, Steffen]

Hello all,

I just submitted a new version of BRSKI-AE. The changes are mainly related to 
stating open issues related to YANG in section 5.2.

Best regards
Steffen

-Original Message-
From: internet-dra...@ietf.org  
Sent: Donnerstag, 24. Juni 2021 18:15
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-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 to the IETF 
repository.

Name:   draft-ietf-anima-brski-async-enroll
Revision:   03
Title:  Support of asynchronous Enrollment in BRSKI (BRSKI-AE)
Document date:  2021-06-24
Group:  anima
Pages:  60
URL:
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-anima-brski-async-enroll-03.txtdata=04%7C01%7Ccef9763c-149c-4881-b9c2-5fedc277663a%40ad011.siemens.com%7C3d4c14c2efc746a6047b08d9372b28ca%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637601480776440915%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=7MNuZVf0BZgvJqtXNxUoRV0jTcqvg0vEtzc0ke6kTeY%3Dreserved=0
Status: 
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-anima-brski-async-enroll%2Fdata=04%7C01%7Ccef9763c-149c-4881-b9c2-5fedc277663a%40ad011.siemens.com%7C3d4c14c2efc746a6047b08d9372b28ca%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637601480776440915%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=ntMrYE9zEmZd6zFnTdXRpfNCvgujW%2BhrTqZNt0kj3w0%3Dreserved=0
Htmlized:   
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-anima-brski-async-enrolldata=04%7C01%7Ccef9763c-149c-4881-b9c2-5fedc277663a%40ad011.siemens.com%7C3d4c14c2efc746a6047b08d9372b28ca%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637601480776440915%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=aKjrNSCcOUInIf%2BjHsDU6G2tki2hWWzoaVj%2B5fWHjx4%3Dreserved=0
Diff:   
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-anima-brski-async-enroll-03data=04%7C01%7Ccef9763c-149c-4881-b9c2-5fedc277663a%40ad011.siemens.com%7C3d4c14c2efc746a6047b08d9372b28ca%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637601480776440915%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=0NeLNBuj4o0jDxzsmsfWS%2BSpT%2BMHl49kv6Sz0ZPy9bo%3Dreserved=0

Abstract:
   This document describes enhancements of bootstrapping a remote secure
   key infrastructure (BRSKI, [RFC8995] ) to also operate in domains
   featuring no or only timely limited connectivity between involved
   components.  Further enhancements are provided to perform the BRSKI
   approach in environments, in which the role of the pledge changes
   from a client to a server . This changes the interaction model from a
   pledge-initiator-mode to a pledge-responder-mode.  To support both
   use cases, BRSKI-AE relies on the exchange of authenticated self-
   contained objects (signature-wrapped objects) also for requesting and
   distributing of domain specific device certificates.  The defined
   approach is agnostic regarding the utilized enrollment protocol
   allowing the application of existing and potentially new certificate
   management protocols.


  


The IETF Secretariat


___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

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

[Fries, Steffen]

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, it is probably the 
easiest way.

Best regards
Steffen

From: Andy Bierman 
Sent: Donnerstag, 17. Juni 2021 17:19


I am not really following this specific issue.
I was just pointing out that YANG enumeration types cannot be augmented.
It is the wrong terminology, since only schema nodes can be augmented.

>From: Anima anima-boun...@ietf.org On Behalf Of 
>Andy Bierman
>An enumeration type is hard-wired.
Hardwired in terms of a fixed definition of values for the enum in RFC 8366?

>No enums can be added via augmentation.
That means just the definition of an additional enum value is not enough.

>You have to "deviate replace" the type-stmt to add an enum externally,
As I’m not too deep in YANG, could you provide more information on this part?  
Would this be an approach to (just) redefine the type enumeration in the leaf 
“assertion” 
(https://datatracker.ietf.org/doc/html/rfc8366#page-11)
 and adding the new assertion type “agent-proximity”? Would this require to 
keep all enums already defined in RFC 8366 or could we just use the ones 
necessary in BRSKI-AE?


https://datatracker.ietf.org/doc/html/rfc7950#section-7.20.3


>or you have to update the module and add the enum inline.
Does this result in an update of the module “ietf-voucher” or to define a new 
module, which imports and augments the voucher by adding the new enum?

Best regards
Steffen


Andy

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

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

[Fries, Steffen]

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.
Hardwired in terms of a fixed definition of values for the enum in RFC 8366?

>No enums can be added via augmentation.
That means just the definition of an additional enum value is not enough.

>You have to "deviate replace" the type-stmt to add an enum externally,
As I’m not too deep in YANG, could you provide more information on this part?  
Would this be an approach to (just) redefine the type enumeration in the leaf 
“assertion” (https://datatracker.ietf.org/doc/html/rfc8366#page-11) and adding 
the new assertion type “agent-proximity”? Would this require to keep all enums 
already defined in RFC 8366 or could we just use the ones necessary in BRSKI-AE?

>or you have to update the module and add the enum inline.
Does this result in an update of the module “ietf-voucher” or to define a new 
module, which imports and augments the voucher by adding the new enum?

Best regards
Steffen
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

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

[Fries, Steffen]

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 registrar-agent and protect 
the exchanged objects by an additional signature. This is done by embedding the 
necessary information into a JOSE object. 
For the enrollment Michael was pointing to the YANG module in 
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-sztp-csr to avoid a 
double definition to transport a certification request. In BRSKI-AE we 
currently use a PKCS#10 request, but using the defined ietf-sztp-csr would also 
allow to use other formats. 

For the enrollment request created by the pledge we have defined the following 
JOSE object:
   {
   "alg": "ES256",
   "x5c": ["MIIB2jCC...dA=="]
   }
   {
 "ietf-sztp-csr:csr": {
   "p10": "base64encodedvalue=="
 }
   }
   {
   SIGNATURE
   }

The question (https://github.com/anima-wg/anima-brski-async-enroll/issues/10) 
now is, if this construct is possible, as we are just using a subset 
(sztp-csr:csr) of the YANG  module " ietf-sztp-bootstrap-server" from 
draft-ietf-netconf-sztp-csr? The alternative would be to define an own module 
modeled in a similar. 

Best regards
Steffen

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

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

[Fries, Steffen]

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
8366](https://datatracker.ietf.org/doc/html/rfc8366#section-5.3)

Kent, how do we do add a new enum?
Does the grouping help us at all?
We need to do this for both voucher and voucher-request.

Firstly, because it took me quite some time to put this message in context, for 
everyone else, here’s a link to GitHub Issue #18: 
https://github.com/anima-wg/anima-brski-async-enroll/issues/18.

I’m unsure what it is trying to be accomplished but, generally, either an 
“augment” and a module-revision can be used to add an enum.

[stf] Thank you for the hint. In one of the use cases of BRSKI-AE a 
registrar-agent acting on behalf of the registrar is used to facilitate the 
communication between pledge and registrar. In this case the MASA should assert 
“agent-proximity” instead of “proximity” to show, that there was no direct 
connection between the pledge and the registrar. Also, as the pledge does not 
verify a signature of the registrar, this assertion is weaker than “proximity” 
but stronger than “logged”. To achieve this we intended to enhance the current 
enum with the new assertion type.

Best regards
Steffen
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

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

[Fries, Steffen]

Hello all,

I just submitted an update of BRSKI-AE which contains the following list of 
changes to the 01 version:

   o  Defined call flow and objects for interactions in use case2.  Object
  format based on draft for JOSE signed voucher artifacts and
  aligned the remaining objects with this approach in Section 5.2.3

   o  Terminology change: issue #2 pledge-agent -> registrar-agent to
  better underline agent relation.

   o  Terminology change: issue #3 PULL/PUSH -> pledge-initiator-mode
  and pledge-responder-mode to better address the pledge operation.

   o  Communication approach between pledge and registrar-agent changed
  by removing TLS-PSK (former section TLS establishment) and
  associated references to other drafts in favor of relying on
  higher layer exchange of signed data objects.  These data objects
  are included also in the pledge-voucher-request and lead to an
  extension of the YANG module for the voucher-request (issue #12).

   o  Details on trust relationship between registrar-agent and
  registrar (issue #4, #5, #9) included in Section 5.2.

   o  Recommendation regarding short-lived certificates for registrar-
  agent authentication towards registrar (issue #7) in the security
  considerations.

   o  Introduction of reference to agent signing certificate using SKID
  in agent signed data (issue #11).

   o  Enhanced objects in exchanges between pledge and registrar-agent
  to allow the registrar to verify agent-proximity to the pledge
  (issue #1) in Section 5.2.3.

   o  Details on trust relationship between registrar-agent and pledge
  (issue #5) included in Section 5.2.

   o  Split of use case 2 call flow into sub sections in Section 5.2.3.

The stated resolved 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) 
; Fries, Steffen (T RDA CST) 
; Werner, Thomas (T RDA CST SEA-DE) 

Subject: New Version Notification for draft-ietf-anima-brski-async-enroll-02.txt


A new version of I-D, draft-ietf-anima-brski-async-enroll-02.txt
has been successfully submitted by Steffen Fries and posted to the IETF 
repository.

Name:   draft-ietf-anima-brski-async-enroll
Revision:   02
Title:  Support of asynchronous Enrollment in BRSKI (BRSKI-AE)
Document date:  2021-06-14
Group:  anima
Pages:  59
URL:
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-anima-brski-async-enroll-02.txtdata=04%7C01%7Ccef9763c-149c-4881-b9c2-5fedc277663a%40ad011.siemens.com%7C3a48344b61fc45c0242e08d92f50bcfa%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637592846077385854%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=%2F6jTDHN9ZJuLOmKSx6AAXbOSHFDVOG9JrvPo6D%2FOx8o%3Dreserved=0
Status: 
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-anima-brski-async-enroll%2Fdata=04%7C01%7Ccef9763c-149c-4881-b9c2-5fedc277663a%40ad011.siemens.com%7C3a48344b61fc45c0242e08d92f50bcfa%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637592846077395842%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=IinDSTTy3D%2BLcoGsUfM0GzUWmwvJaQaqlkr6DchcSG8%3Dreserved=0
Htmlized:   
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-anima-brski-async-enrolldata=04%7C01%7Ccef9763c-149c-4881-b9c2-5fedc277663a%40ad011.siemens.com%7C3a48344b61fc45c0242e08d92f50bcfa%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637592846077395842%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=yfaytb5npue822GNTiMEU%2Bi4di3OuABk9YBvvI2v%2FGo%3Dreserved=0
Diff:   
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-anima-brski-async-enroll-02data=04%7C01%7Ccef9763c-149c-4881-b9c2-5fedc277663a%40ad011.siemens.com%7C3a48344b61fc45c0242e08d92f50bcfa%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637592846077395842%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=C09nmKLYTx%2FbBLyFdwh4fEdU8LYT57msQzTIb6q8kCU%3Dreserved=0

Abstract:
   This document describes enhancements of bootstrapping a remote secure
   key infrastructure (BRSKI, [RFC8995] ) to also operate in domains
   featuring no or only timely limited connectivity between involved
   components.  Further enhancements are provided to perform the BRSKI
   approach in environments, in which the role of the pledge changes
   from a client to a server . This changes the interaction model from a
   

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

[Fries, Steffen]

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 regards
Steffen

> -Original Message-
> From: Anima  On Behalf Of t...@cs.fau.de
> Sent: Freitag, 4. Juni 2021 16:45
> To: anima@ietf.org; anima-cha...@ietf.org
> Subject: [Anima] Input/Questions for ANIMA @ IETF 111, online
> 
> Hi folks,
> 
> Deadline for submission of WG meeting requests for IETF 111 is June 11th.
> 
> In the last few IETFs, we only collected our agenda items last minute, and the
> 1 hour sessions where then pretty tightly packed, allowing for little
> discussion. However, we do have ongoing good discussion in the weekly
> brski related design team meetings, and other side activities.
> 
> Yada yada: I will wait for the deadline and want to ask via this mail for
> feedback if people feel we should request a longer (or two) slots @IETF111,
> especially when contributors think they want to discuss longer about
> potential new work.
> 
> Short of any feeedback for such longer slot suggestions, i will go forward and
> ask again for a 1 hour slot before the deadline and then we can do our usual
> last-minute *sigh* agenda building against that - as usual *sigh*.
> 
> Lets also remember that side-meetings are easy to set up and do (NEW!) also
> support meetecho. Aka: are for all intent and purpose tools-wise as good as a
> full online IETF (i think).
> 
> Cheers
> Toerless
> 
> ___
> Anima mailing list
> Anima@ietf.org
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> .ietf.org%2Fmailman%2Flistinfo%2Fanimadata=04%7C01%7Ccef9763c-
> 149c-4881-b9c2-
> 5fedc277663a%40ad011.siemens.com%7C2be4368106154f771b3c08d927676d
> 6c%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637584147434856
> 161%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu
> MzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=B7DcImpFFtU4
> SxFiAQS7sz0iLJghoYFnBaGfDdPK6co%3Dreserved=0

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

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

[Fries, Steffen]

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: anima-cha...@ietf.org; Rob Wilton (rwilton) ; 
t...@cs.fau.de; draft-friel-anima-brski-cl...@ietf.org
Subject: [Anima] Adoption call for draft-friel-anima-brski-cloud-04, ends April 
20th 2021


Hi, dear ANIMAer,



This message starts a two-week adoption call on 
draft-friel-anima-brski-cloud-04, it ends on April 20th, 2021.



draft-friel-anima-brski-cloud has been presented to the WG since September 2019 
and the WG showed good interest and had discussions. It was presented several 
times and had no opposition. The draft is clearly in scope of ANIMA charter and 
milestones. Giving the dependent BRSKI has passed the IESG evaluation, the 
chairs feel that it may be the right time to call the adoption.



We therefore are asking the ANIMA working group for adoption of the following 
work:



Title:BRSKI Cloud Registrar

Name: draft-friel-anima-brski-cloud-04

Authors:  O. Friel, R. Shekh-Yusef and M. Richardson

URL:  https://datatracker.ietf.org/doc/draft-friel-anima-brski-cloud/

IPR:  No IPR disclosures have been submitted directly on 
draft-richardson-anima-voucher-delegation



This document is intended to become a standards track ANIMA WG document.



Please express your support or rejection. If you think this document should 
_not_ be adopted, please also explicitly indicate the reasons.



Regards,



Sheng
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

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

[Fries, Steffen]

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. April 2021 04:49
To: anima@ietf.org
Cc: anima-cha...@ietf.org; Toerless Eckert 
Subject: [Anima] Adoption call for 
draft-richardson-anima-voucher-delegation-03, ends April 19th 2021


Hi, dear ANIMAer,



This message starts a two-week adoption call, it ends on April 19th, 2021.



draft-richardson-anima-voucher-delegation-03 has been presented to the WG for a 
long while and the WG showed good interest and had discussions. It was 
presented several times and had no opposition. The draft is clearly in scope of 
ANIMA charter and milestones. Giving the dependent BRSKI has passed the IESG 
evaluation, the chairs feel that it may be the right time to call the adoption.



We therefore are asking the ANIMA working group for adoption of the following 
work:



Title:Delegated Authority for Bootstrap Voucher Artifacts

Name: draft-richardson-anima-voucher-delegation-03

Authors:  M. Richardson and W. Pan

URL:  
https://datatracker.ietf.org/doc/draft-richardson-anima-voucher-delegation/

IPR:  No IPR disclosures have been submitted directly on 
draft-richardson-anima-voucher-delegation



This document is intended to become a standards track ANIMA WG document.



Please express your support or rejection. If you think this document should 
_not_ be adopted, please also explicitly indicate the reasons.



Regards,



Sheng
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

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

[Fries, Steffen]

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 case 
2 in the draft)
The approach in draft -01 describes the trust between the pledge(-callee) and 
registrar-agent relation based on a PSK, which is used in a TLS connection 
establishment as kind of proximity assertion. The PSK may be provided using a 
QR code on the pledge(-callee). Intention was to address potential DoS attacks 
on the pledge.
After further discussion, the actual target for a potential DoS is most likely 
the registrar and not the pledge(-callee). The pledge is also assumed to be not 
in operation and providing services at this point in time.

As discussed in the ANIMA WG meeting, it is proposed now to use plain HTTP for 
communication between pledge(-callee) and registrar-agent. The registrar-agent 
can also provide data to the pledge(-callee) to be included in the pledge 
voucher-request, this can be verified by the registrar and by the MASA. The 
provided data relates to the registrar certificate, which may be included in 
the pledge voucher-request as new leaf "agent-provided-registrar-certificate".

The registrar-agent supplies the pledge voucher-request to the registrar. The 
registrar performs acceptance checks for pledge bootstrapping in its domain 
based on IDevID and maybe additional pledge voucher-request payload data as in 
BRSKI.
After registrar and MASA performed the verification of the voucher-request 
successfully, MASA creates a voucher to be returned to the pledge. If the 
pledge voucher-request contained a registrar certificate marked as 
"agent-provided-registrar-certificate", existing voucher assertions "verified" 
or "logged" could be used, but not "proximity".
May be a more direct indication of agent proximity would be to define a new 
assertion like "agent-proximity".

Any thoughts on the approach?

Best regards
Steffen

--
Steffen Fries
Siemens AG


--
Steffen Fries
Siemens AG
T RDA CST
Otto-Hahn-Ring 6
81739 Muenchen, Germany 
Tel.: +49 89 780-522928
Fax: +49 89 636-48000
mailto:steffen.fr...@siemens.com
www.siemens.com

Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann 
Snabe; Managing Board: Roland Busch, Chairman, President and Chief Executive 
Officer; Klaus Helmrich, Cedrik Neike, Matthias Rebellius, Ralf P. Thomas, 
Judith Wiese; Registered offices: Berlin and Munich, Germany; Commercial 
registries: Berlin-Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. 
DE 23691322

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

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

[Fries, Steffen]

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 in 
the draft)
It is proposed to assume an already available LDevID on the registrar-agent 
(former pledge-agent), as it is considered to be a site/domain component. This 
LDevID can be provided by a prior BRSKI run or by other means.
The registrar-agent uses this LDevID for (D)TLS client authentication at the 
protected registrar endpoints.

Any objection or thoughts?

Best regards
Steffen

--
Steffen Fries
Siemens AG

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

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

[Fries, Steffen]

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 terminology PULL and PUSH may lead to misunderstanding to 
which component the model actually applies. The term should clarify, that the 
pledge is either acting as a client or as a server.
Based on this it is proposed to rename:
-  PULL mode to pledge-client mode (pledge initiates the bootstrapping)
-  PUSH mode to pledge-server mode (pledge is waiting for being triggered for 
bootstrapping

Anyone opposed? 

Best regards
Steffen

--
Steffen Fries
Siemens AG

--
Steffen Fries
Siemens AG
T RDA CST
Otto-Hahn-Ring 6
81739 Muenchen, Germany 
Tel.: +49 89 780-522928
Fax: +49 89 636-48000
mailto:steffen.fr...@siemens.com
www.siemens.com

Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann 
Snabe; Managing Board: Roland Busch, Chairman, President and Chief Executive 
Officer; Klaus Helmrich, Cedrik Neike, Matthias Rebellius, Ralf P. Thomas, 
Judith Wiese; Registered offices: Berlin and Munich, Germany; Commercial 
registries: Berlin-Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. 
DE 23691322

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

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

[Fries, Steffen]

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 for the component between the pledge(-callee) and 
the registrar is pledge-agent. This component is supporting the registrar and 
is considered to be a site/domain component with own LDevID credentials.

Therefore we propose to change the terminology to registrar-agent.

Anyone opposed? 

Best regards
Steffen

--
Steffen Fries
Siemens AG

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

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

[Fries, Steffen]

> 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
> > is handled in BRSKI-AE. The motivation for now was to have it to avoid
> > DoS attacks on the pledge.
> 
> Understood.
> Christian Amsuss has done some work with CoAP over the websocket version of
> BTLE/NFC (Please correct me here).  The idea being that we could do EDHOC or
> some such over that link.  That wouldn't be an IPv6 link.
> 
> A reason for this interest is that this interface is available to one-page 
> WEB apps
> on a smartphone via Javascript, while mucking around with IPv6 over BTLE or
> changing wifi access points is a serious pain on smartphones.
> 
> This provides a fair bit of physical proximity, which I think can mitigate 
> the DOS
> attack concern.  Really, we need to do some experiments here with some kind
> of spike solution.
> 
> EDHOC, running over CoAP, should be relatively happy with the store-and-
> forward mechanism that BRSKI-AE would like.
Wouldn't this still require that the pledge is able to verify the certificate 
of the pledge-agent during the first contact? The pledge authentication at the 
pledge-agent is probably easier, if we assume the pledge-agent knows the 
signing certificate of the pledge manufacturer. We run into a similar issue 
with the discussion when using TLS. The pledge (acting as server in PUSH) 
itself does not have a certificate the has the correct subjectAltName (and the 
key usages) to perform the verification on the pledge-agent side. Also, the 
Pledge would not be able to authenticate the pledge-agent until it receives the 
voucher.

> 
> > If we assume that the likelihood for DoS
> > attacks is higher on the registrar side, it is important to protect the
> > registrars endpoints.
> 
> I think that we can handle attacks on this side.
Yes, that is why we though to utilize the same endpoints (via https)


> >> It feels that something like either Delegated STAR could work well.
> >> Or, if not that, and we are using TLS, then draft-ietf-tls-subcerts-10
> >> Failing that, we need to create some kind of JWT, or CWT artifact
> >> which the Registrar uses to bless the pledge-agent.
> 
> > Currently, the proposal would be to utilize an LDevID between the
> > pledge-agent and the registrar. It can be provided either by a separate
> > BRSKI run to the pledge-agent or manually.
> 
> Agreed, that's what I had in mind as well.
> 
> > connecting or a pledge-agent based on the utilized certificate (IDevID
> > or LDevID). I would like to discuss the trust relations in the next
> > design team meeting.
> 
> Awesome!
> 
> >> I find the PULL/PUSH terminology confusing.  I recognize that the
> >> directionality that is implied by the PULL/PUSH is based upon, I
> >> thought, whether the RFC8366 voucher is retrieved by the pledge, or
> >> provided to the pledge.  But, in section 5.1, I think that it's called
> >> PULL because the communication with the RA?
> 
> > The naming PULL and PUSH was motivated by the pledge behavior, that it
> > either PULLs information from the registrar or that it is pushed with
> > the information from the pledge-agent. From a naming perspective we
> > already introduced some further names like pledge(-callee) in the PUSH
> > case, as the pledge is acting as a server while in the PULL case the
> > pledge acts as a client.  So one option would be to state pledge-client
> > (UC1) and pledge-server (UC2). Would you have further suggestions for a
> > naming? We could also discuss this in the next design team meeting.
> 
> I suggest we refer to it as "pledge-initiated onboarding" (PULL), or 
> "registrar (or
> pledge-agent) initiated onboarding".
A further alternative may be pledge-client or pledge server.

> Also, it is a Pledge-Agent, or is it really a Registrar-Agent?
> 
> (In real-estate: we have seller's agent or buyer's agent...)
Yes, this is some point I already put on the slides to have a change in 
terminology. We discussed this and the agent is actually acting rather as a 
registrar agent, specifically in the case were it has an LDevID.

Best regards
Steffen

> 
> 
> --
> Michael Richardson. o O ( IPv6 IøT consulting )
>Sandelman Software Works Inc, Ottawa and Worldwide
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima