Thanks Hendrik for swiftly checking the new diff and for the further
improvements;
I agree to all of them.
David
On 11.07.25 14:37, Brockhaus, Hendrik (FT RPD CST SEA-DE) wrote:
Alanna
Thank you for providing this update.
I took a close look at the
diffhttps://www.rfc-editor.org/authors/rfc9810-auth48diff.html
I have the following final proposals if my coauthors agree.
The abbreviation pvno is not introduced in Section 2 and I support that. It is
basically not an abbreviation but an ASN.1 filed name. To differentiate between
‘protocol version number’, a concrete pvno value, and the pvno field I propose
the following changes:
Sections 5.2.2, 5.2.8.3, and 5.3.13
OLD
Details on the usage of the pvno are described in
Section 7.
NEW
Details on the usage of the protocol version number
are described in Section 7.
Section 7
OLD
Note: Using cmp2000 as the default pvno is done to avoid extra
message exchanges for version negotiation and to foster compatibility
with cmp2000 implementations.
NEW
Note: Using cmp2000 as the default pvno value is done to avoid extra
message exchanges for version negotiation and to foster compatibility
with cmp2000 implementations.
Section 7.1.1
OLD
If, after sending a message with a pvno higher than cmp1999, a client
receives an ErrorMsgContent with a version of cmp1999, then it MUST
abort the current transaction.
NEW
If, after sending a message with a pvno value higher than cmp1999, a
client receives an ErrorMsgContent with a version of cmp1999, then it
MUST abort the current transaction.
Appendix C.1
OLD
The pvno MUST be set as specified in Section 7).
NEW
The protocol version number MUST be set as specified in Section 7.
You changed from ‘end entity’ to ‘EE’. Below you find some remaining places
where 'end entity' could be replaced.
Section 3.1.3
OLD
| | <--------------------- | End Entity | <-------
NEW
| | <--------------------- | EE | <--------------
Section 4.2.2.2.
OLD
End entity RA/CA
========== =============
NEW
EE RA/CA
========== =============
Appendix C.4
OLD
Step# End entity PKI
NEW
Step# EE PKI
Appendix D.5
OLD
Step# End entity PKI
NEW
Step# EE PKI
Here are some minor fixes I would like to propose.
Section 3.1.3
OLD
various environments (e.g., offline: file-based; online: mail, HTTP
NEW
various environments (e.g., offline: file-based; online: email, HTTP
Section 5.1.3.4, can you indent the four line by two characters.
OLD
Encapsulate(pk) -> (ct, ss)
...
Decapsulate(ct, sk) -> (ss)
...
KDF(ss, len, context)->(ssk)
...
KDF(ss, len, context)->(ssk)
NEW
Encapsulate(pk) -> (ct, ss)
...
Decapsulate(ct, sk) -> (ss)
...
KDF(ss, len, context)->(ssk)
...
KDF(ss, len, context)->(ssk)
Section 5.2.1, I support David’s proposal.
OLD
The CertTemplate structure allows an EE or RA to
specify as many data fields as the structure wishes for the requested
certificate. The structure also allows an EE or RA to include any
other necessary data, such as the publicKey field, when it is
required for the certificate. A CertTemplate structure is identical
to a TBSCertificate structure (see [RFC5280]) but with all fields
optional/situational.
NEW
The CertTemplate structure allows entities requesting a certificate
to specify the data fields that they wish to get included. The
publicKey field is typically required to provide. A CertTemplate
structure is identical to a TBSCertificate structure (see [RFC 5280])
but with all fields optional/situational.
Section 6.6.1
OLD
This is done by generating a symmetric key based on the
authorization code and using the symmetric key for generating
MACs) on all messages exchanged.
NEW
This is done by generating a symmetric key based on the
authorization code and using the symmetric key for generating
MACs on all messages exchanged.
Hendrik
-----Ursprüngliche Nachricht-----
Von: Alanna Paloma<apal...@staff.rfc-editor.org>
Gesendet: Donnerstag, 10. Juli 2025 23:16
An: John Gray<john.g...@entrust.com>
Cc:debcool...@gmail.com; Brockhaus, Hendrik (FT RPD CST SEA-DE)
<hendrik.brockh...@siemens.com>; von Oheimb, David (FT RPD CST SEA-DE)
<david.von.ohe...@siemens.com>; Mike Ounsworth
<mike.ounswo...@entrust.com>;rfc-edi...@rfc-editor.org;lamps-...@ietf.org;
lamps-cha...@ietf.org;hous...@vigilsec.com;auth48archive@rfc-editor.org
Betreff: Re: [EXTERNAL] [AD] Re: AUTH48: RFC-to-be 9810 <draft-ietf-lamps-
rfc4210bis-18> for your review
Hi John,
We have updated the files to include both expansions of “LRA”.
The files have been posted here (please refresh):
https://www.rfc-/
editor.org%2Fauthors%2Frfc9810.txt&data=05%7C02%7Chendrik.brockhaus%40siem
ens.com%7C0dd94ff63e0a47ecdbed08ddbff70c69%7C38ae3bcd95794fd4addab42e14
95d55a%7C1%7C0%7C638877790756055380%7CUnknown%7CTWFpbGZsb3d8eyJF
bXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbC
IsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=S2NpSsG6z0LtBwRwXs%2F
MwU2VXQbzQ%2Fhs438l30O8JI8%3D&reserved=0
https://www.rfc-/
editor.org%2Fauthors%2Frfc9810.pdf&data=05%7C02%7Chendrik.brockhaus%40sie
mens.com%7C0dd94ff63e0a47ecdbed08ddbff70c69%7C38ae3bcd95794fd4addab42e1
495d55a%7C1%7C0%7C638877790756103392%7CUnknown%7CTWFpbGZsb3d8eyJ
FbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpb
CIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=tfXaayc%2BlOp5z%2Bn2AX
LuMcn26li3IZnCDVfX0nK5PWg%3D&reserved=0
https://www.rfc-/
editor.org%2Fauthors%2Frfc9810.html&data=05%7C02%7Chendrik.brockhaus%40sie
mens.com%7C0dd94ff63e0a47ecdbed08ddbff70c69%7C38ae3bcd95794fd4addab42e1
495d55a%7C1%7C0%7C638877790756133357%7CUnknown%7CTWFpbGZsb3d8eyJ
FbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpb
CIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=bRacv5RAs9W9Cazk%2Bu8
hvM4DdsI1ZhL804s4JbpR%2B3g%3D&reserved=0
https://www.rfc-/
editor.org%2Fauthors%2Frfc9810.xml&data=05%7C02%7Chendrik.brockhaus%40sie
mens.com%7C0dd94ff63e0a47ecdbed08ddbff70c69%7C38ae3bcd95794fd4addab42e1
495d55a%7C1%7C0%7C638877790756155919%7CUnknown%7CTWFpbGZsb3d8eyJ
FbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpb
CIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=mDEdK020OnfOChAiqXajV9
oM5pjwdnAPgV88Ux0UahQ%3D&reserved=0
The relevant diff files are posted here:
https://www.rfc-/
editor.org%2Fauthors%2Frfc9810-
diff.html&data=05%7C02%7Chendrik.brockhaus%40siemens.com%7C0dd94ff63e0a4
7ecdbed08ddbff70c69%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638
877790756177065%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsI
lYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C6
0000%7C%7C%7C&sdata=r4zABxR3wg4QUg%2BBw5mc65noqpmVbLigvlLZPszSN9
0%3D&reserved=0 (comprehensive diff)
https://www.rfc-/
editor.org%2Fauthors%2Frfc9810-
auth48diff.html&data=05%7C02%7Chendrik.brockhaus%40siemens.com%7C0dd94ff6
3e0a47ecdbed08ddbff70c69%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7
C638877790756196029%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRyd
WUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D
%7C60000%7C%7C%7C&sdata=bmYOiu0i%2BhqfU9ivPvSKO0ILKaj%2B30%2FYT1
pRsDCWi6k%3D&reserved=0 (all AUTH48 changes)
https://www.rfc-/
editor.org%2Fauthors%2Frfc9810-
auth48rfcdiff.html&data=05%7C02%7Chendrik.brockhaus%40siemens.com%7C0dd94
ff63e0a47ecdbed08ddbff70c69%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0
%7C638877790756214570%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOn
RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D
%3D%7C60000%7C%7C%7C&sdata=xh5weZO%2B0lZ0R6dfJOGdCykUbo4QLX4KM
Wdow4hT5O0%3D&reserved=0 (AUTH48 changes side by side)
Thank you,
RFC Editor/ap
--
auth48archive mailing list -- auth48archive@rfc-editor.org
To unsubscribe send an email to auth48archive-le...@rfc-editor.org
