6:59 p.m.
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
11:55 a.m.
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
7:15 p.m.
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
11:30 a.m.
ACK with ticket filed or to be filed.
Christina
On 09/27/2013 05:15 PM, Andrew Wnuk wrote:
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
6:03 p.m.
On 09/30/2013 09:30 AM, Christina Fu wrote:
ACK with ticket filed or to be filed.
Christina
On 09/27/2013 05:15 PM, Andrew Wnuk wrote:
> 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.
Ticket #753 has been created -
https://fedorahosted.org/pki/ticket/753
>>
>> * 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
_______________________________________________
Pki-devel mailing list
Pki-devel(a)redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel
12:11 p.m.
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
3:45 p.m.
On 09/27/2013 10:11 AM, Ade Lee wrote:
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?
DRM rejects archival request when invalid
transport keys are used by CA.
CA marks corresponding enrollment request as rejected providing clear
error message at the end of approval process.
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?
Multiple CAs can
archive keys using single DRM, but one CA cannot
archive keys using multiple DRMs.
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?
Transport
certificate verification returns null only for invalid
transport certificate.
DRM will use current transport key In case of CA not providing transport
certificate through the connector.
I just noticed that attached patch is not the final one. I'll resend it
shortly including (4).
4. Incidentally,
transportCert != null && transportCert.length() > 0
can be replaced with ! StringUtils.isEmpty(transportCert)
Same thing in a couple other places.
I did not see any documentation specifying
such requirement.
5. Why do you return true in KRAService.java (serviceRequest) instead of
false?
This way CA has a chance to return nice message reporting use of invalid
transport certificate to agent approving enrollment request.
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
6:28 p.m.
On 09/27/2013 01:45 PM, Andrew Wnuk wrote:
On 09/27/2013 10:11 AM, Ade Lee wrote:
> 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?
DRM rejects archival request when invalid transport keys are used by CA.
CA marks corresponding enrollment request as rejected providing clear
error message at the end of approval process.
>
> 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?
Multiple CAs can archive keys using single DRM, but one CA cannot
archive keys using multiple DRMs.
>
> 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?
Transport certificate verification returns null only for invalid
transport certificate.
DRM will use current transport key In case of CA not providing
transport certificate through the connector.
I just noticed that attached patch is not the final one. I'll resend
it shortly including (4).
> 4. Incidentally,
> transportCert != null && transportCert.length() > 0
> can be replaced with ! StringUtils.isEmpty(transportCert)
> Same thing in a couple other places.
I see 3 occurrences in 2 files. None of
the two file has dependency on
apache packages at this moment.
Use of StringUtils requires dependency on apache package, so I see no
reason to add unnecessary dependency on the foreign package just to save
16 characters
I did not see any documentation specifying such requirement.
>
> 5. Why do you return true in KRAService.java (serviceRequest) instead of
> false?
This way CA has a chance to return nice message reporting use of
invalid transport certificate to agent approving enrollment request.
>
> 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
>
_______________________________________________
Pki-devel mailing list
Pki-devel(a)redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel
8:27 a.m.
On Fri, 2013-09-27 at 16:28 -0700, Andrew Wnuk wrote:
On 09/27/2013 01:45 PM, Andrew Wnuk wrote:
> On 09/27/2013 10:11 AM, Ade Lee wrote:
>> 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?
> DRM rejects archival request when invalid transport keys are used by CA.
> CA marks corresponding enrollment request as rejected providing clear
> error message at the end of approval process.
>>
>> 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?
> Multiple CAs can archive keys using single DRM, but one CA cannot
> archive keys using multiple DRMs.
>>
>> 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?
> Transport certificate verification returns null only for invalid
> transport certificate.
> DRM will use current transport key In case of CA not providing
> transport certificate through the connector.
> I just noticed that attached patch is not the final one. I'll resend
> it shortly including (4).
>> 4. Incidentally,
>> transportCert != null && transportCert.length() > 0
>> can be replaced with ! StringUtils.isEmpty(transportCert)
>> Same thing in a couple other places.
I see 3 occurrences in 2 files. None of the two file has dependency on
apache packages at this moment.
Use of StringUtils requires dependency on apache package, so I see no
reason to add unnecessary dependency on the foreign package just to save
16 characters
This code is in pki-server which already depends on the apache package
in other locations. If you do a search for StringUtils, you will see it
in a number of places in the newer code.
There is value in using some of the newer functions here for type and
null safety.
> I did not see any documentation specifying such requirement.
>>
>> 5. Why do you return true in KRAService.java (serviceRequest) instead of
>> false?
> This way CA has a chance to return nice message reporting use of
> invalid transport certificate to agent approving enrollment request.
>>
>> 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
>>
>
> _______________________________________________
> 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
4100
days inactive
4105
days old
8 comments
3 participants
participants (3)
-
Ade Lee -
Andrew Wnuk -
Christina Fu