Re: [Anima] [lamps] RFC8994/8995 requirements for CSRattr

needs to be an entity trusted by the CA, so it should not be a problem that it re-builds the CSR.,     David On 01.09.21 15:29, Eliot Lear wrote: David, I mention that point because we already done this in one case with a CA, and my concern is that our code will bloat as we have to customize to oth

Re: [Anima] [lamps] RFC8994/8995 requirements for CSRattr

been decided to update/correct the CSRattrs mechanism of RFC 7030.     David On 30.08.21 09:40, Eliot Lear wrote: I would suggest that it helps in these cases to back up to the scenarios we care to address, and the likelihood of success.  In some cases, it will be possible to coordinate

Re: [Anima] [lamps] RFC8994/8995 requirements for CSRattr

I would suggest that it helps in these cases to back up to the scenarios we care to address, and the likelihood of success.  In some cases, it will be possible to coordinate development with the endpoints and sometimes with the CAs.  The CAs may not be strongly motivated to standardize an

Re: [Anima] [lamps] discussing EST CSRATTRS specifying the SAN at IETF111

So voluntold. On 06.07.21 20:44, Russ Housley wrote: LAMPS chairs: can we have ten minutes for this discussion on the Thursday Session III meeting at IETF111? The Monday Session II is conflicted with ANIMA. I'm gonna voluntold Eliot to lead this discussion :-) Yes, I'll add it.

Re: [Anima] [Iotops] BRSKI and IDevID (non-!)issues with draft-ietf-uta-use-san

Rich, As I wrote, I think we’re past it, because this is about domain/IP address validation and not client cert validation. Correct? Eliot > On 14 May 2021, at 16:02, Salz, Rich wrote: > >> There are a VAST number of devices that run off of iDevIDs: they never >> transition off of them.

Re: [Anima] [Iotops] BRSKI and IDevID (non-!)issues with draft-ietf-uta-use-san

Hi, I think we’re past this, but just to be clear: There are a VAST number of devices that run off of iDevIDs: they never transition off of them. I’m not a fan, but that’s what they do. Eliot > On 14 May 2021, at 02:22, Michael Richardson wrote: > > Signed PGP part > > I read the document

Re: [Anima] AUTH48 request for CSR example

No. > On 14 Apr 2021, at 11:04, Brian Carpenter wrote: > > Is this worth the extra delay? A change like this is hardly editorial & I do > not think we want to wait for a mini last call. I am against any > non-essential change. > > Regards, > Brian Carpenter > (via tiny screen &

Re: [Anima] [lamps] Long-lived certificates, but frequently renewed certificates

> On 22 Mar 2021, at 22:28, Nico Williams wrote: > > End entities send a validation chain for their EE certs, but not the > root CA's cert, and anyways, RPs need to know trust anchors a priori. > Therefore rolling out new TAs is tricky. The presumption we make in the enterprise is that

Re: [Anima] [lamps] Long-lived certificates, but frequently renewed certificates

> On 20 Mar 2021, at 19:00, Michael Richardson wrote: > > It has to be a three phase commit, and it needs to be initiated from the EST > server. See my answer to Nico. The EST server certainly knows when it wants to roll the information. But doing so in the middle of a heart bypass

Re: [Anima] [lamps] Long-lived certificates, but frequently renewed certificates

[Reducing] Hi Nico, > On 20 Mar 2021, at 21:36, Nico Williams wrote: >> >> This is definitely a problem in a number of deployments. One aspect >> that people have to deal with is not so much the gross expiry time, >> but when it is convenient to take a risk of moving to a new cert. Of >>

Re: [Anima] [lamps] Long-lived certificates, but frequently renewed certificates

Hiya, > On 18 Mar 2021, at 19:58, Michael Richardson wrote: > > A pity that EST (and I think SCEP, but I haven't read it all), just returns > the resulting certificate, and not something more useful, like a JSON dict > that includes the certificate. > > RFC7030 has a 202, Retry-After, which

Re: [Anima] Erik Kline's Discuss on draft-ietf-anima-autonomic-control-plane-28: (with DISCUSS and COMMENT)

Hi Erik I wonder if the simpler fix is simply to replace the word “counterpart” with “analog”. Eliot > On 27 Sep 2020, at 23:52, Erik Kline wrote: > > Toerless, > > Thanks for taking the time to go through all this. Generally LGTM, but I > would like to iterate on the ULA text (nothing

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

Steffen I enjoyed today’s discussion. My suggestion is a short document that does not CHANGE endpoints but simply creates new ones that have the same functionality as the old ones. That doesn’t require an “Updates” header, and based on that I think you might even keep these in the same

Re: [Anima] ANIMA: Reminder: Re: Call for agenda ANIMA @ IETF 108, online

Hi Toerless, The co-authors would like to have a few minutes to talk about BRSKI-AE. I think 10 ought to do. Thanks, Eliot > On 21 Jul 2020, at 05:54, Toerless Eckert wrote: > > Reminder. Please bring forward for any agenda items you want to see.! > > Thanks >Toerless > > On Fri, Jul

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

Hi everyone, As Steffen has just noted, we have posted a WG draft. I want highlight one aspect: > On 10 Jul 2020, at 09:39, Fries, Steffen wrote: > > o Inclusion of discovery options of enrollment endpoints at the > domain registrar based on well-known endpoints in Section 5.3 as >

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

> On 2 Jul 2020, at 19:29, Michael Richardson wrote: > > Signed PGP part > > Eliot Lear wrote: >> I have no objection. My only caution is that otherName is poorly >> supported in the open source tool sets, but that is something we could >> conceivably work

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

I have no objection. My only caution is that otherName is poorly supported in the open source tool sets, but that is something we could conceivably work on. Eliot > On 2 Jul 2020, at 15:29, Toerless Eckert wrote: > > Dear WG (ACP author head/hat on) > > ACP Revision -26 introduced a new

Re: [Anima] Russ: Re: rfc822Name use in Autonomic Control Plane document

Hi Toerless, I think either a URI or otherName are pretty much functionally equivalent. I might go with URI for one particular reason, which is that the tooling – in particular OpenSSL – will handle it better. Eliot > On 30 Jun 2020, at 18:10, Toerless Eckert wrote: > > Just had a call

Re: [Anima] representing ACP info in X.509 certs

> On 24 Jun 2020, at 11:39, Toerless Eckert wrote: > > Thanks, Eliot, > > inline > > On Wed, Jun 24, 2020 at 09:04:59AM +0200, Eliot Lear wrote: >> With ACP it???s clear they are overloading semantics of an rfc822name, > > What is your definition of "

Re: [Anima] representing ACP info in X.509 certs

Hi there, > On 24 Jun 2020, at 02:55, Michael Richardson wrote: > > Signed PGP part > > Stephen Kent wrote: >> The simple answer is that when, in the past, developers have chosen to abuse >> the semantics of subject name fields in certs, the result shave been VERY >> long lasting, and

Re: [Anima] Moving forward with draft-ietf-anima-autonomic-control-plane

> On 23 Jun 2020, at 17:28, Eric Rescorla wrote: > > > > Oh it does the DV. It just adds garbage into the cert :-( > > I'm talking about the second sentence, which requires that the SAN contain > only dNSName or IPAddress. Regardless, the garbage that is left in was the point of my note.

Re: [Anima] Moving forward with draft-ietf-anima-autonomic-control-plane

> On 23 Jun 2020, at 14:01, Eric Rescorla wrote: > > I don’t know if the group looked at this, but I can say that from a public CA > standpoint, it’s not much different from otherName because there is a > requirement to validate the name. A new URI scheme would require a new > resolution

Re: [Anima] Moving forward with draft-ietf-anima-autonomic-control-plane

Hi Ben > On 23 Jun 2020, at 05:31, Benjamin Kaduk wrote: > > Russ has been helping reach out to more of the PKIX community; one > suggestion that came up so far is to consider defining a dedicated URI > scheme and using a uniformResourceIdentifier SAN -- did the WG consider > that in the

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

Hi Sheng Thanks for initiating this call. As one of the co-authors, it should surprise you not at all the I have read it, and indeed have modestly contributed to it (Steffen did the heavy lifting). I support its adoption. Eliot > On 18 Jun 2020, at 11:27, Sheng Jiang wrote: > > Hi,

Re: [Anima] rfc822Name use in Autonomic Control Plane document

Ok, so I just want to add that I have been able to populate otherName with garbage and have it get signed by a public CA. My point is that at least some public CAs are loose. If LE is important to this space, and if it’s really important, then this is not a solution. Anyway, Here was the

Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-28: (with DISCUSS and COMMENT)

> On 17 Jun 2020, at 18:10, Michael Richardson wrote: > >> >> Now that it is it represents a new convention. The question at hand is >> whether the information found on the LHS could be subject to >> misinterpretation by non-participants. I wonder if we could add an EKU >> as a SHOULD to

Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-28: (with DISCUSS and COMMENT)

Hi, Could we recap a bit on this? I have commented on the use of the rfc822Name myself, and was a bit concerned about misuse and misinterpretation prior to rfcSELF being present. Now that it is it represents a new convention. The question at hand is whether the information found on the LHS

[Anima] BRSKI-AE

Chairs: The authors of draft-fries-anima-brski-async-enroll-03 have been patiently awaiting follow-up from the previous meeting of this working group in which we came away assuming that there would be a call for adoption. When might we expect that? Eliot

Re: [Anima] draft-ietf-anima-bootstrapping-keyinfra

Hi, IMHO: > On 14 Apr 2020, at 12:03, tom petch wrote: > > The IESG approval of this I-D caused me to look again at it:-( > > I note that part of the formal specification is in CDDL and while other DDL - > ASN.1, SMI, YANG - are bracketed with CODE BEGINS CODE ENDS - the CDDL is > not. I

Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-39: (with DISCUSS and COMMENT)

Hi Ben, > On 31 Mar 2020, at 21:29, Benjamin Kaduk wrote: > > On Tue, Mar 31, 2020 at 08:02:07AM -0700, Benjamin Kaduk wrote: >> >> I am even willing to produce an updated example voucher artifact myself, if >> that would help expedite things -- I believe I already have the needed >>

Re: [Anima] [Iot-onboarding] EST CACerts and Pinned Domain Certificate

Hi Esko > On 24 Mar 2020, at 14:08, Esko Dijk wrote: > > Hello Michael, > > Looking at text in 5.6.2 of BRSKI: > > The 'pinned-domain-cert' is not a > complete distribution of the [RFC7030] section 4.1.3 CA Certificate > Response, which is an additional justification for the

Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-28: (with DISCUSS and COMMENT)

Hi, > On 29 Oct 2019, at 04:18, Benjamin Kaduk wrote: > > I mean, we literally say "Reducing the possibility of this is why the > pledge is mandated to generate a strong random or pseudo-random number > nonce." So to also say "the nonce [...] does not require a strong > cryptographic

Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

> On 16 Jul 2019, at 21:29, Barry Leiba wrote: > >>> I would personally not suggest using IRIs here, given that the scheme >>> (https) is expected to retrieve a resource at a well-known location and >>> thus will always have to be mapped to a URI to do the retrieval (rather >>> than used in a

[Anima] Fwd: Your Webex recording is available for viewing: IoT Onboarding Meeting-20190829 1513-1

is available for viewing: IoT Onboarding > Meeting-20190829 1513-1 > Date: 29 August 2019 at 18:30:59 CEST > To: > Reply-To: > > Hi Eliot Lear, > Your recording is now available on your Webex site. > > IoT Onboarding Meeting-20190829 1513-1 > Thursday, August 29, 2019 > 5

[Anima] IoT Onboarding Virtual Meeting

:16010101T02 TZOFFSETFROM:+0100 TZOFFSETTO:+0200 RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=3 END:DAYLIGHT END:VTIMEZONE BEGIN:VEVENT ORGANIZER;CN=Eliot Lear (elear):MAILTO:el...@cisco.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=iot-onboar d...@ietf.org:MAILTO:iot-onboard

[Anima] IoT Onboarding Virtual Meeting

:16010101T02 TZOFFSETFROM:+0100 TZOFFSETTO:+0200 RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=3 END:DAYLIGHT END:VTIMEZONE BEGIN:VEVENT ORGANIZER;CN=Eliot Lear (elear):MAILTO:el...@cisco.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=iot-onboar d...@ietf.org:MAILTO:iot-onboard

[Anima] Hold for IoT Onboarding Virtual Meeting

:16010101T02 TZOFFSETFROM:+0100 TZOFFSETTO:+0200 RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=3 END:DAYLIGHT END:VTIMEZONE BEGIN:VEVENT ORGANIZER;CN=Eliot Lear (elear):MAILTO:el...@cisco.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=iot-onboar d...@ietf.org:MAILTO:iot-onboard

[Anima] Doodle poll for IoT Onboarding Meeting

Hi everyone, Please if you could, respond to the doodle poll below by the 12th. While I will be on holiday next week, I’ll be sure to send along the meeting details for the meeting once the poll has closed. Proposed Agenda: OPC use case BRSKI IESG review status Other draft status

Re: [Anima] [Iot-onboarding] OPC and BRSKI

10:57, Randy Armstrong (OPC) > wrote: > > HI Eliot, > > Yes, the Operator needs to ensure that only Devices they authorize can > connect and the zero touch provisioning is a feature we desire. > > Regards, > > Randy > > From: Eliot Lear > Sent: August

Re: [Anima] [Iot-onboarding] OPC and BRSKI

want to know that only devices they authorized are connecting (e.g., 802.1X and then like)? This is a natural assumption in the wireless world, but less so in wired. Eliot > > Regards, > > Randy > > > From: Eliot Lear > Sent: August 7, 2019 12:33 AM > To: Randy

Re: [Anima] [Iot-onboarding] OPC and BRSKI

.@ietf.org>> On Behalf Of Randy Armstrong (OPC) > Sent: August 6, 2019 4:17 PM > To: Toerless Eckert mailto:t...@cs.fau.de>> > Cc: iot-onboard...@ietf.org <mailto:iot-onboard...@ietf.org>; anima@ietf.org > <mailto:anima@ietf.org>; Eliot Lear mailto:l...@cisco.com>>

Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

Hi Toerless, > On 17 Jul 2019, at 00:03, Toerless Eckert wrote: > > > Not sure yet how to best do that, hopefully something we can discuss @105. To the general idea… it may be worth setting some time at the end of the ANIMA WG meeting for this, or even in the onboarding/mud side meeting.

Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

> On 16 Jul 2019, at 15:57, Joel M. Halpern wrote: > > I can't tell from this whether you agree that it is reasonable to put in some > mechanism to address this issue? I think I do because I proposed such a mechanism up thread. Eliot > > Yours, > Joel > > On 7/

Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

Hi Joel, > On 16 Jul 2019, at 14:59, Joel Halpern Direct > wrote: > > I am having trouble connecting your reply with my request. > Let's take the direct issue first, and then the analogy. > > I had suggested a specific enhancement to device behavior. The response was > "but that removes

Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

Hi Joel, > On 15 Jul 2019, at 23:42, Joel M. Halpern wrote: > > I would probably go a step further than Adam. Protecting the device so a > thief can not use it in the thiefs' own network seems to me to be something > that we should not be trying to achieve. An active non-goal. It is not our

Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

> On 13 Jul 2019, at 17:10, Michael Richardson wrote: > > Signed PGP part > > Eliot Lear wrote: >> I think the simplest way to address the bulk of both Adam’s and >> Warren’s concern is to require the device to emit via whatever >> management interfac

Re: [Anima] Magnus Westerlund's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS)

Michael, Magnus, I want to reinforce a point I made in that previous discussion about pledges using BRSKI with H2 (and by extension QUIC). In this limited case, both present needless overhead both in terms of dev costs and COGS. H2 in particular, and in this particular case, introduces new

Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

Hi Adam > On 12 Jul 2019, at 00:25, Adam Roach wrote: > > > The smallest change that would satisfy my concern would be a statement that > says that devices conformant to this specification MUST contain a local means > of bootstrapping that does not rely on any specific server being

Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

> On 11 Jul 2019, at 23:48, Benjamin Kaduk wrote: > > On Thu, Jul 11, 2019 at 11:44:55PM +0200, Eliot Lear wrote: >> One thought: >> >> I think the simplest way to address the bulk of both Adam’s and Warren’s >> concern is to require the device to emit

Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

Just to complete the thought: Whether such a voucher would be pinned is something we do not have to specify, with the risks of it not being pinned being born by the owner. Eliot > On 11 Jul 2019, at 23:44, Eliot Lear wrote: > > Signed PGP part > One thought: > > I thin

Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

One thought: I think the simplest way to address the bulk of both Adam’s and Warren’s concern is to require the device to emit via whatever management interface exists, upon request, a voucher that it has signed with its own iDevID. It would have to be nonceless with perhaps a long expiry,

Re: [Anima] Content-Transfer-Encoding and HTTP 1.x in ANIMA BRSKI

I am looking at libest and it certainly generates the header. > On 13 Jun 2019, at 08:27, Carsten Bormann wrote: > > On Jun 12, 2019, at 19:26, Julian Reschke wrote: >> >>> 2) Assuming the answer to (1) is no, what should we make of RFC7030 >>> that says to use it, and to base64 binary

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

> On 11 Jun 2019, at 13:39, Eric Rescorla wrote: > > As I mentioned in another email exchange, why not use two domains under > .example? I missed that. That would be fine with a good example. Eliot > > On Tue, Jun 11, 2019 at 1:40 AM Eliot Lear <mailto:l...@ci

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

mendations made by the registrar > > provider, or federated services. > > > > > >> > >> Maybe you want to propose text ? > > > > Manual approval by administrator or selection by administrator. > > > > Eliot > >> > >> Ch

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

he registrar provider, or federated services. > > Maybe you want to propose text ? Manual approval by administrator or selection by administrator. Eliot > > Cheers > Toerless > > On Wed, Jun 05, 2019 at 01:09:09PM +0200, Eliot Lear wrote: >> Hi Toerless, >>

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

" -> > "the domain (registrar) still needs to authenticate the MASA" ? > (i hope the latter is the correct interpretation of the text) > > Cheers >Toerless > > On Tue, Jun 04, 2019 at 06:33:00PM +0200, Eliot Lear wrote: >> Just on this text: >>

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

Just on this text: In Section 10.3 the following text exists: o A Trust-On-First-Use (TOFU) mechanism. A human would be queried upon seeing a manufacturer's trust anchor for the first time, and then the trust anchor would be installed to the trusted store. There are risks

Re: [Anima] Potential Milestones for ANIMA new charter

Hi Sheng, > On 16 Mar 2019, at 01:56, Sheng Jiang wrote: > > Hi, Eliot, > > As you know, the charter text is different from the milestones. In charter > text, we will have a paragraph to describe the BRSKI relevant works. In > principle, all BRSKI works, even those have not been mentioned,

Re: [Anima] Potential Milestones for ANIMA new charter

Hi Sheng, Forgive me, but I believe that the charter text above the milestones needs a touch up. I also see somewhere around six drafts worth of BRSKI work coming down the pike on their own. They are: draft-ietf-anima-constrained-voucher draft-ietf-anima-contrained-voucher

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

---Original Message- >> From: Michael Richardson [mailto:mcr+i...@sandelman.ca] >> Sent: Tuesday, March 12, 2019 3:35 AM >> To: Eliot Lear >> Cc: Sheng Jiang ; anima-cha...@ietf.org; >> anima@ietf.org >> Subject: Re: [Anima] Call for agenda ANIMA @ IETF 104， Prague

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

Hi Sheng Jiang, I think we had a lengthy conversation about BRSKI next steps, and that we should expect to spend some time on this in ANIMA. I think I count at least four drafts that are worth considering, and Michael might have more in mind: Draft-vanderstock-anima-constrained-join-proxy

Re: [Anima] [Iot-onboarding] On boarding again

d. Please notify us immediately of the error by return > e-mail and please delete this message from your system. > > > > On Wed, Mar 6, 2019 at 2:32 PM Eliot Lear <mailto:l...@cisco.com>> wrote: > Hi everyone, > > For those who are interested in discussing on

[Anima] On boarding again

Hi everyone, For those who are interested in discussing onboarding, I’ve reserved an hour on Wednesday afternoon (27 Mar) at 14:00 at the IETF in Karlin 3. Since our last conversation, a few of us put a bit of an inventory together, regarding the mechanisms that are available. Some of the

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

Hi Sheng, IMHO this would be a good topic to be part of the recharter discussion, and so I would suggest that it come before that. And I think perhaps we indicate the other future work going on with BRSKI. Eliot > On 11 Feb 2019, at 02:42, Sheng Jiang wrote: > > Hi, Steffen, > > How much

Re: [Anima] BRSKI support for asynchronous processing

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

Re: [Anima] BRSKI support for asynchronous processing

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

Re: [Anima] BRSKI support for asynchronous processing

Hi Steffen > On 23 Nov 2018, at 20:27, Fries, Steffen wrote: > > Hi Eliot > >>> We are currently in the process of discussing different scenarios and >>> approaches for the onboarding of (IoT) devices in plants, substations, or >>> cloud-based services. The current BRSKI document provides

Re: [Anima] BRSKI support for asynchronous processing

Hi Steffen > On 23 Nov 2018, at 17:53, Fries, Steffen wrote: > > Hi everyone, > > We are currently in the process of discussing different scenarios and > approaches for the onboarding of (IoT) devices in plants, substations, or > cloud-based services. The current BRSKI document provides here

[Anima] IoT Onboarding discussion summary from Bangkok

Dear Colleagues, [Sorry for the wide distribution- on the other hand, please forward to other interested parties ;-)] Thanks to the 30 or so people who attended the side meeting on IoT onboarding.  We had a pretty good discussion around the fact that there is some fragmentation in the space that

[Anima] side meeting on IoT onboarding

Hi everyone, Thanks to those 30 or so people who participated in a side meeting just after OPSAWG on IoT onboarding.  There was pretty clear agreement that there is at least some fragmentation occurring in onboarding solutions, leading to some confusion amongst some of the players.  In some

[Anima] change of venue: onboarding side meeting

As we seem to have a lot of interest in the topic of onboarding, we are at risk of overflowing the very small room we were assigned.  Therefore, the side meeting will now take place immediately after OPSAWG in Chitlada 2. This meeting is intended as a discussion about whatever common

Re: [Anima] ship and forget use cases for onboarding

Hi Michael, On 22.10.18 21:54, Michael Richardson wrote: > > > https://en.wikipedia.org/wiki/Joe_Isuzu ... I asked google, and I'm not > quite sure I get the connection. Sorry- this was a reference to an earlier message.  There is a mode in which the MASA is acting based on its relationship

Re: [Anima] Fwd: New Version Notification for draft-lear-brski-pop-00.txt

[Christian, read down a ways] On 22.10.18 20:15, Michael Richardson wrote: > Eliot, thanks for this document. If nothing else, it means that > we BRSKI authors can deal with some review comments by pointing to "future > work" :-) > > (A)"request-voucher-with-possession" <-- what about intent to

Re: [Anima] FW: New Version Notification for draft-choi-anima-trust-networking-01.txt

Hi! This is a very interesting draft that addresses an issue industry has been seeing.  One of the challenges within an autonomic system is the establishments of rights, even when a device is identified.  If we look at Figure 6 in your draft, it is very similar to that of the conduit and conduit

[Anima] Fwd: New Version Notification for draft-lear-brski-pop-00.txt

-00.txt has been successfully submitted by Eliot Lear and posted to the IETF repository. Name: draft-lear-brski-pop Revision: 00 Title: Proof of Possession to Devices for Onboarding Document date: 2018-10-20 Group: Individual Submission Pages: 7 URL

Re: [Anima] Secdir last call review of draft-ietf-anima-bootstrapping-keyinfra-16

Hi Michael: On 03.10.18 04:35, Michael Richardson wrote: > 1) you run a half-mind Registrar that is on the secure side of your air-gap, > and it has >a USB interface (or 9-track tape drive... statscan.gc.ca used to run >unidirectional UUCP over 9-track tapes walked across the machine

Re: [Anima] Secdir last call review of draft-ietf-anima-bootstrapping-keyinfra-16

Ted, On 02.10.18 21:10, Ted Lemon wrote: > The problem is that possibly billions of devices will be bricked and > landfilled before this becomes the norm. You really answered your own concern.  Nobody would put up with such an approach that either intentionally bricked* a perfectly functional

Re: [Anima] Secdir last call review of draft-ietf-anima-bootstrapping-keyinfra-16

Randy On 02.10.18 13:21, Randy Bush wrote: >>> when i sell the lightb^Hrouter to mary, of course i reset to factory >>> settings. >> Great.  Mary can register the device with light^hrouter manufacturer >> and life goes on. > iff the manufacturer still exists and the manufacture is willing. > >

Re: [Anima] Secdir last call review of draft-ietf-anima-bootstrapping-keyinfra-16

Hi Christian, On 01.10.18 07:42, Christian Huitema wrote: > If the manufacturer is willing to issue "good until time=X" vouchers, > then in theory you could provide the voucher to your buyer, provided the > time limit of the voucher has not elapsed. If the manufacturer signs a > voucher "good

Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-autonomic-control-plane-16: (with DISCUSS and COMMENT)

Hi Ben, With apologies to the WG for adding a late comment.  On 02.08.18 02:30, Benjamin Kaduk wrote: > In particular, in its current form, it's not clear to me why this document > is targeting the standards-track -- there are lots of places where > determinations of what works best or how to do

Re: [Anima] Revision of scope of MASA in the BRSKI - Reg

Hi Toerless, On 15.07.18 09:19, Toerless Eckert wrote: > Note also that we have not defined cloud-registrar behavior. I > think Eliot wold jus like to add something like WiFi SSID to > vouchers, but i would rather like to see it as a separate > "next-step after enrolment" message There is an

Re: [Anima] Revision of scope of MASA in the BRSKI - Reg

is to also require the >> registrar to provide some proof of ownership to the MASA in the >> VoucherRequest. >> >> From: Anima On Behalf Of Eliot Lear >> Sent: Thursday 12 July 2018 17:38 >> To: Michael Richardson ; anima@ietf.org >> Subject: Re: [Anima] Revision of sc

Re: [Anima] Revision of scope of MASA in the BRSKI - Reg

t code needs to be written, maybe with a few compile-time options. > > More inline. > > On Tue, Jul 10, 2018 at 08:43:30AM +0200, Eliot Lear wrote: >> Hi Toerless, >> >> When we look at this scenario, we should consider several factors: >> >> * The

Re: [Anima] Revision of scope of MASA in the BRSKI - Reg

Hi Toerless, When we look at this scenario, we should consider several factors: * The manufacturer is in a position to control both the MASA and the pledge.  That's useful because it means that there is less interoperability friction if the manufacturer wants to pass additional

Re: [Anima] references to code ? (was: Re: WG Last Call on draft-ietf-anima-bootstrapping-keyinfra-15)

On 31.05.18 20:43, Toerless Eckert wrote: > Thanks, Eliot > > Good point, forgot to ask/mention this point in my previous emails. > > As an ANIMA contributor, i would love for a draft/->RFC like BRSKI to > mention known existing implementations, especially open source, even if just > PoC. > >

Re: [Anima] WG Last Call on draft-ietf-anima-bootstrapping-keyinfra-15

I have reviewed the document and we have a PoC.  I am also aware of others that have done PoC code. I am not aware of any issues. Eliot On 31.05.18 03:56, Toerless Eckert wrote: > Dear ANIMA WG, > > After thorough review and discussions on the mailing list and in bootstrap > meetings, leading

Re: [Anima] Shepherd review draft-ietf-anima-bootstrapping-keyinfra-09

Hi, I'm not Max but I hope you won't mind me commenting in three places: On 02.03.18 23:59, Michael Richardson wrote: > Section 2.1 >> a) The term "Request Join" is only used here, and its IMHO not very logical >> (disclaimer: toerless: en.wikipedia.org/wiki/ESL). It sounds to me like the >>

Re: [Anima] BRSKI over 802.11

Hi Toerless, On this point: On 14.02.18 17:56, Toerless Eckert wrote: > Aka: selecting the best SSID in face of competing offers > multiple or single AP is the type of work i think we should > give some tthought to. Ideally something extensible > where we can in the first spec get away with a

Re: [Anima] BRSKI over 802.11

ng > >> -----Original Message- >> From: Anima [mailto:anima-boun...@ietf.org] On Behalf Of Eliot Lear >> Sent: Thursday, February 08, 2018 5:51 PM >> To: Artur Hecker <artur.hec...@huawei.com>; anima@ietf.org >> Subject: Re: [Anima] BRSKI over 802.11 >> &g

Re: [Anima] BRSKI over 802.11

Artur, I suspect much – but not all – of this could be addressed in EAP. Eliot On 08.02.18 10:24, Artur Hecker wrote: > Hi Michael > > > Sorry, maybe I misunderstood the intention. Is your intention to make it > "standard" or just to make a demonstration? If the latter, then it's OK. It's >

Re: [Anima] early allocation for draft-ietf-anima-voucher

+1. On 12/5/17 4:29 PM, Michael Richardson wrote: > Benoit, draft-ietf-anima-voucher asks for an OID arc: > 8.3. The SMI Security for S/MIME CMS Content Type Registry > > We'd like to do an early allocation for this OID value so that we can update > our examples earlier rather than

Re: [Anima] two EST question/suggestions

On 9/12/17 10:03 PM, Brian E Carpenter wrote: > On 13/09/2017 02:33, Eliot Lear wrote: >> Hi, >> >>> I agree a statement that HTTP2 etc is ok so long as it doesn’t change the >>> possible client state machine… ? >> You need an MTI, and it shoul

Re: [Anima] two EST question/suggestions

Hi, > I agree a statement that HTTP2 etc is ok so long as it doesn’t change the > possible client state machine… ? You need an MTI, and it should be the easiest and most compact thing to implement.  While CoAP would be optimal, HTTP/1.1 is more than sufficient, and the features in 2 in this

Re: [Anima] What is intent ?

Hi Toerless, I've heard MUD called a form of intent, but it's not a perfect fit. MUD expresses needs rather than intent. That is- "I need the network to allow X." One could *infer* an intent, but but such inferences get riskier the higher up the stack one goes. In your case, though, one could

Re: [Anima] Is this how BRSKI/IPIP works?

ails might be needed, eg: > - If a proxy has more than 2^13 interfaces it needs to dynamically allocate > subnet encap addresses. > - A proxy might want to map different subnets to differen registrars for load > balancing. > > Cheers >Toerless > >> On Mon, Jul

Re: [Anima] Is this how BRSKI/IPIP works?

On the other hand, maybe it's fundamental, but is relying on LL in this architecture to go beyond LL boundaries the right thing to do? On 7/17/17 8:34 AM, Michael Richardson wrote: > Toerless Eckert wrote: > > I thought i had asked that question already but not sure, and not

Re: [Anima] Is this how BRSKI/IPIP works?

Hi Brian, On 7/14/17 12:41 AM, Brian E Carpenter wrote: > > That may be true, but for BRSKI as such, the only hard requirement is > an address that is unique on a given link, which is a requirement anyway. > IPIP is more of an issue for the node providing the proxy, which is > hopefully a bit

Re: [Anima] dealing with multiple manufacturer services with a single certificate extension

for my position. > >> On Apr 23, 2017, at 5:23 AM, Eliot Lear <l...@cisco.com >> <mailto:l...@cisco.com>> wrote: >> >> Hi everyone, >> >> Just a quick update on this document. I am preparing for the next >> version of the draft. There is one

[Anima] dealing with multiple manufacturer services with a single certificate extension

Hi everyone, Just a quick update on this document. I am preparing for the next version of the draft. There is one major change contemplated that is not yet addressed. I received feedback from the IETF Chicago meeting regarding how best to structure URLs in manufacturer certificates. There are

Re: [Anima] CRLs in iDevID manufacturer signing certs?

Thanks, Kent. Then it seems to me that we have a MAY floating around for CRL checking on the part of the registrar for BRSKI. Right? Eliot On 3/9/17 7:25 PM, Kent Watsen wrote: > Hi Elliot, > > >> What is the thinking on including CRL pointer in the manufacturer >> signing cert? This

  1   2   >