This patch provides basic support for DRM transport key rotation described in http://pki.fedoraproject.org/wiki/DRM_Transport_Key_Rotation This patch provides implementation for tickets: - 729 - CA to include transport certificate when submitting archival request to DRM - 730 - DRM to detect presence of transport certificate attribute in submitted archival request and validate transport certificate against DRM's transport key list - 731 - DRM to provide handling for alternative transport key based on detected and validated transport certificate arriving as a part of extended archival request _______________________________________________ Pki-devel mailing list Pki-devel(a)redhat.com https://www.redhat.com/mailman/listinfo/pki-devel

Just a few comments/ questions so I can understand the patch better. 1. In CAEnrollProfile, you update the request queue only if the transport cert is invalid. Why do we need to do this? Or why do we not need to do this in all cases here?

2. In EnrollProfile.java, you get the transport cert from ca.connector.KRA.transportCert. Is it possible to have more than one CA connected? Is that parameter always the correct one to use?

3. In EnrollmentService.java, you read the transport cert attribute in the request, and throw an exception of it is not present (basically tcert == null). This will presumably occur if you receive an escrow request from an older CA, right? How are we handling this case?

4. Incidentally, transportCert != null && transportCert.length() > 0 can be replaced with ! StringUtils.isEmpty(transportCert) Same thing in a couple other places.

5. Why do you return true in KRAService.java (serviceRequest) instead of false?

Ade On Wed, 2013-09-25 at 16:59 -0700, Andrew Wnuk wrote: > This patch provides basic support for DRM transport key rotation > described > in http://pki.fedoraproject.org/wiki/DRM_Transport_Key_Rotation > > This patch provides implementation for tickets: > - 729 - CA to include transport certificate when submitting > archival request to DRM > - 730 - DRM to detect presence of transport certificate attribute > in submitted archival > request and validate transport certificate against DRM's > transport key list > - 731 - DRM to provide handling for alternative transport key > based on detected > and validated transport certificate arriving as a part of > extended archival request > > > > _______________________________________________ > Pki-devel mailing list > Pki-devel(a)redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel

First of all, I think it's a nice framework that lays the basis for supporting multiple DRM transport keys. Thanks for taking care of the encrypt/decrypt case as well, which is essential in DRM for supporting HSM's that do not support wrapping/unwrapping. A couple observations/questions: * in base/kra/src/com/netscape/kra/EnrollmentService.java, transportCert is specifically deleted from the requests after extraction. We might want to consider making it optional. I understand that some customer in the past has utilized DRM requests for their own purposes. If space is a concern, one idea is to store the nickname instead. Just something to think about. * Another thing, perhaps as a phase 2, is to think about how to get the exact transport cert that the client is using into the request to the DRM. The primary scenario that we wish to cover, I think, is the case when the transport keys are in transition. The scenario in my mind would be someone getting to the enrollment page (thus a transport key is already in the browser), then taking his/her time to fill out the form, meanwhile, the CA's transport cert changed. However, in this patch, CA is getting the transport cert from it's CS.cfg and stuffing it into the request, which means that in this scenario, CA is stuffing the new transport cert into the request instead of the old one that the client is using. Again, I understand that it is not an easy one to resolve, but it is essential to this feature so we need to solve eventually, perhaps at the next phase. We can discuss more about this.

Christina On 09/25/2013 04:59 PM, Andrew Wnuk wrote: > This patch provides basic support for DRM transport key rotation > described > in http://pki.fedoraproject.org/wiki/DRM_Transport_Key_Rotation > > This patch provides implementation for tickets: > - 729 - CA to include transport certificate when submitting > archival request to DRM > - 730 - DRM to detect presence of transport certificate > attribute in submitted archival > request and validate transport certificate against DRM's > transport key list > - 731 - DRM to provide handling for alternative transport key > based on detected > and validated transport certificate arriving as a part > of extended archival request > > > > > > _______________________________________________ > Pki-devel mailing list > Pki-devel(a)redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel _______________________________________________ Pki-devel mailing list Pki-devel(a)redhat.com https://www.redhat.com/mailman/listinfo/pki-devel

On 09/27/2013 09:55 AM, Christina Fu wrote: > First of all, I think it's a nice framework that lays the basis for > supporting multiple DRM transport keys. Thanks for taking care of > the encrypt/decrypt case as well, which is essential in DRM for > supporting HSM's that do not support wrapping/unwrapping. > > A couple observations/questions: > > * in base/kra/src/com/netscape/kra/EnrollmentService.java, > transportCert is specifically deleted from the requests after extraction. > We might want to consider making it optional. I understand that some > customer in the past has utilized DRM requests for their own > purposes. If space is a concern, one idea is to store the nickname > instead. Just something to think about. > > * Another thing, perhaps as a phase 2, is to think about how to get > the exact transport cert that the client is using into the request to > the DRM. The primary scenario that we wish to cover, I think, is the > case when the transport keys are in transition. The scenario in my > mind would be someone getting to the enrollment page (thus a > transport key is already in the browser), then taking his/her time to > fill out the form, meanwhile, the CA's transport cert changed. > However, in this patch, CA is getting the transport cert from it's > CS.cfg and stuffing it into the request, which means that in this > scenario, CA is stuffing the new transport cert into the request > instead of the old one that the client is using. > Again, I understand that it is not an easy one to resolve, but it is > essential to this feature so we need to solve eventually, perhaps at > the next phase. We can discuss more about this. Ticket #750 has been created - https://fedorahosted.org/pki/ticket/750 > > Christina > > On 09/25/2013 04:59 PM, Andrew Wnuk wrote: >> This patch provides basic support for DRM transport key rotation >> described >> in http://pki.fedoraproject.org/wiki/DRM_Transport_Key_Rotation >> >> This patch provides implementation for tickets: >> - 729 - CA to include transport certificate when submitting >> archival request to DRM >> - 730 - DRM to detect presence of transport certificate >> attribute in submitted archival >> request and validate transport certificate against >> DRM's transport key list >> - 731 - DRM to provide handling for alternative transport key >> based on detected >> and validated transport certificate arriving as a part >> of extended archival request >> >> >> >> >> >> _______________________________________________ >> Pki-devel mailing list >> Pki-devel(a)redhat.com >> https://www.redhat.com/mailman/listinfo/pki-devel > > > > _______________________________________________ > Pki-devel mailing list > Pki-devel(a)redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel _______________________________________________ Pki-devel mailing list Pki-devel(a)redhat.com https://www.redhat.com/mailman/listinfo/pki-devel