> 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
Adam, Alexey,
version -28 of the document contains a CDDL definiton for the audit-log
response.
https://www.ietf.org/rfcdiff?url1=draft-ietf-anima-bootstrapping-keyinfra-27=draft-ietf-anima-bootstrapping-keyinfra-28
I hope that I'm done now!
--
Michael Richardson , Sandelman Software Works
{clearing out todo items in my inbox}
Joel M. Halpern wrote:
> I presume I am missing something basic.
> I have tried to follow this discussion, as it seems to be about a critical
> aspect of whether the BRSKI work is acceptable.
> I have assumed that what we needed is the
All three of those sound like improvements.
WHichever one you and the working group pick would clearly help.
Thank you,
Joel
On 7/17/2019 5:13 PM, Michael Richardson wrote:
Joel M. Halpern wrote:
> Thank you Michael. I saw the proposed change in section 9. I wonder
> if that is
Joel M. Halpern wrote:
> Thank you Michael. I saw the proposed change in section 9. I wonder
> if that is hiding the MUST, since the mechanisms are in section 7...
> Having said that, I can live with it as you have proposed.
I take your point. Options I see are:
1) swap the
Definitely.
My main point was more about the architecture vs. protocols:
originally, ANIMA was chartered to avoid doing architectures, and it
reflects in the difficulty to even get the reference model document
accepted by our AD (for those who do not remembre). "Create only
documents that
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.
Adam,
Not sure if you saw my reply to Alissas comments, but my biggest concern
no only to fudge more and more bits and pieces into thre tailend of this
draft (+1 to birans comment), but also to continue fudge them as protocol
extensions into the BRSKI protocol when in reality the problems we
Michael --
Thanks so much for your work on closing this issue. Assuming the rest of
the WG agrees with it, your proposed text satisfies my concern. I've
indicated two minor nits below.
On 7/16/19 12:55 PM, Michael Richardson wrote:
As specified in the ANIMA charter, this
With the mandates that Michael proposed adding, I can live with
advancing the document.
Yours,
Joel
On 7/16/2019 4:31 PM, Brian E Carpenter wrote:
Up-levelling the topic a little bit:
It seems to me that from the amount of interest and discussion, BRSKI
is going to be quite important (or a
Up-levelling the topic a little bit:
It seems to me that from the amount of interest and discussion, BRSKI
is going to be quite important (or a resounding failure, in which case
this is all beside the point). Assuming it's a success, there will
inevitably be updates and enhancements.
So, I'd
Adam Roach wrote:
>> On Jul 15, 2019, at 02:39, Eliot Lear wrote:
>>
>> This give you the option for that not to be the case (people needn’t
>> worry about Siemens, Rockwell, JCI, Honeywell, or Schneider Electric
>> going out of business anytime soon, for instance
>
Thank you Michael. I saw the proposed change in section 9. I wonder if
that is hiding the MUST, since the mechanisms are in section 7...
Having said that, I can live with it as you have proposed.
Yours,
Joel
On 7/16/2019 3:47 PM, Michael Richardson wrote:
Joel Halpern Direct wrote:
>
Joel Halpern Direct wrote:
> It allows someone who
> controls their network, and who physically controls a new device, to
> put that new device in their network without asking anyone's
> permission.
Right, get your "blue cable" out, connect it to the serial console, bring up
Adam Roach wrote:
> On 7/15/19 3:38 PM, Brian E Carpenter wrote:
>> On 15-Jul-19 16:45, Joel M. Halpern wrote:
>>> I presume I am missing something basic. I have tried to follow this
>>> discussion, as it seems to be about a critical aspect of whether the
>>> BRSKI work is
> > 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 string comparison or something
Adam Roach wrote:
> "HTTP", but even that may be unnecessary in this case.
> REST means... something. Exactly what depends on who you ask. In
> practice, the least controversial thing to do is avoid the term; and,
> if you're trying to describe a specific quality (e.g.,
Ted Hardie wrote:
> Howdy,
> 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 string
Adam Roach wrote:
mcr> *** but manufacturers have to want to do it ***
adam> I completely agree with everything you just said, and sincerely
adam> thank you for the work you've done in this area. I think where our
adam> perspectives might diverge is our beliefs about what *we*,
> 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/16/2019 9:40 AM, Eliot Lear
I can't tell from this whether you agree that it is reasonable to put in
some mechanism to address this issue?
Yours,
Joel
On 7/16/2019 9:40 AM, Eliot Lear wrote:
Hi Joel,
On 16 Jul 2019, at 14:59, Joel Halpern Direct
wrote:
I am having trouble connecting your reply with my request.
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
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 the theft protection." It is that form of theft
protection that I am objecting to.
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
Adding such scope text, along with the mechanism to get the needed
credentials, would be fine with me.
Joel
On 7/15/2019 6:28 PM, Brian E Carpenter wrote:
Joel,
I'd be happy with that as long as there is a scope statement that makes
it clear to the reader.
Regards
Brian
On 16-Jul-19
Joel,
I'd be happy with that as long as there is a scope statement that makes
it clear to the reader.
Regards
Brian
On 16-Jul-19 09: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
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 problem. And trying to achieve it has the implications
that lead to
On 7/15/19 3:38 PM, Brian E Carpenter wrote:
On 15-Jul-19 16:45, Joel M. Halpern wrote:
I presume I am missing something basic.
I have tried to follow this discussion, as it seems to be about a
critical aspect of whether the BRSKI work is acceptable.
I have assumed that what we needed is the
On 15-Jul-19 16:45, Joel M. Halpern wrote:
> I presume I am missing something basic.
> I have tried to follow this discussion, as it seems to be about a
> critical aspect of whether the BRSKI work is acceptable.
>
> I have assumed that what we needed is the ability for a buyer, who has
>
> On Jul 15, 2019, at 02:39, Eliot Lear wrote:
>
> To Adam’s broader point, there are at least several ways to approach this.
> We can leave it to the vendor to decide which is correct, and we can continue
> to look to standardize ideas such as the one Michael had in the message I’m
>
> On Jul 15, 2019, at 02:39, Eliot Lear wrote:
>
> This give you the option for that not to be the case (people needn’t worry
> about Siemens, Rockwell, JCI, Honeywell, or Schneider Electric going out of
> business anytime soon, for instance
When I started IETF work, Nortel would have been
> 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, upon request, a voucher that it
I presume I am missing something basic.
I have tried to follow this discussion, as it seems to be about a
critical aspect of whether the BRSKI work is acceptable.
I have assumed that what we needed is the ability for a buyer, who has
physical possession of the device, and possibly some simple
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, upon request, a voucher that it has signed
> with its own iDevID. It would have to be nonceless
Eliot> I think the simplest way to address the bulk of both Adam’s and
Eliot> Warren’s concern is to require the device to emit via whatever
Eliot> management interface exists, upon request, a voucher that it has
Eliot> signed with its own iDevID. It would have to be nonceless with
Eliot>
Eliot Lear wrote:
> 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.
I beg to differ!
I think that the security properties are vastly different.
It's why we decided when creating RFC8366 not
Thanks for your reply. Responses to questions below.
On 7/12/19 4:07 PM, Michael Richardson wrote:
>
---
> §5.6
>> {
>> "ietf-voucher:voucher": {
>> "nonce": "62a2e7693d82fcda2624de58fb6722e5",
Max and Toerless, please search for your name.
Adam Roach via Datatracker wrote:
> §2.1
>> |+--v---+
>> || (5) Enroll |<---+ (non-error HTTP codes )
>> ^+ |\___/ (e.g. 201 'Retry-After')
>> | Enroll
FYI what you all are discussing are potential changes to the normative language
of
https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-22#section-7.2
Probably strengthening this paragraph from MAY/SHOULD to a MUST:
3. The pledge MAY have an operational mode where it skips
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
On 12-Jul-19 10:52, Adam Roach wrote:
> On 7/11/19 3:05 PM, Michael Richardson wrote:
>> <#secure method=pgpmime mode=sign>
>>
>> Adam Roach via Datatracker wrote:
>> > §5.8:
>>
>> >> Rather than returning the audit log as a response to the POST (with a
>> >> return code 200), the
On 7/11/19 3:05 PM, Michael Richardson wrote:
<#secure method=pgpmime mode=sign>
Adam Roach via Datatracker wrote:
> §5.8:
>> Rather than returning the audit log as a response to the POST (with a
>> return code 200), the MASA MAY instead return a 201 ("Created")
>> RESTful
On 7/11/19 2:55 PM, Michael Richardson wrote:
EXECSUM: Please stop beating us up for having solved the problem that the WG
charter said we we should solve, and for having not solved a
problem that the WG charter said was out-of-scope.
I apologize if the objection came off
> 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 via whatever management interface
>>
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 via whatever management interface
> exists, upon request, a voucher that it has signed with its own
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 the simplest way to
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,
Howdy,
On Thu, Jul 11, 2019 at 1:02 PM Michael Richardson
wrote:
>
> Adam Roach via Datatracker wrote:
> > §5:
>
> >> MASA URI is "https://; iauthority "/.well-known/est".
>
> > This doesn't make sense: iauthority is a component of IRIs, not of
> URIs. In
> > URIs this is
Adam Roach via Datatracker wrote:
> §5:
>> MASA URI is "https://; iauthority "/.well-known/est".
> This doesn't make sense: iauthority is a component of IRIs, not of URIs.
In
> URIs this is simply an "authority." It's not simply a terminology
distinction:
> converting
EXECSUM: Please stop beating us up for having solved the problem that the WG
charter said we we should solve, and for having not solved a
problem that the WG charter said was out-of-scope.
Adam Roach via Datatracker wrote:
> In short, beyond the user-hostile effects of
50 matches
Mail list logo
