Hi Andrew, Thanks a mil for so speedy response and references. Reading the Automated Enrolment guide I had a thought that Cert Based Auth might work for us. Here is a line from the guide - "There are other circumstances when it may be useful to use certificate-based authentication for initially requesting a certificate. For example, tokens may be bulk-loaded with generic certificates which are then used to authenticate the users when they enroll for their user certificates..." Do you know if a single generic (or transport) cert could be used for signing SCEP requests for multiple users? If so, I presume we will need both - a transport private key and transport cert for signing requests? Thanks, Oleg -----Original Message----- From: pki-users-bounces(a)redhat.com [mailto:pki-users-bounces@redhat.com] On Behalf Of Andrew Wnuk Sent: 20 August 2013 18:15 To: pki-users(a)redhat.com Subject: Re: [Pki-users] Using SCEP SCEP is disabled by default in CA, so you need to enable SCEP first: https://access.redhat.com/site/documentation/en-US/Red_Hat_Certificate_Sy... If you want to use SCEP with CA authentication, you need to enable FlatFileAuthentication plug-in: https://access.redhat.com/site/documentation/en-US/Red_Hat_Certificate_Sy... If you want to use SCEP with RA authentication, you need to follow RA's UI to create one time pins for SCEP requests. RA is using SQLite as its repository so no need to create directory entries. I would advise you to use SCEP with CA only as more improvements were provided in this area. Thanks, Andrew On 08/20/2013 07:10 AM, Oleg Antonenko wrote: _______________________________________________ Pki-users mailing list Pki-users(a)redhat.com https://www.redhat.com/mailman/listinfo/pki-users

Hi Andrew, Yes, the story is quite simple. We have to issue certificates to Apple iOS and Android devices via SCEP. For iOS this process - in theory - should be natively supported by iOS, so that would be our first evaluation test. For Android we will have to develop a client application which can talk SCEP. So once we succeed with iOS devices we'd start developing for Android. My confusion is probably coming from not fully understanding the CA workflow for issuing certs via SCEP requests. In the SCEP specification they say that a PKCS#10 request shall be signed by either - - a self-signed cert generated by the requestor itself, or - a cert originally issued by the CA for the requestor - e.g. for reissuance Then the pkcs#10 is wrapped in PKCS#7 envelope signed by the CA public key. So I need to understand how CA would process SCEP requests - - Does it support PKCS#10 req signed by a self-signed cert generated by the requestor? - Does it support PKCS#10 req signed by a cert issued by the CA but not for the requestor exclusively - e.g. a single generic cert issued to e.g. "CN=Device Enrolment, O=Company X" ? - Any alternatives? Thanks a mil, Oleg -----Original Message----- From: Andrew Wnuk [mailto:awnuk@redhat.com] Sent: 20 August 2013 23:38 To: Oleg Antonenko Cc: pki-users(a)redhat.com Subject: Re: [Pki-users] Using SCEP On 08/20/2013 11:00 AM, Oleg Antonenko wrote: Good choice. Transport certificates are used by CA to protect escrowed encryption keys transported to KRA/DRM . I see no relation between transport keys and SCEP. Could you provide more details?

Hi Alexander, Thanks a lot for the info and confirmation, that sounds reassuring :) We're thinking to keep FlatfileAuth as a Plan B option. But at the moment I think the best would be the "Cert Based Auth"... So I'd like to narrow down my questions raised earlier, and would really appreciate your input. This is an extract from the SCEP specification - 2.1.1.3<http://tools.ietf.org/html/draft-nourse-scep-17#section-2.1.1....;. Requester Uses Existing CA-Issued or Self-Signed Certificates In this protocol, the communication between the requester and the certificate authority is secured by using PKCS#7 [RFC2315<http://tools.ietf.org/html/rfc2315>] as the messaging protocol (see Section 4<http://tools.ietf.org/html/draft-nourse-scep-17#section-4>). PKCS#7 RFC2315<http://tools.ietf.org/html/rfc2315>], however, is a data format which assumes the communicating entities already possess the peer's certificates and requires both parties use the issuer names and issuer assigned certificate serial numbers to identify the certificate in order to verify the signature and decrypt the message. * If the requesting system already has a certificate issued by the CA, that certificate SHOULD be presented as credentials for the renewal of that certificate if the CA supports the "Renewal" capability and the CA policy permits the certificate to be renewed. * If the requesting system has no certificate issued by the CA, but has credentials from a different CA, that certificate MAY be presented as credentials instead of a self-signed certificate. Policy settings on the SCEP server will determine if the request can be accepted or not. * If the requester does not have an appropriate existing certificate, then a self signed certificate must be used instead. The self signed certificate MUST use the same subjectName as in the pkcs10 Request. One of those certificates should be used to sign the overall PKCS#7 envelope sent by clients in "PKCSReq" message to the CA. My hunch is that iOS devices use identity certificates issued by Apple for signing SCEP messages (i.e. PKCS#7). Could anyone confirm that the second and third bullet points (i.e. credentials from a different CA & self signed certificate) are supported in Dogtag? If yes, could you also clarify one more thing please? * Does the CA compare the CN in the signing cert with the CN in the PKCS#10 ? With thanks, Oleg From: Alexander Jung [mailto:alexander.w.jung@gmail.com] Sent: 21 August 2013 20:32 To: Oleg Antonenko Cc: Andrew Wnuk; pki-users(a)redhat.com Subject: Re: [Pki-users] Using SCEP Hi, we gathered some experience using scep and dogtag. To be a little more precise we are issuing certs to cisco routers by the thousands (the whole sales force needs these...) The current implementation works, but leaves still some space for improvement :-) Your client initially needs a password that must be known to the ca in the flatfileauth-file used for your scep profile. The CA has a simple (more example) application to request such a password, we tied it to our order system to further authenticate those requests. When your CA certificate (or the certificate you are using for scep) sits in a HSM, you'll need quite an extension for the existing code, as the current code will not be able to decrypt the requests (in this case due to ciscos error - but we have to serve our clients...) The flatfileauth module still has a longstanding bug (from the iplanet days of the dogtag code), that prevents it to work with other tag-names than the default ones, easy to fix, but hair tearing when you debug it. (See https://www.redhat.com/archives/pki-devel/2009-February/msg00000.html for details) The cisco client still complains on some operations not being implemented, but works after those modifications Yours, Alexander

On 08/21/2013 01:41 AM, Oleg Antonenko wrote: I hope that any of the above options would work as long as the request signature can be validated.