I support adoption
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
I support adoption
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
Hi,
The encoding of the challengePassword in RFC 9148 seems undefined, or?
My understanding is that the ANS.1 type for challengePassword is
DirectoryString, which according to RFC 5280 is
DirectoryString ::= CHOICE {
teletexString TeletexString (SIZE (1..MAX)),
Review of draft-ietf-ace-coap-est-oscore-02
Hi,
Below is my review of draft-ietf-ace-coap-est-oscore-02. This does not seem
ready yet.
* “EST-coaps ([RFC9148])”
This is in parathesis, other references are not.
* OLD “DTLS
I support adoption and will review.
Cheers,
John
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
Hi,
We have submitted draft-ietf-ace-extend-dtls-authorize-07. This version
addresses all comments received from OpsDir and IESG.
- Expanded the terms ACE, CoAP, TLS, DTLS, OSCORE, AS, RS as suggested by
OpsDir and John Scudder.
- Added some info on the ACE framework (RFC9200) including the
John
From: internet-dra...@ietf.org
Date: Wednesday, 25 January 2023 at 12:34
To: Göran Selander , John Mattsson
, Göran Selander ,
John Mattsson , Olaf Bergmann
Subject: New Version Notification for
draft-ietf-ace-extend-dtls-authorize-06.txt
A new version of I-D, draft-ietf-ace-extend-dtls
Hi Paul,
Thanks for you review.
I very much agree with you that this should have been part of the RFC 9202. In
fact, I pointed out the need for TLS compatibility very early in the
standardization process. The situation right now is that this was unfortunately
not done, and that TLS/TCP is
I agree with earlier replies that ACE should meet at IETF 116 . ACE is now
deployed in a number of industries and there is a lot of things to address,
regarding both lacking security as well as functionality. As discussed by
previous comments, meetings during the IETF week attract a lot of
Hi Tirumaleswar,
Thanks for your review and the good comments. See inline. We will update the
document accordingly.
Cheers,
John
From: tirumal reddy
Date: Friday, 13 January 2023 at 07:32
To: sec...@ietf.org , last-c...@ietf.org ,
ace@ietf.org ,
To: Göran Selander , John Mattsson
, Göran Selander ,
John Mattsson , Olaf Bergmann
Subject: New Version Notification for
draft-ietf-ace-extend-dtls-authorize-05.txt
A new version of I-D, draft-ietf-ace-extend-dtls-authorize-05.txt
has been successfully submitted by John Preuß Mattsson and posted
As a author I obviously support adoption.
The whole content of the document is 164 words. If anybody has been looking for
a really short document to review, now’s your chance :)
Cheers,
John
___
Ace mailing list
Ace@ietf.org
support, I don’t think there is any need for a -bis version,
DTLS 1.3 is to my understanding already supported by the current document
thanks to IESG.
John
From: Carsten Bormann
Date: Thursday, 4 November 2021 at 16:14
To: John Mattsson
Cc: ace@ietf.org
Subject: Re: [Ace] Protocol Action
Thanks to the IESG for stepping in and adding DTLS 1.3. Very much appreciated!
I think IESG should send any (D)TLS 1.2 only drafts back to the WGs from now
on. A lot of SDOs and industries are working hard on updating all (D)TLS
applications to work also with 1.3. The last thing the world needs
Hi,
I think it would be good if the draft added a sentence to clarify that the
profile works with all transports that CoAP can be transported over. This is
already the case, but it is not mentioned. The default choice for most
deployments will probably be UDP, but sometimes UDP is blocked, and
Thanks,
I think this is a very useful mechanism and a well written draft. Some quick
comments.
- "ciphersuite"
Note that both TLS and EDHOC spells this with space "cipher suite"
- Section 2. I don't understand what "SM" in Figure 1 is an abbrevation for.
- Section 2. "UDP/TCP/Websockets" Why
-of-possession
context storage
|| |
| OSCORE Request -> | |
| | |
| <--- OSCORE Response - | |
| ... | |
--
Hi Olof,
Your reasoning does seem to be anchored in the draft. See inline.
The current state of the draft is not acceptable.
Grüße,
John Preuß Mattsson
-Original Message-
From: Olaf Bergmann
Date: Wednesday, 9 September 2020 at 10:20
To: John Mattsson
Cc: "ace@ietf.org"
September 2020 at 00:48
To: John Mattsson , "ace@ietf.org"
Subject: RE: Assignment of OSCORE Sender and Recipient IDS - was RE: [Ace]
Review of draft-ietf-ace-oscore-profile
Hey John, comments in line commented with JLS2
-Original Message-----
From: John Mattsson
Sent: Tuesday,
Hi,
Summarizing my thoughts and opinion on this issue. Changing the title to
highlight the issues better.
As currently specified in draft-ietf-ace-oauth-authz-35, the RS will happily
send the AS address to any node that asks. This causes two problems.
- If C acts on the unauthorized
how to negotiate
Sender ID / Recipient ID. If there is ever a bis version, this should definitly
be added.
John
-Original Message-
From: Jim Schaad
Date: Tuesday, 8 September 2020 at 21:14
To: John Mattsson , Göran Selander
, "ace@ietf.org"
Subject: RE: [Ace] Review of draf
, this should definitly
be added.
John
-Original Message-
From: Jim Schaad
Date: Tuesday, 8 September 2020 at 21:14
To: John Mattsson , Göran Selander
, "ace@ietf.org"
Subject: RE: [Ace] Review of draft-ietf-ace-oscore-profile
John,
I am wondering if this is really the document t
Hi Stephanie,
Regarding the section that you quoted: "the client MUST be able to determine
whether an AS has the authority to issue access tokens for a certain RS. This
can for example be done through pre-configured lists, or through an online
lookup mechanism that in turn also must be
of the AS dictating Sender and
Recipient IDs.
I think Jim has a good point in that the solution with symmetric key
authentication comes with a lot of limitations anyway.
/John
-Original Message-
From: Göran Selander
Date: Monday, 7 September 2020 at 17:05
To: John Mattsson , "ace@iet
byte.
/John
-Original Message-
From: Jim Schaad
Date: Monday, 7 September 2020 at 22:14
To: John Mattsson , "ace@ietf.org"
Subject: Assignment of OSCORE Sender and Recipient IDS - was RE: [Ace] Review
of draft-ietf-ace-oscore-profile
-Original Message-
From: Ace
tacks.
Cheers,
John
-Original Message-
From: John Mattsson
Date: Monday, 7 September 2020 at 12:45
To: Seitz Ludwig , "ace@ietf.org"
Subject: Re: AS discovery in draft-ietf-ace-oauth-authz-35
Hi Ludwig,
The problem I have is that the current mechanism is presented as
AS address
X.X BTW the error message could be used for AS discovery but has limited
effeciency and security and is not recommended.
Cheers,
John
-Original Message-
From: Seitz Ludwig
Date: Monday, 7 September 2020 at 08:28
To: John Mattsson , "ace@ietf.org"
Subject: RE: AS dis
Hi,
I just reviewed draft-ietf-ace-oscore-profile. This made me wonder about the AS
discovery mechanism in the ACE framework. Why is this particular discovery
mechanism given so much attention? Of all possible discovery mechanisms, this
seems like one of the worst as:
1. It requires a
Hi,
I have reviewed the latest GitHub version of draft-ietf-ace-oscore-profile
https://ace-wg.github.io/ace-oscore-profile/draft-ietf-ace-oscore-profile.html
In general this draft looks very good. I have one major comments, and several
more minor comments.
Major comment
---
-
y, 9 March 2020 at 18:41
To: Joel Hoglund , Göran Selander
, Martin Furuhed ,
John Mattsson , Shahid Raza ,
Joel Höglund , John Mattsson ,
Göran Selander
Subject: New Version Notification for draft-raza-ace-cbor-certificates-04.txt
A new version of I-D, draft-raza-ace-cbor-certifica
-Original Message-
From: "internet-dra...@ietf.org"
Date: Wednesday, 11 September 2019 at 15:46
To: Göran Selander , Göran Selander
, John Mattsson ,
Francesca Palombini
Subject: New Version Notification for draft-selander-ace-cose-ecdhe-14.txt
A new version of
For those of you that are not following the CFRG list. The CFRG Crypto Review
Panel has recently provided two reviews of draft-selander-ace-cose-ecdhe-12
Russ Housley:
https://mailarchive.ietf.org/arch/msg/cfrg/6WN2C2RYGTIAInE2jIUco6L9pO8
Stanislav V. Smyshlyaev:
Richard Barnes ; wrote:
>This is the part that worries me. It would be helpful to be very crisp
>about what assumptions are being changed here, and why it's OK for them to
>be changed. Especially given that the Bruni et al. paper seems to have
>found flaws.
As explained in Stanislav's CFRG
for doing so is to provide protocols that can be used even in very constrained
systems.
Cheers,
John
-Original Message-
From: Hannes Tschofenig
Date: Wednesday, 21 November 2018 at 16:16
To: John Mattsson , "ace@ietf.org" ,
"l...@ietf.org"
Cc: Benjamin Kaduk ,
Hi Rene,
These are interesting ideas. As you say, EDHOC is currently optimized for a
minimum number of messages and bytes. Spreading out the bytes and computations
could be beneficial in some applications. EDHOC is currently based on SIGMA-I.
The four-message variant would be based on SIGMA-R
--
Differences compared to PSK + ECDHE
None
50 bytes
-Original Message-
From: Jim Schaad
Date: Wednesday, 21 November 2018 at 16:25
To: John Mattsson , "ace@ietf.org" ,
"l...@ietf.org"
Cc: 'Benjamin Kaduk' , "salvador@um.es"
Subject: RE: [Ace]
Hi Salvador, Michael,
Regarding your comments on negotiation and out-of-band. We have gotten similar
comments from Klaus Hartke regarding cipher suites and out-of-band. I added
your comments to the open issue on GitHub
https://github.com/EricssonResearch/EDHOC/issues/57
We agree with you
Hi,
We recently submitted
https://tools.ietf.org/html/draft-raza-ace-cbor-certificates-00, which build on
research done by Research Institutes of Sweden, Royal Institute of Technology
in Stockholm, and Nexus:
https://kth.diva-portal.org/smash/get/diva2:1153958/FULLTEXT01.pdf
, 13:15, "internet-dra...@ietf.org"
wrote:
A new version of I-D, draft-selander-ace-cose-ecdhe-10.txt
has been successfully submitted by John Mattsson and posted to the
IETF repository.
Name: draft-selander-ace-cose-ecdhe
Revision: 10
Title: Ephemeral Diffie-He
I strongly support Carsten’s suggestion to have a coordinated effort to produce
updated profiles for the use of crypto algorithms in IoT. I think the work
should include at least TLS, DTLS, COSE, and X.509 and take into consideration
the hardware acceleration available in (future) devices.
N_U serves as a session identifier. That is the reason it is bounced back in
message_2.
Both N_U and N_V is not needed in message_3. In the updated version on Github
only a single session identifier is used in message_3
Sent from my Cray-1
> On 24 Feb 2017, at 15:07, Göran Selander
41 matches
Mail list logo
