I'm trying to support keygen-provisioned browsers in the RA. I can do almost everything needed, but I can't figure out how to get the subject name into the certificate. I can definitely get the CA to pick up the subject name as a parameter, but either I am not giving it the right name in the parameter blob, or something else is amiss. What the CA does is issue these RA-approved requests with the a subject name the same as the CA's. (Non-keygen requests are processed differently and the subject AVAs should be embedded in the request. It would be nice to be able to have RA agents edit request subject names before submission, tho.) Help me understand what to do here. Thanks, ==mwh Michael Helm ESnet/LBNL
On 06/02/2011 08:04 PM, Mike Helm wrote:
I'm trying to support keygen-provisioned browsers in the RA. I can do almost everything needed, but I can't figure out how to get the subject name into the certificate.
I can definitely get the CA to pick up the subject name as a parameter, but either I am not giving it the right name in the parameter blob, or something else is amiss. What the CA does is issue these RA-approved requests with the a subject name the same as the CA's.
Michael, You may try to change policy form "Subject Name Default" to "User Supplied Subject Name Default" in the profile generating your certificate.
(Non-keygen requests are processed differently and the subject AVAs should be embedded in the request. It would be nice to be able to have RA agents edit request subject names before submission, tho.)
You need to customize RA's UI to add subject name components not provided by current UI. Thank you, Andrew
Help me understand what to do here.
Thanks, ==mwh Michael Helm ESnet/LBNL
_______________________________________________ Pki-users mailing list Pki-users@redhat.com https://www.redhat.com/mailman/listinfo/pki-users
Andrew Wnuk writes:
On 06/02/2011 08:04 PM, Mike Helm wrote:
I'm trying to support keygen-provisioned browsers in the RA. I can do almost everything needed, but I can't figure out how to get the subject name into the certificate.
I can definitely get the CA to pick up the subject name as a parameter, but either I am not giving it the right name in the parameter blob, or something else is amiss. What the CA does is issue these RA-approved requests with the a subject name the same as the CA's.
Michael,
You may try to change policy form "Subject Name Default" to "User Supplied Subject Name Default" in the profile generating your certificate.
Thanks, I will try this.
(Non-keygen requests are processed differently and the subject AVAs should be embedded in the request. It would be nice to be able to have RA agents edit request subject names before submission, tho.)
You need to customize RA's UI to add subject name components not provided by current UI.
That is _exactly_ what I am in the midst of doing. I can do whatever I need to do on the client (RA javascript) side, but I don't know how to get the subject components to the CA itself - I've sent it all kinds of things & successfully gotten it to write the certificate subjectaltname component, but not the subject. Our plan is to let the profile handle all the policy attributes and only bring over the user/ee - specific content. That's our use case. If anyone else is working on this I'd be delighted to work with you. There are a lot of browsers we can support if we can keygen support out to the RA. Thanks, ==mwh
On 06/03/2011 11:14 AM, Mike Helm wrote:
Andrew Wnuk writes:
On 06/02/2011 08:04 PM, Mike Helm wrote:
I'm trying to support keygen-provisioned browsers in the RA. I can do almost everything needed, but I can't figure out how to get the subject name into the certificate.
I can definitely get the CA to pick up the subject name as a parameter, but either I am not giving it the right name in the parameter blob, or something else is amiss. What the CA does is issue these RA-approved requests with the a subject name the same as the CA's. Michael,
You may try to change policy form "Subject Name Default" to "User Supplied Subject Name Default" in the profile generating your certificate. Thanks, I will try this.
(Non-keygen requests are processed differently and the subject AVAs should be embedded in the request. It would be nice to be able to have RA agents edit request subject names before submission, tho.) You need to customize RA's UI to add subject name components not provided by current UI.
That is _exactly_ what I am in the midst of doing. I can do whatever I need to do on the client (RA javascript) side, but I don't know how to get the subject components to the CA itself - I've sent it all kinds of things& successfully gotten it to write the certificate subjectaltname component, but not the subject.
Our plan is to let the profile handle all the policy attributes and only bring over the user/ee - specific content. That's our use case.
If anyone else is working on this I'd be delighted to work with you. There are a lot of browsers we can support if we can keygen support out to the RA.
Thanks, ==mwh Which browser are you trying to support?
Andrew Wnuk writes:
Which browser are you trying to support?
Anything that has a functioning keygen tag - currently, opera, most google chrome / webkit, safari on mac os, & some derivatives. firefox also has keygen but it has a Mozilla crypto. method that the RA supports. Thanks, ==mwh
On 06/03/2011 08:10 PM, Mike Helm wrote:
Andrew Wnuk writes:
Which browser are you trying to support? Anything that has a functioning keygen tag - currently, opera, most google chrome / webkit, safari on mac os,& some derivatives.
firefox also has keygen but it has a Mozilla crypto. method that the RA supports.
Thanks, ==mwh
There are keygen samples in current RA and CA UI but they were only tested with IE. Each platform from your list may have different underlying crypto modules with different methods to interact with hardware tokens and may have different preferred scripting languages to access their crypto modules.If you find a simple way to make keygen work across all of the above platforms, then I'll be happy to review your patch. Thank you, Andrew
Andrew Wnuk writes:
There are keygen samples in current RA and CA UI but they were only tested with IE. Each platform from your list may have different
IE doesn't use keygen, it has CAPI (or whatever it's called now in Windows 7) and makes pkcs#10 requests. I couldn't find any trace of a keygen tag in IE 9 and I am given to understand (from some of the W3c mailing lists) that Microsoft is opposed to it & won't implement it in their HTML5. In any event, they're fine as-is. Opera and Google-style webkit browsers seem to have keygen. I don't know whether it works on all platforms they support yet. Definitely works on Windows. (My guess is it doesn't work on MacOS.) Safari also has keygen, but it doesn't work on windows - the tag exists but it won't do anything. Does work on MacOS. The tag is a browser method (one of my more knowledgeable coworkers calls it this) and so I can't really look inside the tag & see usable methods - just have to try and check results. Firefox has it but it's kind of a magic tag, perhaps it's an interface to crypto.crmf-something. It works on most platforms (not mobile Android - this deployment completely lacks crypto.* as far as I can tell.) By "work" I mean it does only what it says it will do - make a key pair, and understand that it has a private key somewhere & how to retrieve it. I can definitely load a successfully-signed certificate into these browsers. It may be that some options can provide a little more capability, but I can't tell whether they're there & I don't understand them either. I don't see one that will link more attributes to the generated key. The problem now is, I need to persuade the CA to sign the certificate with a usable subject name. This I don't know how to do, & I don't understand the CA's internal software structure (let alone the "request architecture" or flow) well enough yet to figure out whether it can be fixed. I can get it the key; I can get it a subjectaltname; I can deliver the policy attributes thru the profile, but the subject name.... My hope is that the CA is fine as-is and what I need to do is adjust the policy or learn some more about the request API so I can feed it the subject name in a manner it can understand - that would mean a patch to the RA perl libraries. Otherwise, need to modify something in the CA. Thanks, ==mwh Michael Helm ESnet/LBNL
Mike Helm writes:
Andrew Wnuk writes:
There are keygen samples in current RA and CA UI but they were only
We're good. My colleague, who understands the CA & the profile framework, added a subject parameter & extended the profile we were using; I added this parameter to the package I was posting to the CA, so the CA now picks up the right subject name and signs good certificates. I believe the UI on the CA will support keygen platforms, but the RA wasn't doing this. The CA may not support them well or completely but I think it supported the one that is the most important to us (Safari on MacOS). The RA didn't, tho, which was not good. I need to do some housecleaning before I provide a patch. I think the things we did could be generalized but at the moment we are only interested in some very basic certificate attributes & that is probably as much as I will do. I would certainly like to have a review & advice on the best way to do this - more in a few weeks. Thanks, ==mwh Michael Helm ESnet/LBNL
On 06/08/2011 09:33 AM, Mike Helm wrote:
We're good.
My colleague, who understands the CA& the profile framework, added a subject parameter& extended the profile we were using; I added this parameter to the package I was posting to the CA, so the CA now picks up the right subject name and signs good certificates.
I believe the UI on the CA will support keygen platforms, but the RA wasn't doing this. The CA may not support them well or completely but I think it supported the one that is the most important to us (Safari on MacOS).
Will Safari on iPad work similar way?
The RA didn't, tho, which was not good.
I need to do some housecleaning before I provide a patch. I think the things we did could be generalized but at the moment we are only interested in some very basic certificate attributes& that is probably as much as I will do. I would certainly like to have a review& advice on the best way to do this - more in a few weeks.
Thanks, ==mwh Michael Helm ESnet/LBNL
Andrew Wnuk writes:
Will Safari on iPad work similar way?
ipad/iphone seems to lack crypto services - there's nothing presented by <keygen>, & no keys are generated. I don't find any UI for certificate management either but I don't know very much about this platform. We suspect Apple is going to (or maybe does) support certificates by generating keys, signing, & pushing to the device. I'd like to be wrong about all of this - if we had some certificate UI we could start supporting this platform in some capacity, which would be very welcome. Thanks, ==mwh
On 06/08/2011 02:46 PM, Mike Helm wrote:
Andrew Wnuk writes:
Will Safari on iPad work similar way? ipad/iphone seems to lack crypto services - there's nothing presented by<keygen>,& no keys are generated. I don't find any UI for certificate management either but I don't know very much about this platform.
We suspect Apple is going to (or maybe does) support certificates by generating keys, signing,& pushing to the device. I'd like to be wrong about all of this - if we had some certificate UI we could start supporting this platform in some capacity, which would be very welcome. Thanks, ==mwh
I saw some references on the net saying that iPad could use SCEP protocol to deploy certificates. (http://images.apple.com/ipad/business/pdf/iPad_Deployment_Scenarios.pdf) Have you tried this? Thank you, Andrew
Andrew Wnuk writes:
On 06/08/2011 02:46 PM, Mike Helm wrote:
Andrew Wnuk writes:
Will Safari on iPad work similar way? ipad/iphone seems to lack crypto services - there's nothing presented by<keygen>,& no keys are generated. I don't find any UI for certificate management either but I don't know very much about this platform.
We suspect Apple is going to (or maybe does) support certificates by generating keys, signing,& pushing to the device. I'd like to be wrong about all of this - if we had some certificate UI we could start supporting this platform in some capacity, which would be very welcome. Thanks, ==mwh
I saw some references on the net saying that iPad could use SCEP protocol to deploy certificates. (http://images.apple.com/ipad/business/pdf/iPad_Deployment_Scenarios.pdf) Have you tried this?
No we haven't but thanks for that tip - will definitely look into this. My _guess_ at this point is that the platform can't generate the keys, it needs to get them from somewhere else. Having never used SCEP I don't know if the ipad platform can use a bare key pair to craft a signed SCEP request or not. Otherwise, I read the page as discussing various methods the ipad can use to download a certificate from a smarter one - like your Mac laptop. However, the page doesn't seem to distinguish the private key handling from cert handling, so.... Hand-me-down certificates fit our working scenarios today but we'll soon have customers that want to conduct these transactions directly on their mobile platform. I think that'll mean we have to have a key pair generator or some other trusted service. Thanks, ==mwh
On 06/08/2011 07:22 PM, Mike Helm wrote:
Andrew Wnuk writes:
Andrew Wnuk writes:
Will Safari on iPad work similar way? ipad/iphone seems to lack crypto services - there's nothing presented by<keygen>,& no keys are generated. I don't find any UI for certificate management either but I don't know very much about this platform.
We suspect Apple is going to (or maybe does) support certificates by generating keys, signing,& pushing to the device. I'd like to be wrong about all of this - if we had some certificate UI we could start supporting this platform in some capacity, which would be very welcome. Thanks, ==mwh I saw some references on the net saying that iPad could use SCEP
On 06/08/2011 02:46 PM, Mike Helm wrote: protocol to deploy certificates. (http://images.apple.com/ipad/business/pdf/iPad_Deployment_Scenarios.pdf) Have you tried this? No we haven't but thanks for that tip - will definitely look into this.
My _guess_ at this point is that the platform can't generate the keys, it needs to get them from somewhere else. Having never used SCEP I don't know if the ipad platform can use a bare key pair to craft a signed SCEP request or not. Otherwise, I read the page as discussing various methods the ipad can use to download a certificate from a smarter one - like your Mac laptop. However, the page doesn't seem to distinguish the private key handling from cert handling, so....
Hand-me-down certificates fit our working scenarios today but we'll soon have customers that want to conduct these transactions directly on their mobile platform. I think that'll mean we have to have a key pair generator or some other trusted service.
Thanks, ==mwh
_______________________________________________ Pki-users mailing list Pki-users@redhat.com https://www.redhat.com/mailman/listinfo/pki-users I wonder if certmonger would be useful in this case. It can request certificates on behalf other constituents. It definitely works with IPA but it might not work with raw Dogtag. Would you consider evaluating this approach?
-- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/
On 06/08/2011 04:22 PM, Mike Helm wrote:
No we haven't but thanks for that tip - will definitely look into this.
My_guess_ at this point is that the platform can't generate the keys, it needs to get them from somewhere else. Having never used SCEP I don't know if the ipad platform can use a bare key pair to craft a signed SCEP request or not. Otherwise, I read the page as discussing various methods the ipad can use to download a certificate from a smarter one - like your Mac laptop. However, the page doesn't seem to distinguish the private key handling from cert handling, so....
Hand-me-down certificates fit our working scenarios today but we'll soon have customers that want to conduct these transactions directly on their mobile platform. I think that'll mean we have to have a key pair generator or some other trusted service.
Thanks, ==mwh
Here is an interesting quote from above pdf file: /... iPad generates a certificate enrollment request using the SCEP protocol. This SCEP enrollment request talks directly to the enterprise certificate authority and enables iPad to receive the identity certificate from the certificate authority in response. ... / which means that follows SCEP (included in Dogtag) and general PKI rules. Thank you, Andrew
participants (3)
-
Andrew Wnuk -
Dmitri Pal -
Mike Helm