Conversation
johngray-dev
left a comment
johngray-dev
left a comment
There was a problem hiding this comment.
Just a few minor comments. Generally it seems to make things clearer I think, but it does differ in language from other RFCs
draft-ietf-lamps-rfc4210bis.md
Outdated
| DN, e.g., indicating a generation identifier like the year of issuance or | ||
| a version number, for instance in an OU element. How to bridge trust to | ||
| the new root CA certificate in a CA DN change or a cross-certificate scenario | ||
| a new CA certificate in a CA DN change or a cross-certificate scenario |
There was a problem hiding this comment.
Could also say "How to bridge trust to a newly trusted CA Certificate in a CA DN change..."
draft-ietf-lamps-rfc4210bis.md
Outdated
| Profile of how a Certificate structure may be "self-signed". These | ||
| structures are used for distribution of CA public keys. This can | ||
| Profile of how a certificate structure may be "self-signed". These | ||
| structures are used for distribution of new trusted CA public keys as self-signed certificate. This can |
There was a problem hiding this comment.
I think I would say "newly trusted"
| -- in later PKI messages (for encryption) | ||
| RootCaKeyUpdate optionally present, with | ||
| relevant value | ||
| RootCaKeyUpdate optionally present, with relevant value |
There was a problem hiding this comment.
Should this name change from RootCAKeyUpdate to TrustedCaKeyUpdate?
There was a problem hiding this comment.
It would be great to also update the types. But this would be a breaking change for RFC 9483 because we introduced the new types already with RFC 9480 and we also registered some OIDs using the old language. Therefore, I think we should keep the syntax and address this with the note.
|
Option 1 was rejected in favor of option 2, #67 was merged |
2 participants
Implements #65