respect to the examples nits, the focus of
draft-ietf-anima-jws-voucher is on voucher objects.
More concrete use cases should be described in other specifications,
e.g., draft-ietf-anima-brski-prm
Best regards
Thomas
*Von: *Eliot Lear via Datatracker
*Datum: *Montag, 16. September 2024 um
Reviewer: Eliot Lear
Review result: Ready with Nits
This draft describes a JWS-protected RFC-8366 voucher. It is well written and
clear.
Major issues:
None.
Minor issues:
None.
Nits:
I would prefer a more complete test vector in the examples. That is, could you
provide the inputs that
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
d to see that it has 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 po
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 out-o
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.
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.
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
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 & keyboa
> 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 distrib
> 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 operati
[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
>> cour
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 cou
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 maj
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 docume
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
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
>
> 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
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 othe
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 with
> 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 "
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 embarras
> 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.
> 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 me
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 initial
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, ANIMAer
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 line
> 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 bre
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 c
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
__
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 su
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
>> keys/certs
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 recommendati
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 randomness
> 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 s
vailable 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
: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
: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
: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
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
https://dood
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
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
.@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>>
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. Thi
> 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
>
>
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 th
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
> 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 interface exists
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 de
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 available.
> 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
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 think t
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, and
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 objec
> 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
Hi Brian,
I like what I see. This permits the pacing of work as we discussed during the
F2F in Prague with the area director, and allows for building on the
foundational work that is now completing.
Eliot
> On 11 Jun 2019, at 03:02, Brian E Carpenter
> wrote:
>
> Hi all,
>
> I've taken the
h as recommendations made by the registrar
> > provider, or federated services.
> >
> >
> >>
> >> Maybe you want to propose text ?
> >
> > Manual approval by administrator or selection by administrator.
> >
> > Eliot
> >>
> &
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,
>>
the manufacturer" ->
> "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 thi
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 w
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, wo
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
draft-fries-anima-b
---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
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
Draf
ibited. 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 discussi
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 que
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 t
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 yo
> 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 w
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 he
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
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
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 cases,
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
architectural
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 wit
[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 t
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 c
-brski-pop-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:
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 roo
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
de
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.
>
> you
On 02.10.18 00:44, 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.
Eliot
signature.asc
Description: OpenPGP digital signature
__
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 unti
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
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 ord
ential option 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]
The problem is that the manufacturer doesn't have enough context to make
decisions as to which network to join. That is the challenge.
On 12.07.18 17:12, Michael Richardson wrote:
> Eliot Lear wrote:
> > involved. What a manufacturer wants to avoid is a pledge joining a
&
ode 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 manufact
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 para
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.
>
> B
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 to
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
>> pl
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 mos
gt; B.R.
> Bing
>
>> -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 ; anima@ietf.org
>> Subject: 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
> t
Absolutely!
On 18.12.17 20:01, Brian E Carpenter wrote:
> I just noticed that draft-ietf-anima-bootstrapping-keyinfra
> has Intended status: Informational.
>
> Surely it should be Standards Track?
>
> Regards
>Brian
>
>
> ___
> Anima mailing list
On 12/5/17 8:36 PM, Michael Richardson wrote:
> Eliot Lear wrote:
> > +1.
>
> I'd also like to get an early allocation for MUD's OID arc, but at this point
> the MUD document seems like it meant lap BRSKI. I guess that's also Benoit's
> call
>
+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 later
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 should b
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 cas
1 - 100 of 121 matches
Mail list logo