No, I'm not aware of any IPR that applies to this draft
Russ
On Aug 7, 2023, at 9:20 AM, Joe Clarke (jclarke) wrote:
>
> Ahead of a call for WG adoption of draft-ymbk-opsawg-9092-update, we’d like
> to poll for known IPR.
>
> Authors and contributors on the To: line, please respond on-list
> On Sep 15, 2023, at 1:29 PM, Randy Bush wrote:
>
>> 1/ the new EE certificate uses an 'inherit' element in its RFC3779
>> extension, but section 5 disallows the use of 'inherit' in EEs.
>
> sigh. russ?
Oops. I'll dig into it.
>
>> 2/ given that the example EE was refreshed in -01, the
internet-dra...@ietf.org wrote:
>> Internet-Draft draft-ietf-opsawg-9092-update-02.txt is now available. It is a
>> work item of the Operations and Management Area Working Group (OPSAWG) WG of
>> the IETF.
>>
>> Title: Finding and Using Geofeed Data
>> Aut
Job:
> The example signature chain still is broken :-/
Thank you for your very careful review.
> 1/ The Trust Anchor cert still doesn't mark its RFC 3779
> autonomousSysNum extension as critical. RFC 6487 section 4.8.11
> requires this.
I must have done something very clumsy when I composed
RFC 9092 includes a normative reference to RFC 8805.The shepherd writeup for
draft-ietf-opsawg-finding-geofeeds (which eventually became RFC 8805) calls out
this downref.
The downward references were referenced in the Last Call:
https://mailarchive.ietf.org/arch/search/?q=draft-ietf-opsawg-findi
Tim:
>> (2) Section 6, paragraph 5: is this intended to be a RFC 2119 "MAY"?
>> If so, capitalize. If not, avoid the word.
>
> took me a moment. i think it is para 6, this one, yes?
>
> It is good key hygiene to use a given key for only one purpose. To
> dedicate a signing private key for
Paul:
I am writing to address #3 and #4.
Thanks for your careful review.
> #3 Signature and white space requirements are a bit troubling
>
>Trailing blank lines MUST NOT appear at the end of the file.
>
> That's rather strong. Should the file be rejected if a blanc line appears
> at th
Randy:
>>
>> Suggested edits:
>>
>> The address range of the signing certificate MUST cover all prefixes
>> in the signed geofeed file. If not, the authenticator is invalid.
>>
>> The signing certificate MUST NOT include the Autonomous System
>> Identifier Delegation certificate extens
Randy:
The consumer of geofeed data SHOULD fetch and process the data
themselves. Importing datasets produced and/or processed by a third-
party places significant trust in the third-party.
>>>
>>> this is in sec cons already. you want it moved up or duplicated? i
>>> kinda l
The Authors.
>
>
> From: Russ Housley via Datatracker <mailto:nore...@ietf.org>>
> Date: Thursday, 25 April 2024 at 20:32
> To: sec...@ietf.org <mailto:sec...@ietf.org> <mailto:sec...@ietf.org>>
> Cc: draft-ietf-opsawg-tacacs-tls13@ietf.org
>
I think that the best way forward is to ask SECDISPATCH. I do not think SUIT
is a bad answer, but we have a process to pick.
Russ
> On Jun 14, 2020, at 5:23 PM, Michael Richardson wrote:
>
> Hi, I read draft-moran-suit-mud today.
> It would naturally fall into a MUD WG if we had that.
> As
I do not know about any IPR associated with thie Internet-Draft.
Russ
> Authors, contributors, and WG members, as we are in WGLC for this
> document, we want to solicit knowledge of any IPR that may pertain to
> the draft-ietf-opsawg-finding-geofeeds work.
>
> Please state either, "no, I am not
Responding to just two places where Randy handed off to me ...
>> 3. The definition of canonicalization refers to section 2.2 of RFC
>> 5485 (which talks about ASCII) vs RFC8805 which talks about UTF-8. Is
>> this disparity an issue?
>
> russ, how do you want to handle?
This is really about lin
> On Apr 12, 2021, at 7:33 PM, Randy Bush wrote:
>
3. The definition of canonicalization refers to section 2.2 of RFC
5485 (which talks about ASCII) vs RFC8805 which talks about UTF-8. Is
this disparity an issue?
>>>
>>> russ, how do you want to handle?
>>
>> This is really a
Rob:
>>
>> Unless is modified to formally define
> [RW]
>
> My comment was less about what gets written in the documents, and more about
> how this update would actually be done in practice. E.g., updating 8805 to
> indicate a new section would presumably break any existing clients expecting
Kyle:
> > This document appears to propose overlapping mechanisms for
> > establishment of trust in geofeed data. As far as I can tell, geofeed
> > data may be authenticated both by:
> >
> > * RPKI private key signature of a digest of a canonicalized form of the
> > geofeed data file. * Web PKI
> On May 3, 2021, at 10:47 AM, Kyle Rose wrote:
>
> On Mon, May 3, 2021 at 10:40 AM Russ Housley <mailto:hous...@vigilsec.com>> wrote:
>
>> Understood. I'm not suggesting the web PKI be used to authenticate IP
>> address space ownership. I'm s
> On May 3, 2021, at 11:44 AM, Kyle Rose wrote:
>
> On Mon, May 3, 2021, 11:28 AM Russ Housley <mailto:hous...@vigilsec.com>> wrote:
>> This is not quite right. It is true that theWebPKI provide authentication
>> and integrity when https:// is used, but
Roman:
Addressing some of your comments below. I'm leaving others to my co-authors.
> --
> DISCUSS:
> --
>
> The validation process for the signature computed
Thanks Roman. Two follow-up comments in line.
Russ
> On May 19, 2021, at 5:59 PM, Roman Danyliw wrote:
>
> Hi Russ!
>
> Inline ...
>
>> -Original Message-----
>> From: Russ Housley
>> Sent: Wednesday, May 19, 2021 11:27 AM
>> To: Roman Danyli
Ben:
Responding to Part 1 of your DISCUSS and a few of your comments. My co-authors
will address the other parts, including the NITS.
> --
> DISCUSS:
> --
>
>
Roman:
Responding to just one comment.
> ** Appendix A. The end-user certificate has a sbgp-ipAddBlock field which is
> “IPv4: inherit IPv6: inherit”. However, the parent CA is encoding an IPv4
> only
> range so it seems misplaced that there is a IPv6 reference there.
>
> See https://mailarch
I guess the last sentence should go away too. RFC 8805 does not prohibit them,
but I cannot imagine them as helpful.
Russ
> On May 21, 2021, at 3:39 PM, Randy Bush wrote:
>
> so
>
> The canonicalization procedure converts the data from its internal
> character representation to the UTF-8
Ben:
text. Trailing space characters MUST NOT appear on a line of text.
That is, the space or tab characters must not be followed by the
sequence. [...]
Is the restriction on Unicode characters of category "space separator"
("space characters") or the two
> On Dec 2, 2024, at 5:34 PM, Mahesh Jethanandani
> wrote:
>
> Hi Russ,
>
> Thanks for the review.
>
>> On Dec 2, 2024, at 2:08 PM, Russ Housley via Datatracker > <mailto:nore...@ietf.org>> wrote:
>>
>> Reviewer: Russ Housley
>> Rev
ng...@ietf.org
> Subject: Re: [OPSAWG]IPR POLL: Publishing End-Site Prefix Lengths
>
>> "No, I'm not aware of any IPR that applies to this draft”
>
> randy
>
>
> Date: Tue, 07 Jan 2025 12:53:01 -0800
> From: Randy Bush
> To: Massimo Candela , Russ Ho
This approach works for me.
Russ
> On Mar 13, 2025, at 5:33 AM, Douglas Gash (dcmgash)
> wrote:
>
> Just to confirm, there are three authentication methods (Cert, PSK, RPK).
> Cert MUST be implemented, the other two MAY be implemented, as they become
> mature.
>
> We have made two specific
This looks like an improvement to me.
Russ
> On Apr 29, 2025, at 9:48 AM, Douglas Gash (dcmgash) wrote:
>
> Dear OPSAWG et al,
>
> We would like to extend an offline discussion onto the group regarding the
> use of wildcards for identities in server certificates. The document
> currently p
025, at 5:44 AM, mohamed.boucad...@orange.com wrote:
>
> Hi Russ,
>
> Please see inline.
>
> Cheers,
> Med (as doc Shepherd)
>
>> -----Message d'origine-
>> De : Russ Housley via Datatracker
>> Envoyé : dimanche 9 mars 2025 02:17
>> À
gnment) at
> https://datatracker.ietf.org/doc/review-ietf-opsawg-tacacs-tls13-18-secdir-lc-housley-2025-03-08/
>
> Cheers
> Med
>
> De : Russ Housley mailto:hous...@vigilsec.com>>
> Envoyé : jeudi 3 avril 2025 19:28
> À : Joe Clarke (jclarke) mailto:jcla...@cisco.com>>
f?url2=draft-ietf-opsawg-tacacs-tls13-19.
> If you agree with the modified text can you amend your DIR review to Ready?
>
> Thanks.
>
> Joe
>
> From: Russ Housley mailto:hous...@vigilsec.com>>
> Date: Thursday, March 13, 2025 at 23:02
> To: Douglas Gash (dcmgash)
Reviewer: Russ Housley
Review result: Not Ready
I reviewed this document as part of the Security Directorate's ongoing
effort to review all IETF documents being processed by the IESG. These
comments were written primarily for the benefit of the Security Area
Directors. Document au
Reviewer: Russ Housley
Review result: Not Ready
I reviewed this document as part of the Security Directorate's ongoing
effort to review all IETF documents being processed by the IESG. These
comments were written primarily for the benefit of the Security Area
Directors. Document au
Reviewer: Russ Housley
Review result: Almost Ready
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new
Reviewer: Russ Housley
Review result: Almost Ready
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.
For more
Document: draft-ietf-opsawg-tacacs-tls13
Title: Terminal Access Controller Access-Control System Plus (TACACS+) over TLS
1.3
Reviewer: Russ Housley
Review result: Ready
I reviewed this document as part of the Security Directorate's ongoing
effort to review all IETF documents being process
Document: draft-ietf-opsawg-tacacs-tls13
Title: Terminal Access Controller Access-Control System Plus over TLS 1.3
(TACACS+ over TLS)
Reviewer: Russ Housley
Review result: Ready
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents
Reviewer: Russ Housley
Review result: Not Ready
I reviewed this document as part of the Security Directorate's ongoing
effort to review all IETF documents being processed by the IESG. These
comments were written primarily for the benefit of the Security Area
Directors. Document au
38 matches
Mail list logo
