I have posted -29, which includes all changes in the past two weeks,
including the informal YANG Doctor review.
Name: draft-ietf-anima-bootstrapping-keyinfra
Revision: 29
Title: Bootstrapping Remote Secure Key Infrastructures (BRSKI)
Document date: 2019-10-28
Group:
Benjamin Kaduk wrote:
>> >> But, that's why we have SHOULD, and the SHOULD (vs MUST) part was
>> really to >> allow for some fancy HTTP/3 we know nothing about :-)
>>
>> > :)
>>
>> > Do we still want to say "HTTP 1.1 persistent connections" vs. "HTTP
>> > persistent
While recovering from today's telechat, I noticed that I seem to have never
replied to this one! (Luckily, there's not much to say...)
On Mon, Sep 16, 2019 at 05:46:37PM -0400, Michael Richardson wrote:
>
> Combining your August 9 and September 3 emails, and removing resolved items.
>
>
Combining your August 9 and September 3 emails, and removing resolved items.
https://tinyurl.com/y2kmjqmm for diffs aginst -26.
(also includes changes for Alexey)
Submitting -27 in process.
Benjamin Kaduk wrote:
>> This was asked by Eric as well.
>> It's the Subject Key Identifier that
Whoops, this one apparently got skipped over amid some other deluge in my
inbox; sorry.
On Sun, Aug 18, 2019 at 04:09:50PM -0400, Michael Richardson wrote:
>
> Benjamin Kaduk wrote:
> > That specific construction would seem like an "optional feature" per
> >
>
On Thu, Aug 15, 2019 at 12:58:45PM -0400, Michael Richardson wrote:
>
> Benjamin Kaduk wrote:
> >> + directly. This is because BRSKI pledges MUST use the CSR Attributes
>
> > (This may not need to be a 2119 MUST since we cite 7030.)
>
> It turns out, in pracice, that many EST clients
Benjamin Kaduk wrote:
>> I guess by WWAN card, you mean some kind of LTE or 5G connection? Or
>> do you mean 802.11/802.15.4? The distinction matters, because LTE
>> cards have SIM cards, and therefore are not zero-touch.
> Um. I think I meant LTE, along the lines of how I
On Wed, Aug 14, 2019 at 09:10:26PM -0400, Michael Richardson wrote:
>
> Benjamin Kaduk wrote:
> >> Are you asking for a forward reference to 10.2? I will add this.
> >> I think that section 10.2 is pretty clear about this.
> >> I don't think it's mentioned just in passing.
>
>
On Thu, Aug 15, 2019 at 01:02:45PM -0400, Michael Richardson wrote:
>
> Benjamin Kaduk wrote:
> >> There does not otherwise seem to be any risk from this compromise to
> >> devices which are already deployed, or which are sitting locally in
> >> boxes waiting for deployment (local
Benjamin Kaduk wrote:
>> There does not otherwise seem to be any risk from this compromise to
>> devices which are already deployed, or which are sitting locally in
>> boxes waiting for deployment (local spares). The issue is that
> (That is, if the boxes are already in local
Benjamin Kaduk wrote:
>> + directly. This is because BRSKI pledges MUST use the CSR Attributes
> (This may not need to be a 2119 MUST since we cite 7030.)
It turns out, in pracice, that many EST clients do not use the CSR
Attributes, so I need this line as a hammer.
>> >
Benjamin Kaduk wrote:
> Apparently I only have one comment buried inline. We must be making
> progress :)
>> > The audit log is a defense against this in that it allows for
>> post-facto > discovery of misuse? Or is there some pre-issuance
>> authorization check > going
Benjamin Kaduk wrote:
doc> The MASA and the registrars SHOULD be prepared to support TLS client
doc> certificate authentication and/or HTTP Basic or Digest
doc> authentication as described in [RFC7030] for EST clients. This
doc> connection MAY also have no client authentication
Benjamin Kaduk wrote:
>> Are you asking for a forward reference to 10.2? I will add this.
>> I think that section 10.2 is pretty clear about this.
>> I don't think it's mentioned just in passing.
> It looks like the main coverage here is:
> o the identity of the device
https://tinyurl.com/y2skc9xz
Benjamin Kaduk wrote:
>> We did not resort to a YANG data model for the auditlog responses, so I
spent
>> a few minutes mystified by your complaint... then:
>> We referenced 7951 (YANG->JSON), but we should have just referenced
RFC7159 (JSON)!
>
https://tinyurl.com/y2skc9xz
Michael Richardson wrote:
>> o The subject-alt field's encoding MAY include a non-critical
>> version of the RFC4108 defined HardwareModuleName. (from [IDevID]
>> section 7.2.9) If the IDevID is stored in a Trusted Platform
>> Module (TPM), then
Apparently I only have one comment buried inline. We must be making
progress :)
On Tue, Aug 13, 2019 at 05:07:46PM -0400, Michael Richardson wrote:
>
> Benjamin Kaduk wrote:
> doc> The authentication of the BRSKI-MASA connection does not affect the
> doc> voucher-request process, as
On Mon, Aug 12, 2019 at 04:23:54PM -0400, Michael Richardson wrote:
>
> Benjamin Kaduk via Datatracker wrote:
> > Section 13.2
>
> > I think CDDL needs to be a normative reference, as does RFC 7231. RFC
> > 2473 is listed but not referenced in the text, as are RFC 2663, RFC
> >
On Mon, Aug 12, 2019 at 03:30:13PM -0400, Michael Richardson wrote:
>
> WG: there is a chunk of Security Considerations text here that I hope
> many will read.
>
>
> Benjamin Kaduk via Datatracker wrote:
> > Section 11.4
>
> > It is not entirely clear to me whether device
On Wed, Aug 14, 2019 at 10:05:13AM -0400, Michael Richardson wrote:
>
> Benjamin Kaduk wrote:
> >> domainID: The domain IDentity is a unique hash based upon a
> >> Registrar's certificate. If the certificate includes the
> >> SubjectKeyIdentifier (Section 4.2.1.2 [RFC5280]), then
On Mon, Aug 12, 2019 at 03:05:44PM -0400, Michael Richardson wrote:
>
> https://tinyurl.com/yylruorn contains a diff against -24.
>
> Benjamin Kaduk via Datatracker wrote:
> > Section 5.8.1
>
> doc>A log data file is returned consisting of all log entries
> associated
> doc>
Benjamin Kaduk wrote:
>> domainID: The domain IDentity is a unique hash based upon a
>> Registrar's certificate. If the certificate includes the
>> SubjectKeyIdentifier (Section 4.2.1.2 [RFC5280]), then it is to be
>> used as the domainID. If not, then the 160-bit SHA-1 hash
Benjamin Kaduk wrote:
doc> The authentication of the BRSKI-MASA connection does not affect the
doc> voucher-request process, as voucher-requests are already signed by
doc> the registrar. Instead, this authentication provides access control
doc> to the audit log.
>>
>> >
On 8/13/19 10:37 AM, Michael Richardson wrote:
Adam Roach wrote:
>> Adam Roach:
https://mailarchive.ietf.org/arch/msg/anima/6AAD9mwsKEsbIUmXRVOAV0N83yA
>> ...
>> This is an rfcdiff from the already-wrapped JSON to the proposed -23
that
>> includes all the changes from
On Sun, Aug 11, 2019 at 12:06:07AM -0400, Michael Richardson wrote:
>
> https://tinyurl.com/yylruorn contains an updated diff against -24.
>
> Benjamin Kaduk via Datatracker wrote:
> > Section 5.2
>
> > application/voucher-cms+json The request is a "YANG-defined JSON
> > document
Adam Roach wrote:
>> Adam Roach:
https://mailarchive.ietf.org/arch/msg/anima/6AAD9mwsKEsbIUmXRVOAV0N83yA
>> ...
>> This is an rfcdiff from the already-wrapped JSON to the proposed -23 that
>> includes all the changes from the various DISCUSSes up to now:
>>
Benjamin Kaduk via Datatracker wrote:
> Section 13.2
> I think CDDL needs to be a normative reference, as does RFC 7231. RFC
> 2473 is listed but not referenced in the text, as are RFC 2663, RFC
> 7217, and RFC 7575.
CDDL->RFC8610, now normative. (Glad that got published)
WG: there is a chunk of Security Considerations text here that I hope
many will read.
Benjamin Kaduk via Datatracker wrote:
> Section 11.4
> It is not entirely clear to me whether device manufacturers are set up
> with incentives to maintain a well-run secure CA with strong
https://tinyurl.com/yylruorn contains a diff against -24.
Benjamin Kaduk via Datatracker wrote:
> Section 5.8.1
doc>A log data file is returned consisting of all log entries associated
doc> with the the device selected by the IDevID presented in the request.
doc> The audit
https://tinyurl.com/yylruorn contains an updated diff against -24.
Benjamin Kaduk via Datatracker wrote:
> Section 5.2
> application/voucher-cms+json The request is a "YANG-defined JSON
> document that has been signed using a CMS structure" as described
> in Section 3 using
On Fri, Aug 09, 2019 at 04:17:17PM -0400, Michael Richardson wrote:
>
> https://tinyurl.com/yylruorn contains a diff against -24.
>
> Benjamin Kaduk via Datatracker wrote:
> > [disclaimer: some of these comments get pretty blunt at the end; it's a
> > long document and I'm tired.
https://tinyurl.com/yylruorn contains a diff against -24.
Benjamin Kaduk via Datatracker wrote:
> [disclaimer: some of these comments get pretty blunt at the end; it's a
> long document and I'm tired. Please try not to get too annoyed if I'm
> failing to see something that's right
On Tue, Jul 16, 2019 at 06:14:37PM -0400, Michael Richardson wrote:
>
> I have responded to DISCUSSes from:
> Alissa Cooper:
> https://mailarchive.ietf.org/arch/msg/anima/QZn8UnsNxtE3MCHm_gPVBl5uSrU
> Roman Danyli:
> https://mailarchive.ietf.org/arch/msg/anima/mff9ZyGBk4EflTqYS6fENWOFRpI
>
On 7/16/19 5:14 PM, Michael Richardson wrote:
Adam Roach:
https://mailarchive.ietf.org/arch/msg/anima/6AAD9mwsKEsbIUmXRVOAV0N83yA
...
This is an rfcdiff from the already-wrapped JSON to the proposed -23 that
includes all the changes from the various DISCUSSes up to now:
I have responded to DISCUSSes from:
Alissa Cooper:
https://mailarchive.ietf.org/arch/msg/anima/QZn8UnsNxtE3MCHm_gPVBl5uSrU
Roman Danyli:
https://mailarchive.ietf.org/arch/msg/anima/mff9ZyGBk4EflTqYS6fENWOFRpI
Alexey Melnikov
Benjamin Kaduk has entered the following ballot position for
draft-ietf-anima-bootstrapping-keyinfra-22: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please
36 matches
Mail list logo
