Hi Toerless,
Yes, I think your model is correct. Three more comments below, then I will
leave this alone until we revise the draft:
On 13-Aug-19 07:10, Toerless Eckert wrote:
> On Sat, Aug 10, 2019 at 11:23:20AM +1200, Brian E Carpenter wrote:
>> Hi Toerless,
>>
>> If there was only one
Hi Toerless,
Just responding to one of your points, a colleague of mine from Cisco (Nancy
Cam-Winget) and I have created a draft for authentication-only data protection
for TLS 1.3. We've registered the cipher suites and will be going through the
Independent Review for this RFC soon. If you,
On Sat, Aug 10, 2019 at 11:23:20AM +1200, Brian E Carpenter wrote:
> Hi Toerless,
>
> If there was only one operating system in the world, I guess we could
> describe this. The challenge I see is that the way to solve this may
> be drastically different in different o/s environments, depending on
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
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Autonomic Networking Integrated Model and
Approach WG of the IETF.
Title : Bootstrapping Remote Secure Key Infrastructures
(BRSKI)
Authors : Max
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
Jack Visoky wrote:
>> I think so; there are some details of resale that BRSKI would like to
>> make out-of-scope for the first document. Some way, we have to deal
>> with it, and I would actually like feedback from OPC about the
>> parameters of different solutions here.
>
Agreeing to what Michael and you said, but also wanted to point out
that TLS as defined by IETF is on a trajectory which may or may not be desirable
for e.g.: industrial automation (where OPC is used) or other regulated/
critical environments.
For example the total elimination of any
Hi,
In the context of the L2ACP draft (draft-carpenter-anima-l2acp-scenarios):
It seems that MACsec keying and associations are generally pair-wise, but IEEE
Std 802.1AE-2018 says:
"The guarantees provided by MACsec support the following security services for
stations participating in MACsec:
> I think so; there are some details of resale that BRSKI would like to make
> out-of-scope for the first document. Some way, we have to deal with it, and
> I would actually like feedback from OPC about the parameters of different
> solutions here.
So in this case would the MASA need to be
> but there are significant benefits to not maintaining your own protocols, and
> significant benefits to getting the extensive review that TLS gets.
I could not agree more with this statement.
Thanks,
--Jack
-Original Message-
From: Michael Richardson
Sent: Saturday, August 10,
Randy Armstrong (OPC) wrote:
> 1) As it stands today BRSKI is pull model only and the push model is
> out of scope but I don't see why that has to be the case once you allow
> for different protocols between the Device and the Registrar. With our
> proposed OPC mapping we would
13 matches
Mail list logo
