-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove root ca terminology #66
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could also say "How to bridge trust to a newly trusted CA Certificate in a CA DN change..."
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I would say "newly trusted"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
@@ -4784,13 +4810,12 @@ PreferredSymmAlg present (object identifier one | |||
value | |||
-- the symmetric algorithm that this CA expects to be used | |||
-- 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this name change from RootCAKeyUpdate to TrustedCaKeyUpdate?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 |
Implements #65