[PATCH] 510 Fixed NumberFormatException in key-request-find.
by Endi Sukma Dewata
Previously if a key archival failed, the REST service would return
an invalid key URL, which would cause an exception when the CLI tried
to parse it. The service has been fixed to return a null URL which
can be detected to avoid parsing invalid value.
Ticket #1043
--
Endi S. Dewata
10 years, 1 month
Design for new top level DN functionality in Dogtag
by Ade Lee
Design at:
http://pki.fedoraproject.org/wiki/Top-Level_Tree
This is a feature to change the tree structure of the Dogtag internal
database so that a new top level baseDN is available. This will
simplify the replication topology by allowing one to replicate all
subsystems in a tomcat instance with a single replication agreement,
instead of needing a separate replication agreement for each subsystem.
This is a feature that I plan to start implementing very shortly for
Dogtag 10.2 -- ie. within the next couple of weeks.
There are implications both for IPA (and how Dogtag is deployed within
IPA) as well as implications for Dogtag.
Please take a look and provide comments.
Thanks,
Ade
10 years, 1 month
[RHEL 6.6] Revised patch for 'pki-core' . . .
by Matthew Harmsen
After a spirited discussion on the IRC channel, I have restored the
archival functionality and re-factored the following bug to account for
items in the discussion.
Please review the attached patch which address the following bug:
* Bugzilla Bug #1061442 - RFE - ipa-server should keep backup of
CS.cfg <https://bugzilla.redhat.com/show_bug.cgi?id=1061442>
Note that this bug is ONLY relevant to the RHEL 6 platform.
The actual bug contains new documentation, a revised sample SRPM which
contains the patch and a spec file, and the comments in the bug have
been updated to provide ADDITIONAL TESTING instructions.
It would be great to have ACKs for this by early Friday, 06/20/2014, so
that I can generate official builds of 'pki-core'.
Thanks,
-- Matt
P. S. - Although the use of check sums was discussed during the IRC
session, I utilized the 'cmp' command to perform byte by byte comparisons
instead since the 'cmp' command will supposedly stop as soon
as any difference is detected (thereby reducing the time needed to read
the entire contents of both files).
10 years, 1 month
Re: [Pki-devel] Dogtag sub-CA design proposal; work-in-progress
by Fraser Tweedale
On Wed, Jun 18, 2014 at 04:32:11PM -0400, Dmitri Pal wrote:
> On 06/18/2014 03:15 PM, Ade Lee wrote:
> >Added my comments to the etherpad.
>
I've fleshed out and formatted the design proposal (though it is
still far from complete) and put it up on the wiki:
http://pki.fedoraproject.org/wiki/Lightweight_sub-CAs
And also the LDAP Profile Storage design proposal, which is in a
similar state of incompleteness. I hope to nail down the LDAP
schema, finalise the design and begin implementing next week:
http://pki.fedoraproject.org/wiki/LDAP_Profile_Storage
On the bright side, I think that there are no dependencies between
these design proposals. In FreeIPA there might or might not be a
conceptual association between the two, but that could exist only on
the FreeIPA side, and shouldn't affect the implementation of these
changes.
On the Solution 1 vs Solution 2 debate, from a cleanliness of
implementation view, I think Solution 1 is better, however the fact
that the creation of a new sub-CA must be effected on all replicas
lends much weight to Solution 2.
Anyhow, have a nice weekend and I look forward to continuing the
design process next week.
Cheers,
Fraser
> I added couple comments but have to go so I will resume on Monday. Sorry.
> >Ade
> >
> >On Tue, 2014-06-17 at 14:19 -0400, Dmitri Pal wrote:
> >>On 06/17/2014 08:11 AM, Ade Lee wrote:
> >>>I can't access this etherpad. It says it needs an account/password.
> >>>How do I get an account?
> >>>
> >>>My guess also will be that others in the dogtag group will have trouble
> >>>getting to this account too. I would suggest putting this on a more
> >>>accessible etherpad - like http://etherpad.corp.redhat.com perhaps or
> >>>even a public etherpad.
> >>I changed access. Ade you should be able to see it now.
> >>I also added my comments.
> >>
> >>Fraser it is OK to create a design page on the IPA or Dogtag wiki and
> >>discuss this on the public list.
> >>
> >>>Ade
> >>>
> >>>On Tue, 2014-06-17 at 17:14 +1000, Fraser Tweedale wrote:
> >>>>Hi Ade,
> >>>>
> >>>>Have been working on the design document and comprehending the
> >>>>subsystem/SigningUnit implementation today. The document so far is
> >>>>at http://idm.etherpad.corp.redhat.com/dogtag-sub-ca-design. Please
> >>>>pass along to / copy in anyone else whose feedback would be valuable
> >>>>at this stage of design.
> >>>>
> >>>>Dmitri, could you please provide input on the whether no-restart of
> >>>>Dogtag is a requirement w.r.t. FreeIPA's use of Dogtag sub-CAs?
> >>>>Insights regarding the impact of replication on the proposed design
> >>>>approach would also be appreciated.
> >>>>
> >>>>Cheers,
> >>>>
> >>>>Fraser
> >>
> >
>
>
> --
> Thank you,
> Dmitri Pal
>
> Sr. Engineering Manager IdM portfolio
> Red Hat, Inc.
>
10 years, 1 month
copying EKU info from certificate request
by Fraser Tweedale
Hi all,
Currently the ExtendedKeyUsageExtDefault unconditionally sets the
EKU info for the certificate according to its configuration. If an
EKU extension is present in a signing request, it gets clobbered.
This is apparently a cause for confusion (see
https://fedorahosted.org/freeipa/ticket/2915), but because the
policy default is always paired with a policy constraint, it is
possible to copy the EKU from the request and allow the constraint
to reject unacceptable values.
Implementing this behaviour seems reasonable to me (and it would
resolve the above ticket) but I only have a newcomer's view of the
profiles system. Perhaps "multitude of profiles" is preferred over
"versatile profiles", or things must remain as they are for other
reasons. I appreciate your input!
(A side note: There are several profiles that use NoConstraint with
ExtendedKeyUsageExtDefault; to preserve existing behaviour, these
would have to be changed to use ExtendedKeyUsageExtConstraint,
configured to match the default).
Cheers,
Fraser
10 years, 1 month
[RHEL 6.6] Patches for 'pki-core' . . .
by Matthew Harmsen
Please review the attached patches which address the following bugs:
* Bugzilla Bug #1061442 - RFE - ipa-server should keep backup of
CS.cfg <https://bugzilla.redhat.com/show_bug.cgi?id=1061442>
* Bugzilla Bug #1055080 - Giant /var/log/pki-ca/debug
<https://bugzilla.redhat.com/show_bug.cgi?id=1055080>
Note that these bugs are ONLY relevant to the RHEL 6 platform.
The actual bugs contain the same sample SRPM which contains both of
these patches and a spec file, and the comments in both bugs provide
TESTING instructions for that particular patch.
It would be great to have ACKs for these by this Friday, 06/20/2014, so
that I can generate official builds of 'pki-core'.
Thanks,
-- Matt
10 years, 1 month
[PATCH] pki-cfu-0017-ticket-941-Part1-TPS-Rewrite-Enrollment-Recovery-Key.patch
by Christina Fu
This patch is the 1st patch to ticket #941 - TPS Rewrite: Enrollment,
Recovery, KeyRecovery, revoke/unrevoke processor
It mainly allows tomcat TPS to
1. take the raw bytes of public key generated on the token,
2. parse it and transform it into a PublicKey structure
3. send request to CA
4. upon success of the issuance from CA, receive and decode into
X509CertImp ready to be processed and injected to the token
5 takes token profile (tokenKey) from CS.cfg for the remote handlers
It currently does not:
* handle ECC
* verify the key proof (challenge)
Please review
thanks,
Christina
10 years, 1 month
[PATCH] 223 Fix identities for agents in new DRM rest services
by Ade Lee
Fix identities for security data storage, retrieval and generation
For the new security data storage and retrieval, and for symmetric
key generation, we need to store the identity of the agent that is
requesting and approving each operation, both in the ldap record
and in the audit logs. (Tickets 806 and 807)
This patch also adds required logic to check that the owner of the
recovery request is the same agent that retrieves the key. It also
adds missing audit log constants for symmmetric key generation so that
they will show up in the audit log.
Please review. Thanks,
Ade
10 years, 1 month
