Skip to content

Specifically state how mechanism will address PQ size growth - #141

Merged
davidben merged 2 commits into
ietf-plants-wg:mainfrom
Bren2010:branch3
Sep 3, 2025
Merged

Specifically state how mechanism will address PQ size growth#141
davidben merged 2 commits into
ietf-plants-wg:mainfrom
Bren2010:branch3

Conversation

@Bren2010

Copy link
Copy Markdown
Contributor

No description provided.

Comment thread charter-ietf-plants.md
The Working Group will initially put down roots and define the mechanisms needed to interoperably construct and consume certificates:

1. An externally monitorable transparency log structure, maintained by a CA, containing the key/identifier bindings that the CA has certified.
1. An extensible and externally monitorable transparency log structure, maintained by a CA, containing the key/identifier bindings that the CA has certified.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Conditional on this not causing a lot of list drama, I don't mind this adding this. However, keep in mind that, the work here is already unavoidably extensible to what you're trying to do. If it can bind a TBSCertificate and the TBSCertificate is constructed by the log operator, it can be extended. It's just how X.509 non-critical extensions work.

And, of course, there is an inherent extension point here: the things the RP trusts. You can always make a new CAs that implement different signature algorithms, etc. Indeed that's the very extension point we're looking to use here. The lack of extension point has never been the limiting factor here.

Comment thread charter-ietf-plants.md Outdated
@davidben
davidben merged commit cc53581 into ietf-plants-wg:main Sep 3, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants