| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
| |
This reverts commit 8eed1e60b0921d05872e2f43eee9088cef038d7e, which
broke "trust anchor --remove".
|
| |
|
|
|
|
|
|
|
| |
Previously, all objects read from p11-kit persist files are marked as
modifiable when parsing, regardless of the explicit "modifiable: false"
setting in the file.
Reported by Kai Engert in:
https://bugs.freedesktop.org/show_bug.cgi?id=99797
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The PKCS#11 spec states that the CKA_ID should match the
SubjectKeyIdentifier if such an extension is present.
We delay the filling of CKA_ID until the builder phase of populating
attributes which allows us to have more control over how this works.
Note that we don't make CKA_ID reflect SubjectKeyIdentifier *attached*
extensions. The CKA_ID isn't supposed to change after object creation.
Making it dependent on attached extensions would be making promises
we cannot keep, since attached extensions can be added/removed at any
time.
This also means the CKA_ID of attached extensions and certificates
won't necessarily match up, but that was never promised, and not how
attached extensions should be matched to their certificate anyway.
Based on a patch and research done by David Woodhouse.
https://bugs.freedesktop.org/show_bug.cgi?id=84761
|
| |
|
|
|
|
|
| |
The term 'stapled extensions' is confusing because it overloads
terminology used with OSCP stapling.
Suggested by Daniel Kahn Gillmor.
|
| |
|
|
|
|
|
|
|
| |
CKA_PUBLIC_KEY_INFO is defined in the PKCS#11 2.40 draft, so use that
rather than defining our own.
* Fixed up by Nikos Mavrogiannopoulos <nmav@redhat.com>
https://bugs.freedesktop.org/show_bug.cgi?id=83495
|
|
|
Still use recursive for documentation and translation.
|
