us to write somehing short about this into rfc8366bis
so readers can understand why this differentiation by KeyIdentifier
may be useful to have.
Cheers
Toerless
On Fri, Jul 23, 2021 at 10:00:40PM +, Max Pritikin (pritikin) wrote:
Inline,
On Jul 23, 2021, at 11:34 AM, Toerless Ecker
Inline,
> On Jul 23, 2021, at 11:34 AM, Toerless Eckert wrote:
>
>
> Unfortunately, i have to pile on instead of just answering:
>
> I can not remember that we ever constructed a case where his
> field was necessary when we wrote rfc8366. At least, we did
> not document it e.g. in the examples
On the discussion of what the ‘pinned-domain-cert’ is please refer to the
language of RFC8366:
leaf pinned-domain-cert {
type binary;
mandatory true;
description
"An X.509 v3 certificate structure, as specified by RFC 5280,
using Distinguished E
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 vo
inline comments,
> On Jul 10, 2019, at 6:34 PM, Michael Richardson wrote:
>
>
> Roman Danyliw via Datatracker wrote:
>> (5) Section 1.3.2. Cite the origin of the taxonomy which defines
>> “class 2+” devices – likely RFC7228
>
> done.
>
>> (6) Section 1.5. Per “Upon successfully validating
On Dec 11, 2018, at 3:16 PM, Michael Richardson
mailto:mcr+i...@sandelman.ca>> wrote:
Jim Schaad mailto:i...@augustcellars.com>> wrote:
Clarification requested - exactly what element is the Registrar?
It's an EST RFC7030 term, but essentially it's the server that connects to
(or is) the CA.
> On Dec 11, 2018, at 3:23 PM, Michael Richardson wrote:
>
>
> Panos Kampanakis (pkampana) wrote:
>> I was assuming it was mandatory in the current draft, but I was wrong. As
>> you suggest it is not clear in the -17 version. I do think that an unsigned
>> voucher should make it to the MASA,
Great thread you all. Some key points for response follow. Additionally we’re
working through each numbered comment specifically.
Generally lets keep the scope of BRSKI in mind. It is a new protocol for
bootstrapping via vouchers. It does not preclude the use of a local console for
bootstrappi
> On Jun 19, 2018, at 9:20 AM, Carsten Bormann wrote:
>
> Hi Michael,
>
> 2.2.2 says:
>
> It is not an error if a name is first used with a "/=" or "//="
> (there is no need to “create it" with "=“).
We must have absorbed this sentence w/o noticing it.
>
> The intention is indeed to s
On Jun 15, 2018, at 8:38 PM, Michael Richardson
mailto:mcr+i...@sandelman.ca>> wrote:
Michael Richardson mailto:mcr+i...@sandelman.ca>> wrote:
5) use the existing /voucherrequest, but define the result (when an
application/cbor+cose voucher request is presented) to be a multipart
result, with
what is wrong with going simple: “constrained voucher request” ?
- max
> On Jun 1, 2018, at 9:10 AM, Michael Richardson wrote:
>
>
> Michael Richardson wrote:
>> Also, a related question is whether ietf-cwt-voucher-request to inherit
>> from BRSKI's ietf-voucher-request, or from ietf-voucher
> On Mar 12, 2018, at 4:12 PM, Toerless Eckert wrote:
>
>
> Hi Sheng,
>
> Not that many actual new draft/work-items, but lots of activity going
> on, hee's what's on my contributor plate:
>
> 1. draft-ietf-anima-autonomic-control plane
> 5 min IESG review update
>
> 2. draft-eckert-anima-g
> On Feb 20, 2018, at 7:38 PM, Toerless Eckert wrote:
>
> Thanks, Michael
> Can't see a commit on github since 6 dyays ago, maybe in different branch ?
> Comments for now therefore inline against your email.
>
> On Tue, Feb 20, 2018 at 07:54:40PM -0500, Michael Richardson wrote:
>>
>> Toerles
> On Feb 15, 2018, at 10:14 AM, Toerless Eckert wrote:
>
> On Thu, Feb 15, 2018 at 04:06:33PM +0000, Max Pritikin (pritikin) wrote:
>>>> b) Key infrastructure
>>>
>>>> There is no definition/reference for this term. Please describe on
>
> On Feb 14, 2018, at 7:45 PM, Michael Richardson wrote:
>
>
> Toerless Eckert wrote:
>> 1.2) Terminology:
>
>> a) vendor vs. manufacturer.
>
>> The document uses 48 times "vendor" and 13 times "manufacturer". Please
>> revisit this: If there is a clear reason when/why to use vendor and whe
Much thanks for Michael Richardson for putting these diffs together. Comments
inline,
> On Feb 14, 2018, at 1:09 PM, Michael Richardson wrote:
>
>
> tl:dr: https://github.com/anima-wg/anima-bootstrap/pull/41
>
> https://www.ietf.org/rfcdiff?url1=draft-ietf-anima-bootstrapping-keyinfra
On Dec 14, 2017, at 9:32 AM, Eric Rescorla
mailto:e...@rtfm.com>> wrote:
On Thu, Dec 14, 2017 at 8:29 AM, Max Pritikin (pritikin)
mailto:priti...@cisco.com>> wrote:
On Dec 14, 2017, at 8:43 AM, Eric Rescorla
mailto:e...@rtfm.com>> wrote:
On Thu, Dec 14, 2017 a
On Dec 14, 2017, at 8:43 AM, Eric Rescorla
mailto:e...@rtfm.com>> wrote:
On Thu, Dec 14, 2017 at 7:40 AM, Michael Richardson
mailto:mcr+i...@sandelman.ca>> wrote:
Eric Rescorla mailto:e...@rtfm.com>> wrote:
> The case I am concerned with right now is the case where the attacker
> jus
I don’t see why the voucher actually has to be expired before obtaining a
refresh.
The creation time would of course be updated.
Michael’s point that a Registrar could use this to force the MASA to perform
crypto operations is valid. As implied the fix is to allow the MASA to simply
return a c
Fantastic!
It looks like you went ahead and dropped them all into Master. I’ll read
through the diffs and comment if I have concerns (later this evening).
- max
> On Oct 3, 2017, at 1:09 PM, Michael Richardson wrote:
>
>
> Max, as agreed in today's call, I went through the todo of edits, an
Any protocol work needs balance future proofing (anticipating changes in the
MTI) against clear and definitive statements to meet the current requirements.
If there are places where the current language falls down commenting on that
specific language would help.
Re the HTTP/2 discussion:
HTTP
/d8aeff53fd048c07cebcc88828558c6bafc179df
- max
> On Sep 8, 2017, at 3:24 PM, Max Pritikin (pritikin)
> wrote:
>
> I’ve commented inline about these discussion.
>
> I’ve also prepared a set of diffs to help bring clarity as per the
> discussion. The diffs are in this bra
> On Aug 29, 2017, at 2:31 PM, Michael Richardson wrote:
>
>
> Max, I suggest that we add some text to section 2 to indicate that BRSKI EST
> connections SHOULD be HTTP 1.1 persistent connections.
> I wrote:
>Establishment of the TLS connection for bootstrapping is as
> specif
ael Richardson wrote:
>
>
> Max Pritikin (pritikin) wrote:
>> The voucher-request has this additional requirement:
>
>> s3.3 of BRSKI-07,
>> The request is a "YANG-defined JSON
>> document that has been signed using a PKCS#7 structure" as
>&g
> On Sep 5, 2017, at 6:09 PM, Michael Richardson wrote:
>
>
> PKCS7 artifacts have three things in them:
> 1) the content (technically optional, but we need them)
> 2) a set of SignerInfo objects on the content.
> 3) within the SignerData, a bag of certificates, one or more of which has
> sig
re: "this case must work”
There sure is a lot of complexity in this thread to ensure that link local
addresses can be used outside of the local scope.
Some simpler suggestions,
1) a stateful proxy. I know, I know. But how many devices are actually going to
need to perform BRSKI at the same ti
Brian, I’m out for a couple of weeks but wanted to thank you for this note.
Michael Richardson will likely have good comments but for now I’ve set a
calendar event to catch up when I return and also have created a github issue
to track this.
https://github.com/anima-wg/anima-bootstrap/
Toerless (the other working group chair) has been involved in conversations
concerning the open issues listed on the github repository for the voucher
document.
The issues should be resolved now as per the current status in github. See here
for details of three open issues remaining:
https://git
PM, Michael Richardson wrote:
>
>
> Max Pritikin (pritikin) wrote:
>> From https://tools.ietf.org/html/rfc2616#section-9.5
>
>> The action performed by the POST method might not result in a
>> resource that can be identified by a URI. In this case, either 200
&
> On Jun 5, 2017, at 4:22 PM, Brian E Carpenter
> wrote:
>
> This version includes a second round of responses to IESG comments.
>
> We may not be done yet, but please check the diffs. Here are the main changes:
>
> Removed all mention of TLS, including SONN, since it was under-
> specifi
>From https://tools.ietf.org/html/rfc2616#section-9.5
The action performed by the POST method might not result in a
resource that can be identified by a URI. In this case, either 200
(OK) or 204 (No Content) is the appropriate response status,
depending on whether or not the response i
The -06 version is posted. We are midstream and expect to keep working on this.
In particular the voucher document is currently undergoing focused update and
we expect an -07 of BRSKI to be published soon after to reflect those updates.
- max
___
A
ing your concerns. To help we’ll
push the 06 version of the doc to give you a better reference for generating
feedback.
- max
>
> Toerless
>
> On Tue, Apr 18, 2017 at 05:07:18PM +, Max Pritikin (pritikin) wrote:
>>
>> Peter,
>>
>> The current text is
> On May 2, 2017, at 7:22 PM, Kent Watsen wrote:
>
>
> I've had some time now to investigate JWS, in particular, reproducing some
> examples in RFCs 7515 and 7520 using nothing but shell scripts and the
> `openssl` command line utility.
Excellent. I look forward to hearing what tool you used
I most likely will be missing the bootstrapping discussion this week. I’ll try
to join as possible.
I should be on email and hope to push some git updates.
My apologies if I can’t join. I will check the etherpad for notes or hope to
see something posted to the list,
- max
___
I’ve been agitating for a combined form. My thanks to Eliot for continuing the
conversation. Below I provide some details from the current BRSKI draft to
flesh out the conversation and then present an argument for my position.
On Apr 23, 2017, at 5:23 AM, Eliot Lear mailto:l...@cisco.com>>
wro
Kent,
> On Apr 21, 2017, at 4:51 PM, Max Pritikin (pritikin)
> wrote:
>
>>
>> On Apr 21, 2017, at 1:50 PM, Kent Watsen wrote:
>>
>> Hi Max,
>>
>> I think what you're trying to say is that the x5c header is not under
>> the signature
that I see how
to do testing using openssl like this I can have my own little hackathon. ;)
- max
>
> K.
>
> -ORIGINAL MESSAGE-
>
> Kent,
>
>> On Apr 20, 2017, at 6:55 PM, Max Pritikin (pritikin)
>> wrote:
>>
>>>
>>> On Apr
Kent,
> On Apr 20, 2017, at 6:55 PM, Max Pritikin (pritikin)
> wrote:
>
>>
>> On Apr 20, 2017, at 6:51 PM, Kent Watsen wrote:
>>
>>
>> Hi Max,
>>
>> I'd like to reproduce your experiment, but I can't find a library
>> tha
> On Apr 20, 2017, at 6:51 PM, Kent Watsen wrote:
>
>
> Hi Max,
>
> I'd like to reproduce your experiment, but I can't find a library
> that supports the 'x5c' header. What do you mean that you added
> it (the x5c header) to the JWS?
The x5c header is defined in JWT but the library I used o
7; statements
can be used
to ensure syntactic alignment between the two artifacts.
K.
On 4/19/17, 8:13 PM, "Max Pritikin (pritikin)"
mailto:priti...@cisco.com>> wrote:
FYI - added the below to capture it but not distract myself from current
‘concise’ branch work. As per the r
FYI - added the below to capture it but not distract myself from current
‘concise’ branch work. As per the recommendations I’m informing the list as
well. I’ll circle back to this
- max
https://github.com/anima-wg/voucher/issues/3
There is some inconsistencies in the existing text that need
is is defensible based on the (lack of)
> complexity in JWT and the relatively clean way BRSKI *only extends* EST but
> isn’t optimal for clients. Ensuring that the client can use JWT all the way
> through requires overloading that one EST call. That’s a more substantial
> impact on EST but is
rough requires
overloading that one EST call. That’s a more substantial impact on EST but is
implied by a transition to JWT. Its a really good point.
Cheers,
- max
>
> Rgs,
> Panos
>
>
>
> -Original Message-
> From: Anima-bootstrap [mailto:anima-bootstrap
ocol. A great topic to hear folks on this list comment on.
- max
>
> Cheerio,
>
> Peter
>
>
>
> Max Pritikin (pritikin) schreef op 2017-04-18 20:08:
>> Folks, in Chicago we discussed the signing method for vouchers.
>> Because the voucher is JSON, and there
Folks, in Chicago we discussed the signing method for vouchers.
Because the voucher is JSON, and there is expectation of a CBOR encoding for
future work, there is an open discussion point about using the JWS/COSE signing
methods; if not JWT/CWT. There was brief discussion of this at IETF98 and
nal document, or is it a study that will be used
> later for editing the final document?
>
> Peter
>
> Max Pritikin (pritikin) schreef op 2017-04-15 00:34:
>> For those of you tracking the git repository please note the existence
>> of a new branch. As warned I’m significa
For those of you tracking the git repository please note the existence of a new
branch. As warned I’m significantly reducing the text. This work is going on in
the branch “concise”.
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/lis
+2 (grin)
Factory reset means: back to what the factory shipped. No intermediate states.
(If there is actually a requirement for an intermediate state it can be
developed as part of other/additional work. Such would not be called “factory
reset” it would be something else).
- max
> On Mar 10
I’m am OK with the current anchoring.
It is not clear that the calendaring tools deal with this well so I wanted to
be sure of how it shook out. thanks,
- max
> On Nov 18, 2016, at 5:42 PM, Michael Richardson wrote:
>
>
> Max Pritikin (pritikin) wrote:
>> "time
"time zones are hard”
I think this shifts our meetings — making them occur 1hr earlier than they have
been.
Is that intentional? Am I in error?
- max
> On Nov 17, 2016, at 8:39 PM, Michael Richardson wrote:
>
>
> The Anima Bootstrap design team (which includes work on the ownership
> vouc
The current text around error cases includes:
Section 3.1.1. Discovery
Supports a backoff mechanisms but on review I’m thinking the language about
final failure to be vague:
"Once all discovered services are attempted the device SHOULD return
to Multicast DNS. It should periodically retry
Some comments on the BRSKI discussion inline,
> On Nov 17, 2016, at 3:17 PM, Toerless Eckert wrote:
>
>
> Thanks Brian & Bing
>
> Inline
>
The following quote levels appear to be direct or paraphrases from the
objectives draft.
I’m tempted not even to respond to this email thread due to th
> On Nov 17, 2016, at 3:10 AM, Eliot Lear wrote:
>
> Hi authors,
>
> The Fairhair folk would like some clarity on the following statement in
> Section 3.1.7:
>
>> Functionality to provide generic "configuration" information is
>> supported. The parsing of this data and any subsequent use
detailed discussion in line,
> On Nov 6, 2016, at 11:01 PM, Toerless Eckert wrote:
>
> On Fri, Nov 04, 2016 at 09:23:15PM +0000, Max Pritikin (pritikin) wrote:
>> There is a lot here. Attempting to comment on it all.
>>
>> It would really help if we could relate these d
Assuming we work out the BRSKI questions such that bootstrapping during
disaster recovery is clearly defined I’d imagine the rest of anima work work
“magically” — in that the new equipment added to a network does what it is
intended to do automatically.
- max
> On Nov 13, 2016, at 12:02 AM,
There is a lot here. Attempting to comment on it all.
It would really help if we could relate these discussions to specific text
sections that could be improved. Otherwise we’re just blowing into the wind.
(Where it seems obvious I’ve added such notes).
> On Nov 3, 2016, at 2:40 PM, Toerless
> On Nov 3, 2016, at 6:45 PM, Toerless Eckert wrote:
>
> On Tue, Nov 01, 2016 at 10:42:32PM +0000, Max Pritikin (pritikin) wrote:
>> Taken to the extreme one could argue that we need ANI to be self-contined so
>> depending on IP seems wrong.
>
> Can you explain whe
n the network needs
>> to be up. The only question then is whether the MASA server needs to be
>> up. It is perfectly possible to design a system where that is the case.
>>
>> Eliot
>>
>>
>> On 11/2/16 5:05 PM, Max Pritikin (pritikin) wrote:
>>
My position is that during a large scale disaster it would be foolish of us to
think that security is somehow less important.
BRSKI supports nonceless tokens that can be distributed in advance. These
include the serial number of the device and the domain CA cert so it IS NOT a
"master key".
> On Oct 31, 2016, at 6:59 PM, Brian E Carpenter
> wrote:
>
> Hi Toerless,
> On 01/11/2016 11:18, Toerless Eckert wrote:
>> On Mon, Oct 31, 2016 at 01:23:36PM +1300, Brian E Carpenter wrote:
I am confused about the reason for this discussion. It seems you are trying
to figure out how
> On Jun 20, 2016, at 1:41 AM, Hannes Tschofenig
> wrote:
>
> Michael,
>
> it depends what "bootstrapping" means.
>
> We have a key distribution mechanism in the OAuth-ACE document (which is
> relevant to this specific discussion thread).
>
> Ciao
> Hannes
Hannes, are referencing this state
62 matches
Mail list logo
