October 2011 - Pki-devel - Dogtag PKI List Archives

[PATCH] 0009-add-tests-to-classpath
by Adam Young 02 Nov '11

02 Nov '11

Requires 0008 in order to not break the build in eclipse.

2 2

[PATCH] 0008-stub-unimplemented-abstract-methods
by Adam Young 02 Nov '11

02 Nov '11

2 2

Request to build the following PKI components on Fedora 15, Fedora 16, and Fedora 17 (Rawhide) . . .
by Matthew Harmsen 31 Oct '11

31 Oct '11

Please build the following components on Fedora 15, Fedora 16, and Fedora 17 (rawhide) in Koji . . . * dogtag-pki-theme-9.0.9-1.fc15.src.rpm (dogtag-pki-theme) * pki-core-9.0.15-1.fc15.src.rpm (pki-core) * pki-console-9.0.5-1.fc15.src.rpm (pki-console) * pki-kra-9.0.8-1.fc15.src.rpm (pki-kra) * pki-ocsp-9.0.7-1.fc15.src.rpm (pki-ocsp) * pki-tks-9.0.7-1.fc15.src.rpm (pki-tks) * pki-ra-9.0.4-1.fc15.src.rpm (pki-ra) * pki-tps-9.0.7-1.fc15.src.rpm (pki-tps) * dogtag-pki-9.0.0-7.fc15.src.rpm (dogtag-pki) All changes have been checked-in, and the official tarballs (for all three platforms) have been published to: * http://pki.fedoraproject.org/pki/sources/dogtag-pki-theme/dogtag-pki-theme-… (dogtag-pki-theme) * http://pki.fedoraproject.org/pki/sources/pki-core/pki-core-9.0.15.tar.gz (pki-core) * http://pki.fedoraproject.org/pki/sources/pki-console/pki-console-9.0.5.tar.… (pki-console) * http://pki.fedoraproject.org/pki/sources/pki-kra/pki-kra-9.0.8.tar.gz (pki-kra) * http://pki.fedoraproject.org/pki/sources/pki-ocsp/pki-ocsp-9.0.7.tar.gz (pki-ocsp) * http://pki.fedoraproject.org/pki/sources/pki-tks/pki-tks-9.0.7.tar.gz (pki-tks) * http://pki.fedoraproject.org/pki/sources/pki-ra/pki-ra-9.0.4.tar.gz (pki-ra) * http://pki.fedoraproject.org/pki/sources/pki-tps/pki-tps-9.0.7.tar.gz (pki-tps) * N/A (dogtag-pki) The official spec files (for all three platforms) are located at: * https://alpha.dsdev.sjc.redhat.com/home/mharmsen/kwright/SPECS/dogtag-pki-t… (dogtag-pki-theme) * https://alpha.dsdev.sjc.redhat.com/home/mharmsen/kwright/SPECS/pki-core.spec (pki-core) * https://alpha.dsdev.sjc.redhat.com/home/mharmsen/kwright/SPECS/pki-console.… (pki-console) * https://alpha.dsdev.sjc.redhat.com/home/mharmsen/kwright/SPECS/pki-kra.spec (pki-kra) * https://alpha.dsdev.sjc.redhat.com/home/mharmsen/kwright/SPECS/pki-ocsp.spec (pki-ocsp) * https://alpha.dsdev.sjc.redhat.com/home/mharmsen/kwright/SPECS/pki-ra.spec (pki-ra) * https://alpha.dsdev.sjc.redhat.com/home/mharmsen/kwright/SPECS/pki-tks.spec (pki-tks) * https://alpha.dsdev.sjc.redhat.com/home/mharmsen/kwright/SPECS/pki-tps.spec (pki-tps) * https://alpha.dsdev.sjc.redhat.com/home/mharmsen/kwright/SPECS/dogtag-pki.s… (dogtag-pki) To build the specified components, please import the following into the buildroot: * Fedora 15 o jss-4.2.6-20.el15 (pki-core, pki-console, pki-kra, pki-ocsp, pki-tks) o osutil-2.0.2-1.el15 (pki-core) o tomcatjss-6.0.2-1.el15 (pki-core) * Fedora 16 o jss-4.2.6-20.el16 (pki-core, pki-console, pki-kra, pki-ocsp, pki-tks) o osutil-2.0.2-1.el16 (pki-core) o tomcatjss-6.0.2-1.el16 (pki-core) * Fedora 17 o jss-4.2.6-20.el17 (pki-core, pki-console, pki-kra, pki-ocsp, pki-tks) o osutil-2.0.2-1.el17 (pki-core) o tomcatjss-6.0.2-1.el17 (pki-core) Thanks, -- Matt

3 3

Request to build the following PKI components on Fedora 15, Fedora 16, and Fedora 17 (Rawhide) . . .
by Matthew Harmsen 31 Oct '11

31 Oct '11

Fixes have been made to allow Dogtag 9.0 to build successfully on Fedora 17! Please build the following components on Fedora 15, Fedora 16, and Fedora 17 (rawhide) in Koji . . . * pki-core-9.0.16-1.fc[15,16,17].src.rpm (pki-core) * pki-kra-9.0.9-1.fc[15,16,17].src.rpm (pki-kra) * pki-ocsp-9.0.8-1.fc[15,16,17].src.rpm (pki-ocsp) * pki-tks-9.0.8-1.fc[15,16,17].src.rpm (pki-tks) * dogtag-pki-9.0.0-8.fc[15,16,17].src.rpm (dogtag-pki) and please build the following components on Fedora 17 (rawhide) in Koji . . . * pki-ra-9.0.4-1.fc17.src.rpm (pki-ra) * pki-tps-9.0.7-1.fc17.src.rpm (pki-tps) All changes have been checked-in, and the official tarballs (for all three platforms) have been published to: * http://pki.fedoraproject.org/pki/sources/pki-core/pki-core-9.0.16.tar.gz (pki-core) * http://pki.fedoraproject.org/pki/sources/pki-kra/pki-kra-9.0.9.tar.gz (pki-kra) * http://pki.fedoraproject.org/pki/sources/pki-ocsp/pki-ocsp-9.0.8.tar.gz (pki-ocsp) * http://pki.fedoraproject.org/pki/sources/pki-tks/pki-tks-9.0.8.tar.gz (pki-tks) * N/A (dogtag-pki) likewise, the official tarballs for the additional Fedora 17 (rawhide) builds are available at: * http://pki.fedoraproject.org/pki/sources/pki-ra/pki-ra-9.0.4.tar.gz (pki-ra) * http://pki.fedoraproject.org/pki/sources/pki-tps/pki-tps-9.0.7.tar.gz (pki-tps) The official spec files (for all three platforms) are located at: * https://alpha.dsdev.sjc.redhat.com/home/mharmsen/kwright/SPECS/FEDORA/pki-c… (pki-core) * https://alpha.dsdev.sjc.redhat.com/home/mharmsen/kwright/SPECS/FEDORA/pki-k… (pki-kra) * https://alpha.dsdev.sjc.redhat.com/home/mharmsen/kwright/SPECS/FEDORA/pki-o… (pki-ocsp) * https://alpha.dsdev.sjc.redhat.com/home/mharmsen/kwright/SPECS/FEDORA/pki-t… (pki-tks) * https://alpha.dsdev.sjc.redhat.com/home/mharmsen/kwright/SPECS/FEDORA/dogta… (dogtag-pki) likewise, the official spec files for the additional Fedora 17 (rawhide) builds are available at: * https://alpha.dsdev.sjc.redhat.com/home/mharmsen/kwright/SPECS/FEDORA-17/pk… (pki-ra) * https://alpha.dsdev.sjc.redhat.com/home/mharmsen/kwright/SPECS/FEDORA-17/pk… (pki-tps) Thanks, -- Matt

3 2

Patch for review - Fix installation errors associated with CA, DRM, OCSP, and TKS . . .
by Matthew Harmsen 29 Oct '11

29 Oct '11

* *Bugzilla Bug #749945* <https://bugzilla.redhat.com/show_bug.cgi?id=749945> - Installation error reported during CA, DRM, OCSP, and TKS package installation . . . Please review the attached patch: * https://bugzilla.redhat.com/attachment.cgi?id=530759&action=diff&context=pa… Thanks, -- Matt

2 1

Patch for review - Fix Java class conflicts when using Java 7 . . .
by Matthew Harmsen 29 Oct '11

29 Oct '11

* *Bugzilla Bug #749927* <https://bugzilla.redhat.com/show_bug.cgi?id=749927> - Java class conflicts using Java 7 in Fedora 17 (rawhide) . . . Please review the attached patch: * https://bugzilla.redhat.com/attachment.cgi?id=530756&action=diff&context=pa… Thanks, -- Matt

2 1

Client Authentication
by Adam Young 28 Oct '11

28 Oct '11

Ade, Your ealier emali discussed the renegotiation challenge based on the Profiles. http://pki.fedoraproject.org/wiki/REST#Profiles For the case where a user points a browser (say and Ajax request) at /pki/profiles lets say that we have two cases: one where the user is authenticated and one where they are not. In both cases, they get back a collection, but in the case of unauthenticated it will have significantly fewer entries. In this case, we would want the Java equivalent of mod_nss: NSS_VerifyCLient: Optional I'm guessing this a tomcatjss setting. In this case, if the user has the certificate, they can present it, but if they don't, the operation will complete. I think this is what we want. We always ask for the certificate, but we say it is OK if you don't have it, you just don't get the data. In the case where the user is asking for an object, say an actual profile, and they don't have sufficient privs, they get back a hard and fast error: probably 403.2 http://en.wikipedia.org/wiki/HTTP_403 For something like CSRs, we probably want to restrict access to agents. In that case, if an unauthenticated user, or one without appropriate privs, attempts to access that URL, they also get a 403.2. I don't know how this works in with the renegotiate, but I am guessing that every time the user without a certificate hits an "Optional" page they will be asked for their cert. This might be chatty. No idea. So in general, we tag the URLS either NSS_VerifyClient: Require if they must be authenticated to use them NSS_VerifyClient: Optional if they see different results based on authentication or not NSS_VerifyClient: None if they can view them unauthenticated and see the same results as everyone else IN the pki/WEB-INF/web.xml, this probably maps to something like this: <security-constraint> <web-resource-collection> <web-resource-name>Protected Resource</web-resource-name> <url-pattern>*/*/profile*</url-pattern> </web-resource-collection> <auth-constraint> <role-name>*anonymous*</role-name> <role-name>*agent*</role-name> </auth-constraint> </security-constraint> I'm guessing that we want to specify a role for anonymous as opposed to no role. <web-app> ... <login-config> <auth-method>CLIENT-CERT</auth-method> <realm-name>Tomcat Manager Application</realm-name> <realm-name>PKICA</realm-name> </login-config> ... </web-app> the PKICA Realm would be defined at the server level, in conf/server.xml. Something like: <Realm className="com.netscape.catalina.realm.LDAPCertRealm" connectionURL="ldaps://localhost:8389" userPattern="uid={0},ou=people,dc=mycompany,dc=com" roleBase="ou=groups,dc=mycompany,dc=com" roleName="cn" roleSearch="(uniqueMember={0})" /> There is a class that almost does what we want. *org.apache.catalina.realm.JNDIRealm*. I suspect we can subclass it. It has two ways of doing the auth : Bind mode and Comparison mode. It might be possible to add a Client Cert mode in a subclass. docs are here: http://tomcat.apache.org/tomcat-6.0-doc/realm-howto.html#JNDIRealm

3 2

Interface doc changed (version 0.4)
by Ade Lee 27 Oct '11

27 Oct '11

Hi all, Based on feedback from Jack on some KRA servlets, I have made a few small modifications to the interface docs and flows. In particular, added a couple flows for key generation and storage on the DRM (server-side key gen), and key recovery when nAgents=1. On the interface docs, made the types of POST-a to /pki/keyrequest more explicit. See: http://pki.fedoraproject.org/wiki/REST http://pki.fedoraproject.org/wiki/REST/flows Ade

1 0

Choosing a REST implementation
by Adam Young 27 Oct '11

27 Oct '11

As we close in on the decision about REST, I'd like to mention one thing that Ade and I have been looking into: which REST implementation to choose. It seems like the world has settled in on JAX-B as the API of choice. This makes things as little easier for us, as it means we can program to a standard API and swap out the libraries. I've done what I call a Spike ( something less than a proof-of-concept, more like poking a hole in the ground to see if something comes out) using the reference implementation: Jersey. With this I can do: curl -H "accept: application/json" -H "Accept: applicaton/json" http://$IPASERVER:8080/PKIREST/pki/certificates/2 And get back: {"algorithmID":"RSA","issuer":"Fedora PKA Server Cert","serialNumber":"2","version":"0"} as well as curl -H "accept: application/xml" -H "Accept: applicaton/json" http://$IPASERVER:8080/PKIREST/pki/certificates Which gets: <?xml version="1.0" encoding="UTF-8" standalone="yes"?><certificates><certificate><algorithmID>RSA</algorithmID><issuer>Fedora PKA Server Cert</issuer><serialNumber>2</serialNumber><version>0</version></certificate><certificate><algorithmID>RSA</algorithmID><issuer>Fedora PKA CA</issuer><serialNumber>1</serialNumber><version>0</version></certificate></certificates> So we have a library and an approach that can handle both XML and JSON without much fuss. Note that this is just a Plain Ole Java Object (POJO) that is a place holder for a real certificate and not anything that ties in with our APIs. As I said, a spike. The other REST implementations I've checked out are RESTlet and RESTeasy. Of them, RESTeasy is closer to home, as it is supported by the JBoss team, and is the JBoss REST Implementation of choice. Both of them are complicated enough that it is not immediately clear how to go about integrating them into a pre-existing Serlvet app. I'm sure it is not much different than the Jersey code base. The questions then are: does the Jersey implementation do everything that we foresee needing and how hard would it be to package. I'll answer the packaging question first, as it is the easier one. In order to productize the Jersey implementation for shipping with PKI I'd have to get the source for Jersey and make an RPM out of it: someone on the JPackage team has done this in the past, and it shouldn't be hard to move it forward to the latest Jersey implementation. The Jersey implementation from the Oracle site provides: asm-3.1.jar jackson-xc-1.8.3.jar jersey-server-1.9.1.jar jackson-core-asl-1.8.3.jar jersey-client-1.9.1.jar jettison-1.1.jar jackson-jaxrs-1.8.3.jar jersey-core-1.9.1.jar jsr311-api-1.1.1.jar jackson-mapper-asl-1.8.3.jar jersey-json-1.9.1.jar Most of these are not in Fedora yet. Only jettison. asm is at an older version(2) but we should be able to get 3 in with a the name asm3, which is what I think is already going to happen for Maven support. I suspect it would not be that hard to package the others and get them into Fedora. The source for all of them is in the Maven Repo: http://download.java.net/maven/2/com/sun/jersey/ and converting Maven POMs to Spec files is straightforward enough that it can be automated. The other REST implementations are in pretty much the same boat. None of the mare packaged for Fedora, and most of them pull in quite a few other packages for Building. Both RESTlet and RESTeasy are fairly heavy weight to build: they both go beyond providing a library that interfaces with the Servlet API to providing full Servers, far more than we would want to support. Lets just say that getting them to build as RPMs is a task that I would not be willing to take on in support of PKI. There are a few others out there, but mostly they seem to be projects that were originally for web services that decided to add support for REST as well. So then the question is: Does Jersey does everything we think we need it to do? The short answer right now is that I don't know, but I suspect so. REST is basically making Heavy use of the HTTP definition, so really, the question is does it let us maximize things like redirects, response codes, renegotiation and authentication. This is the next stage of investigation, and I'll keep you posted.

1 0

POST-a vs. POST-b
by Ade Lee 26 Oct '11

26 Oct '11

I was asked today what the difference in the interface doc was between POST-a and POST-b. Below is an excerpt from Restful Web Services (in the best practices chapter) that explains in more detail. Basically, POST-a is using POST to add a new resource. You must use POST instead of PUT if the server is responsible for the final URI. Example, in creating a new request, the server is responsible for assigning a request_id and hence the link to the uri -- /pki/request/$id This is a good use of POST (as described in section 8.6.2) 8.6.3 describes the overloaded use of POST - which is as the result of a submission of a form. This is what I call POST-b - and what some call POST-p (for POST-processor). We have tried to reduce the number of cases where POST-b is used. Its not bad in and of itself, but it makes the interface less clear and less resource oriented or RESTful. Sometimes we have to use it -- as Jack specified for OCSP for instance. In the case of CRLs, at this point I just do not understand how that interface is supposed to work (and am waiting for Andrew or Christina to tell me). Hope this helps, Ade ********************************************* 8.6.2. New Resources: PUT Versus POST You can expose the creation of new resources through PUT, POST, or both. But a client can only use PUT to create resources when it can calculate the final URI of the new resource. In Amazon’s S3 service, the URI path to a bucket is /{bucket-name}. Since the client chooses the bucket name, a client can create a bucket by constructing the corresponding URI and sending a PUT request to it. On the other hand, the URI to a resource in a typical Rails web service looks like /{database-table-name}/{database-ID}. The name of the database table is known in advance, but the ID of the new resource won’t be known until the corresponding record is saved to the database. To create a resource, the client must POST to a “factory” resource, located at /{database-table-name}. The server chooses a URI for the new resource. 8.6.3. Overloading POST POST isn’t just for creating new resources and appending to representations. You can also use it to turn a resource into a tiny RPC-style message processor. A resource that receives an overloaded POST request can scan the incoming representation for additional method information, and carry out any task whatsoever. This gives the resource a wider vocabulary than one that supports only the uniform interface. This is how most web applications work. XML-RPC and SOAP/WSDL web services also run over overloaded POST. I strongly discourage the use of overloaded POST, because it ruins the uniform interface. If you’re tempted to expose complex objects or processes through overloaded POST, try giving the objects or processes their own URIs, and exposing them as resources. I show several examples of this in Section 8.8” later in this chapter. There are two noncontroversial uses for overloaded POST. The first is to simulate HTTP’s uniform interface for clients like web browsers that don’t support PUT or DELETE. The second is to work around limits on the maximum length of a URI. The HTTP standard specifies no limit on how long a URI can get, but many clients and servers impose their own limits: Apache won’t respond to requests for URIs longer than 8 KB. If a client can’t make a GET request to http://www.example.com/numbers/1111111 because of URI length restrictions (imagine a million more ones there if you like), it can make a POST request to http://www.example.com/numbers?_method=GET and put “1111111” in the entity-body. If you want to do without PUT and DELETE altogether, it’s entirely RESTful to expose safe operations on resources through GET, and all other operations through overloaded POST. Doing this violates my Resource-Oriented Architecture, but it conforms to the less restrictive rules of REST. REST says you should use a uniform interface, but it doesn’t say which one. If the uniform interface really doesn’t work for you, or it’s not worth the effort to make it work, then go ahead and overload POST, but don’t lose the resource-oriented design. Every URI you expose should still be a resource: something a client might want to link to. A lot of web applications create new URIs for operations exposed through overloaded POST. You get URIs like /weblog/myweblog/rebuild-index. It doesn’t make sense to link to that URI. Instead of putting method information in the URI, expose overloaded POST on your existing resources (/weblog/myweblog) and ask for method information in the incoming representation (method=rebuild-index). This way, /weblog/myweblog still acts like a resource, albeit one that doesn’t totally conform to the uniform interface. It responds to GET, PUT, DELETE... and also “rebuild-index” through overloaded POST. It’s still an object in the object-oriented sense. A rule of thumb: if you’re using overloaded POST, and you never expose GET and POST on the same URI, you’re probably not exposing resources at all. You’ve probably got an RPC-style service.

1 0