[PATCH] 0048-0049 Lightweight CAs: implement deletion
by Fraser Tweedale
The attached patches fix some incorrect synchronization of the
lightweight CAs index (patch 0048) and implement deletion of
lightweight CAs (patch 0049).
These patches replace earlier patches 0048 and 0049 which I rescind.
There is a commented out throw in
CertificateAuthority.deleteAuthority(); I don't yet understand what
causes this failure case but a) everything seems to work (at least
with the small numbers of lightweight CAs I've tested with) and b)
I'm seeking clarification from NSS experts on the matter, so stay
tuned.
Cheers,
Fraser
9 years
[PATCH ] 041 Python packaging of PKI client library
by Christian Heimes
Hi,
Ade has asked me to modify setup.py so we can upload the client library
parts of Dogtag on the Python package index.
I ran into trouble with setuptools and had to remove setuptools again.
The latest version of setuptools broke the data_files option.
Christian
9 years
[PATCH] 644 Added support for directory-authenticated profiles in CLI.
by Endi Sukma Dewata
The pki client-cert-request CLI has been modified to support
directory-authenticated profiles by sending the username and
password as XML/JSON request attributes. The CertRequetService
will then put the credentials into an AuthCredentials object.
The ProfileSubmitServlet has also been modified to create an
AuthCredentials object from the HTTP request object.
The certificate processor classes have been modified to accept
an AuthCredentials object instead of retrieving it from HTTP
request object.
https://fedorahosted.org/pki/ticket/1463
--
Endi S. Dewata
9 years
[PATCH] Lightweight CAs
by Fraser Tweedale
The latest lightweight CAs (f.k.a. Sub-CAs) patches are attached.
This cut has significant changes and additions including:
- CAs are now stored in a flat structure with references to parents
- CAs are now identified by "AuthorityID" (which for now is a UUID
underneath). Many variables, method names and user-visible
strings were updated accordingly. Out with "caRef" terminology.
- "Sub-CA" terminology is (mostly) out; "Authority" is in. This is
to support lightweight CAs that are not descendents of top-level
CA (which can be implemented later).
- ca-cert-request-submit command and related client / service
classes were updated to add "authority" parameter
- Some more specific use of exception (including some new exception
classes) to indicate / catch particular errors.
- More appropriate HTTP status codes return when client has send
invalid data (400), referenced unknown authority (404) or attempts
to create an authority with Subject DN already uesd by another
authority (409 Conflict)
- LDAP entry now gets added before key generation and signing. If
something goes wrong, the DB entry is removed in the catch block.
There are still notable gaps in functionality that are in progress
or will be implemented soon:
- Audit log events
- Resources to enable/disable/delete authority
- Resources to access cert and pkcs7 chain of authority
- Keygen params
- Param to specify token on which to generate authority key
Thanks,
Fraser
9 years
[pki-devel][PATCH] 0052-KRA-key-archival-recovery-via-cli-should-honor-encry.patch
by John Magne
[PATCH] KRA: key archival/recovery via cli - should honor
encryption/decryption flags.
Ticket # 1597
Currently, KRA allows sites to opt for doing encryption/decryption instead of wrapping/unwrapping for key archival and recovery.
The new cli code was later added without such support. We should honor the same flags when cli is called to do key archival and recovery.
This feature was due to a specific customer request. Here is what is now supported:
1. When the pki cli tool is used to recover a asymmetric private key, support is there to do so with encrypt / decrypt.
2. The passphrase and generic data facility already uses encrypt / decrypt so nothing here was needed. Calling it out since this will possibly be a customer issue.
3. While under the hood, it made sense to add this functionality to the Symmetric key archival and recovery operations.
4. All tests in DRMTest.java worked successfully when the kra was configured to support this feature and configured to not observe this feature.
What is missing:
We have since added a method to do a server side key generation of a asymmetric key pair in the kra and also archive it there at the same time. In order to do encrypt / decrypt in this case we need to extract the key contents out of a key object that is used to generate this key. It proved problematic to extract said key. This should be ok since the customer only needs to recover an asymmetric key in their test cases. We could look into doing this later if a pressing need arises.
9 years
[PATCH] 271 python client code for subcas
by Ade Lee
This may need a couple of tweaks when Fraser's initial commit goes in -
maybe aid -> id in the Java json code, but should be pretty much
correct at this point.
This supersedes a previous patch on this.
Please review,
Ade
9 years
Replace legacy Python base64 invocations
by Christian Heimes
Patch for https://fedorahosted.org/pki/ticket/1102
b64encode() and base64.encodestring() work slightly different.
encodestring() includes an extra newline at the end of the string. It
seems the server treats both representations equally.
I ran the KRA tests according to base/kra/functional/drmtest.readme.txt.
The tests are passing, too.
Christian
9 years, 1 month
