From rpb5bnc at gmail.com Wed Dec 3 19:16:47 2014 From: rpb5bnc at gmail.com (Peter Beal) Date: Wed, 03 Dec 2014 14:16:47 -0500 Subject: [Pki-users] Best way to bypass challenge password verification Message-ID: <547F619F.9010705@gmail.com> Hello, Our group is developing its own RA to be part of a PKI solution that includes Dogtag. Our solution uses EST (RFC 7030) between the the clients and the RA, with the EST protocol terminating at the RA. The RA then takes the CSRs and sends them on to Dogtag using REST commands. This project has been going very well, however we did just hit one issue that we were hoping others might be able to provide some guidance on. The EST protocol defines a feature called Proof Of Possession (PoP) where the clients insert the TLS unique ID of the TLS session between it and the EST server, in our case our RA. This TLS UID is sent in the challenge password attribute field of the CSR so that it can be signed by the client. The EST server is responsible for verifying this TLS UID, and once this verification is performed the value in the challenge password field no longer has any meaning. Because the CSR cannot be resigned at this point, the challenge password cannot be taken out of the CSR. This CSR is passed as is along to Dogtag and we're currently finding that Dogtag is checking the CSR and does not like the challenge password attribute: [03/Dec/2014:13:37:59][http-bio-8444-exec-3]: Start parsePKCS10(): MIIBdDCB3gIBADAUMRIwEAYDVQQDDAkxMjcuMC4wLjEwgZ8wDQYJKoZIhvcNAQEB BQADgY0AMIGJAoGBAMPNKtwZO82WfR5u/hS+SsVghdS9jD5BQS6Z5ymXrKcr9R4t DtSeEQ+AtCZ5qVNXcangb00vJgVqgS/7NH4MzSqscgNzZdpx9+mPklvOUuqTuYCv MFIlMwP/2DJ6TBrmF86vJ1I0GmZAyTSzHg4V4YWaN7r0V7x0RyvFqoBnZU51AgMB AAGgITAfBgkqhkiG9w0BCQcxEgwQTUR4clVZNmd6TnZqdWRmNzANBgkqhkiG9w0B AQsFAAOBgQAAKLbWGndYFfa+8IhopufYOEKIOAmcT+Nhr27vFt5I4ymoUwSlKX9L K+KpLho5Q2GsRoItNXJ6VxRcGe1CPZBW2ef7yPdZaKhFmnxXsYVQaqPY5BGI8kAY MMMr75WQcpn+XUpu+FNB4F2j8YY314u2rsplCMbOdR4tcrgc8WqucA== [03/Dec/2014:13:37:59][http-bio-8444-exec-3]: EnrollProfile: parsePKCS10: signature verification enabled [03/Dec/2014:13:37:59][http-bio-8444-exec-3]: EnrollProfile: parsePKCS10: use internal token [03/Dec/2014:13:37:59][http-bio-8444-exec-3]: EnrollProfile: parsePKCS10 setting thread token [03/Dec/2014:13:37:59][http-bio-8444-exec-3]: EnrollProfile: parsePKCS10 java.io.IOException: DerValue.getPrintableString, not a string 12 [03/Dec/2014:13:37:59][http-bio-8444-exec-3]: EnrollProfile: parsePKCS10 restoring thread token So we're wondering what the best approach might be to handle this. Is there a way to configure Dogtag so that it will ignore the challenge password? Thanks very much, Pete Beal From ftweedal at redhat.com Thu Dec 4 03:44:12 2014 From: ftweedal at redhat.com (Fraser Tweedale) Date: Thu, 4 Dec 2014 13:44:12 +1000 Subject: [Pki-users] Best way to bypass challenge password verification In-Reply-To: <547F619F.9010705@gmail.com> References: <547F619F.9010705@gmail.com> Message-ID: <20141204034411.GU8412@dhcp-40-8.bne.redhat.com> On Wed, Dec 03, 2014 at 02:16:47PM -0500, Peter Beal wrote: > > Hello, > > Our group is developing its own RA to be part of a PKI solution that > includes Dogtag. Our solution uses EST (RFC 7030) between the the clients > and the RA, with the EST protocol terminating at the RA. The RA then takes > the CSRs and sends them on to Dogtag using REST commands. This project has > been going very well, however we did just hit one issue that we were hoping > others might be able to provide some guidance on. > > The EST protocol defines a feature called Proof Of Possession (PoP) where > the clients insert the TLS unique ID of the TLS session between it and the > EST server, in our case our RA. This TLS UID is sent in the challenge > password attribute field of the CSR so that it can be signed by the client. > The EST server is responsible for verifying this TLS UID, and once this > verification is performed the value in the challenge password field no > longer has any meaning. Because the CSR cannot be resigned at this point, > the challenge password cannot be taken out of the CSR. This CSR is passed > as is along to Dogtag and we're currently finding that Dogtag is checking > the CSR and does not like the challenge password attribute: > > [03/Dec/2014:13:37:59][http-bio-8444-exec-3]: Start parsePKCS10(): > MIIBdDCB3gIBADAUMRIwEAYDVQQDDAkxMjcuMC4wLjEwgZ8wDQYJKoZIhvcNAQEB > BQADgY0AMIGJAoGBAMPNKtwZO82WfR5u/hS+SsVghdS9jD5BQS6Z5ymXrKcr9R4t > DtSeEQ+AtCZ5qVNXcangb00vJgVqgS/7NH4MzSqscgNzZdpx9+mPklvOUuqTuYCv > MFIlMwP/2DJ6TBrmF86vJ1I0GmZAyTSzHg4V4YWaN7r0V7x0RyvFqoBnZU51AgMB > AAGgITAfBgkqhkiG9w0BCQcxEgwQTUR4clVZNmd6TnZqdWRmNzANBgkqhkiG9w0B > AQsFAAOBgQAAKLbWGndYFfa+8IhopufYOEKIOAmcT+Nhr27vFt5I4ymoUwSlKX9L > K+KpLho5Q2GsRoItNXJ6VxRcGe1CPZBW2ef7yPdZaKhFmnxXsYVQaqPY5BGI8kAY > MMMr75WQcpn+XUpu+FNB4F2j8YY314u2rsplCMbOdR4tcrgc8WqucA== > > [03/Dec/2014:13:37:59][http-bio-8444-exec-3]: EnrollProfile: parsePKCS10: > signature verification enabled > [03/Dec/2014:13:37:59][http-bio-8444-exec-3]: EnrollProfile: parsePKCS10: > use internal token > [03/Dec/2014:13:37:59][http-bio-8444-exec-3]: EnrollProfile: parsePKCS10 > setting thread token > [03/Dec/2014:13:37:59][http-bio-8444-exec-3]: EnrollProfile: parsePKCS10 > java.io.IOException: DerValue.getPrintableString, not a string 12 > [03/Dec/2014:13:37:59][http-bio-8444-exec-3]: EnrollProfile: parsePKCS10 > restoring thread token > > So we're wondering what the best approach might be to handle this. Is there > a way to configure Dogtag so that it will ignore the challenge password? > > Thanks very much, > Pete Beal > Hi Pete, Dogtag tries to decode the request object as a whole (and is failing; see below). There is no way to bypass this. PKCS #9 (RFC 2985) ?5.4.1 "Challenge password" states that "PKCS #9- attribute processing systems MUST be able to recognize and process all string types in DirectoryString values." Therefore, this is a bug in Dogtag, and I will file a ticket. (Incidentally, OpenSSL also fails to deal with with this part of the request object, but the problem is isolated to the attribute.) The problem should not present when using PrintableString instead of UTF8String. Since according to RFC 7030 (EST) the value of the challengePassword attribute is base64 encoded, it is printable, and furthermore RFC 2985 also states, "ChallengePassword attribute values generated in accordance with this version of this document SHOULD use the PrintableString encoding whenever possible." If you have control over the clients (I understand you may not) then using PrintableString instead of UTF8String is recommended and should get you over the line with Dogtag until the decoding issue is fixed on our end. Cheers, Fraser From ftweedal at redhat.com Thu Dec 4 06:20:31 2014 From: ftweedal at redhat.com (Fraser Tweedale) Date: Thu, 4 Dec 2014 16:20:31 +1000 Subject: [Pki-users] Best way to bypass challenge password verification In-Reply-To: <20141204034411.GU8412@dhcp-40-8.bne.redhat.com> References: <547F619F.9010705@gmail.com> <20141204034411.GU8412@dhcp-40-8.bne.redhat.com> Message-ID: <20141204062031.GW8412@dhcp-40-8.bne.redhat.com> On Thu, Dec 04, 2014 at 01:44:12PM +1000, Fraser Tweedale wrote: > On Wed, Dec 03, 2014 at 02:16:47PM -0500, Peter Beal wrote: > > > > Hello, > > > > Our group is developing its own RA to be part of a PKI solution that > > includes Dogtag. Our solution uses EST (RFC 7030) between the the clients > > and the RA, with the EST protocol terminating at the RA. The RA then takes > > the CSRs and sends them on to Dogtag using REST commands. This project has > > been going very well, however we did just hit one issue that we were hoping > > others might be able to provide some guidance on. > > > > The EST protocol defines a feature called Proof Of Possession (PoP) where > > the clients insert the TLS unique ID of the TLS session between it and the > > EST server, in our case our RA. This TLS UID is sent in the challenge > > password attribute field of the CSR so that it can be signed by the client. > > The EST server is responsible for verifying this TLS UID, and once this > > verification is performed the value in the challenge password field no > > longer has any meaning. Because the CSR cannot be resigned at this point, > > the challenge password cannot be taken out of the CSR. This CSR is passed > > as is along to Dogtag and we're currently finding that Dogtag is checking > > the CSR and does not like the challenge password attribute: > > > > [03/Dec/2014:13:37:59][http-bio-8444-exec-3]: Start parsePKCS10(): > > MIIBdDCB3gIBADAUMRIwEAYDVQQDDAkxMjcuMC4wLjEwgZ8wDQYJKoZIhvcNAQEB > > BQADgY0AMIGJAoGBAMPNKtwZO82WfR5u/hS+SsVghdS9jD5BQS6Z5ymXrKcr9R4t > > DtSeEQ+AtCZ5qVNXcangb00vJgVqgS/7NH4MzSqscgNzZdpx9+mPklvOUuqTuYCv > > MFIlMwP/2DJ6TBrmF86vJ1I0GmZAyTSzHg4V4YWaN7r0V7x0RyvFqoBnZU51AgMB > > AAGgITAfBgkqhkiG9w0BCQcxEgwQTUR4clVZNmd6TnZqdWRmNzANBgkqhkiG9w0B > > AQsFAAOBgQAAKLbWGndYFfa+8IhopufYOEKIOAmcT+Nhr27vFt5I4ymoUwSlKX9L > > K+KpLho5Q2GsRoItNXJ6VxRcGe1CPZBW2ef7yPdZaKhFmnxXsYVQaqPY5BGI8kAY > > MMMr75WQcpn+XUpu+FNB4F2j8YY314u2rsplCMbOdR4tcrgc8WqucA== > > > > [03/Dec/2014:13:37:59][http-bio-8444-exec-3]: EnrollProfile: parsePKCS10: > > signature verification enabled > > [03/Dec/2014:13:37:59][http-bio-8444-exec-3]: EnrollProfile: parsePKCS10: > > use internal token > > [03/Dec/2014:13:37:59][http-bio-8444-exec-3]: EnrollProfile: parsePKCS10 > > setting thread token > > [03/Dec/2014:13:37:59][http-bio-8444-exec-3]: EnrollProfile: parsePKCS10 > > java.io.IOException: DerValue.getPrintableString, not a string 12 > > [03/Dec/2014:13:37:59][http-bio-8444-exec-3]: EnrollProfile: parsePKCS10 > > restoring thread token > > > > So we're wondering what the best approach might be to handle this. Is there > > a way to configure Dogtag so that it will ignore the challenge password? > > > > Thanks very much, > > Pete Beal > > > Hi Pete, > > Dogtag tries to decode the request object as a whole (and is > failing; see below). There is no way to bypass this. > > PKCS #9 (RFC 2985) ?5.4.1 "Challenge password" states that "PKCS #9- > attribute processing systems MUST be able to recognize and process > all string types in DirectoryString values." Therefore, this is a > bug in Dogtag, and I will file a ticket. (Incidentally, OpenSSL > also fails to deal with with this part of the request object, but > the problem is isolated to the attribute.) > > The problem should not present when using PrintableString instead of > UTF8String. Since according to RFC 7030 (EST) the value of the > challengePassword attribute is base64 encoded, it is printable, and > furthermore RFC 2985 also states, "ChallengePassword attribute > values generated in accordance with this version of this document > SHOULD use the PrintableString encoding whenever possible." If you > have control over the clients (I understand you may not) then using > PrintableString instead of UTF8String is recommended and should get > you over the line with Dogtag until the decoding issue is fixed on > our end. > > Cheers, > > Fraser New ticket: https://fedorahosted.org/pki/ticket/1221 From rpb5bnc at gmail.com Thu Dec 4 15:36:10 2014 From: rpb5bnc at gmail.com (Peter Beal) Date: Thu, 04 Dec 2014 10:36:10 -0500 Subject: [Pki-users] Best way to bypass challenge password verification In-Reply-To: <20141204034411.GU8412@dhcp-40-8.bne.redhat.com> References: <547F619F.9010705@gmail.com> <20141204034411.GU8412@dhcp-40-8.bne.redhat.com> Message-ID: <54807F6A.5060404@gmail.com> Hi Fraser, Thanks for the quick response. I saw the ticket get opened. Thanks for jumping on that as well. What I see at our EST based client as it is building the CSR is the following value being used for the challenge password (gdb) p tls_uid $35 = 0x7ffff001a4d0 "H9wOU8vX9HX5s/hH" (gdb) We take the TLS UID and run it through a base64 encoding and the above string is what is placed in the challenge password field. This appears to be a printable string for us as it's placed into the CSR. We verify the CSR at the EST server and then send it on to Dogtag unmodified. I haven't go into the RA or Dogtag to verify this, but I suspect this string is still set to this value when it arrives at Dogtag. Thanks again for you help, Pete On 12/3/14 10:44 PM, Fraser Tweedale wrote: > On Wed, Dec 03, 2014 at 02:16:47PM -0500, Peter Beal wrote: >> Hello, >> >> Our group is developing its own RA to be part of a PKI solution that >> includes Dogtag. Our solution uses EST (RFC 7030) between the the clients >> and the RA, with the EST protocol terminating at the RA. The RA then takes >> the CSRs and sends them on to Dogtag using REST commands. This project has >> been going very well, however we did just hit one issue that we were hoping >> others might be able to provide some guidance on. >> >> The EST protocol defines a feature called Proof Of Possession (PoP) where >> the clients insert the TLS unique ID of the TLS session between it and the >> EST server, in our case our RA. This TLS UID is sent in the challenge >> password attribute field of the CSR so that it can be signed by the client. >> The EST server is responsible for verifying this TLS UID, and once this >> verification is performed the value in the challenge password field no >> longer has any meaning. Because the CSR cannot be resigned at this point, >> the challenge password cannot be taken out of the CSR. This CSR is passed >> as is along to Dogtag and we're currently finding that Dogtag is checking >> the CSR and does not like the challenge password attribute: >> >> [03/Dec/2014:13:37:59][http-bio-8444-exec-3]: Start parsePKCS10(): >> MIIBdDCB3gIBADAUMRIwEAYDVQQDDAkxMjcuMC4wLjEwgZ8wDQYJKoZIhvcNAQEB >> BQADgY0AMIGJAoGBAMPNKtwZO82WfR5u/hS+SsVghdS9jD5BQS6Z5ymXrKcr9R4t >> DtSeEQ+AtCZ5qVNXcangb00vJgVqgS/7NH4MzSqscgNzZdpx9+mPklvOUuqTuYCv >> MFIlMwP/2DJ6TBrmF86vJ1I0GmZAyTSzHg4V4YWaN7r0V7x0RyvFqoBnZU51AgMB >> AAGgITAfBgkqhkiG9w0BCQcxEgwQTUR4clVZNmd6TnZqdWRmNzANBgkqhkiG9w0B >> AQsFAAOBgQAAKLbWGndYFfa+8IhopufYOEKIOAmcT+Nhr27vFt5I4ymoUwSlKX9L >> K+KpLho5Q2GsRoItNXJ6VxRcGe1CPZBW2ef7yPdZaKhFmnxXsYVQaqPY5BGI8kAY >> MMMr75WQcpn+XUpu+FNB4F2j8YY314u2rsplCMbOdR4tcrgc8WqucA== >> >> [03/Dec/2014:13:37:59][http-bio-8444-exec-3]: EnrollProfile: parsePKCS10: >> signature verification enabled >> [03/Dec/2014:13:37:59][http-bio-8444-exec-3]: EnrollProfile: parsePKCS10: >> use internal token >> [03/Dec/2014:13:37:59][http-bio-8444-exec-3]: EnrollProfile: parsePKCS10 >> setting thread token >> [03/Dec/2014:13:37:59][http-bio-8444-exec-3]: EnrollProfile: parsePKCS10 >> java.io.IOException: DerValue.getPrintableString, not a string 12 >> [03/Dec/2014:13:37:59][http-bio-8444-exec-3]: EnrollProfile: parsePKCS10 >> restoring thread token >> >> So we're wondering what the best approach might be to handle this. Is there >> a way to configure Dogtag so that it will ignore the challenge password? >> >> Thanks very much, >> Pete Beal >> > Hi Pete, > > Dogtag tries to decode the request object as a whole (and is > failing; see below). There is no way to bypass this. > > PKCS #9 (RFC 2985) ?5.4.1 "Challenge password" states that "PKCS #9- > attribute processing systems MUST be able to recognize and process > all string types in DirectoryString values." Therefore, this is a > bug in Dogtag, and I will file a ticket. (Incidentally, OpenSSL > also fails to deal with with this part of the request object, but > the problem is isolated to the attribute.) > > The problem should not present when using PrintableString instead of > UTF8String. Since according to RFC 7030 (EST) the value of the > challengePassword attribute is base64 encoded, it is printable, and > furthermore RFC 2985 also states, "ChallengePassword attribute > values generated in accordance with this version of this document > SHOULD use the PrintableString encoding whenever possible." If you > have control over the clients (I understand you may not) then using > PrintableString instead of UTF8String is recommended and should get > you over the line with Dogtag until the decoding issue is fixed on > our end. > > Cheers, > > Fraser From ftweedal at redhat.com Fri Dec 5 00:08:39 2014 From: ftweedal at redhat.com (Fraser Tweedale) Date: Fri, 5 Dec 2014 10:08:39 +1000 Subject: [Pki-users] Best way to bypass challenge password verification In-Reply-To: <54807F6A.5060404@gmail.com> References: <547F619F.9010705@gmail.com> <20141204034411.GU8412@dhcp-40-8.bne.redhat.com> <54807F6A.5060404@gmail.com> Message-ID: <20141205000839.GX8412@dhcp-40-8.bne.redhat.com> On Thu, Dec 04, 2014 at 10:36:10AM -0500, Peter Beal wrote: > Hi Fraser, > > Thanks for the quick response. > > I saw the ticket get opened. Thanks for jumping on that as well. > > What I see at our EST based client as it is building the CSR is the > following value being used for the challenge password > > (gdb) p tls_uid > $35 = 0x7ffff001a4d0 "H9wOU8vX9HX5s/hH" > (gdb) > > We take the TLS UID and run it through a base64 encoding and the above > string is what is placed in the challenge password field. This appears to be > a printable string for us as it's placed into the CSR. We verify the CSR at > the EST server and then send it on to Dogtag unmodified. I haven't go into > the RA or Dogtag to verify this, but I suspect this string is still set to > this value when it arrives at Dogtag. > > Thanks again for you help, > Pete > The DER data in the Dogtag log output shows that the challengePassword attribute value has UTF8String encoding (tag 0x0C), not PrintableString (tag 0x13). Dogtag MUST be able to parse UTF8String challengePassword attributes, but according to the RFCs the value SHOULD have PrintableString encoding, so you may want to look into it. I have a patch for the decoding issue in the works; should get it to the pki-devel list for review this morning. What OS and Dogtag version are you running? Hopefully we can get that patch in the next Dogtag release for your distro. Regards, Fraser > On 12/3/14 10:44 PM, Fraser Tweedale wrote: > >On Wed, Dec 03, 2014 at 02:16:47PM -0500, Peter Beal wrote: > >>Hello, > >> > >>Our group is developing its own RA to be part of a PKI solution that > >>includes Dogtag. Our solution uses EST (RFC 7030) between the the clients > >>and the RA, with the EST protocol terminating at the RA. The RA then takes > >>the CSRs and sends them on to Dogtag using REST commands. This project has > >>been going very well, however we did just hit one issue that we were hoping > >>others might be able to provide some guidance on. > >> > >>The EST protocol defines a feature called Proof Of Possession (PoP) where > >>the clients insert the TLS unique ID of the TLS session between it and the > >>EST server, in our case our RA. This TLS UID is sent in the challenge > >>password attribute field of the CSR so that it can be signed by the client. > >>The EST server is responsible for verifying this TLS UID, and once this > >>verification is performed the value in the challenge password field no > >>longer has any meaning. Because the CSR cannot be resigned at this point, > >>the challenge password cannot be taken out of the CSR. This CSR is passed > >>as is along to Dogtag and we're currently finding that Dogtag is checking > >>the CSR and does not like the challenge password attribute: > >> > >>[03/Dec/2014:13:37:59][http-bio-8444-exec-3]: Start parsePKCS10(): > >>MIIBdDCB3gIBADAUMRIwEAYDVQQDDAkxMjcuMC4wLjEwgZ8wDQYJKoZIhvcNAQEB > >>BQADgY0AMIGJAoGBAMPNKtwZO82WfR5u/hS+SsVghdS9jD5BQS6Z5ymXrKcr9R4t > >>DtSeEQ+AtCZ5qVNXcangb00vJgVqgS/7NH4MzSqscgNzZdpx9+mPklvOUuqTuYCv > >>MFIlMwP/2DJ6TBrmF86vJ1I0GmZAyTSzHg4V4YWaN7r0V7x0RyvFqoBnZU51AgMB > >>AAGgITAfBgkqhkiG9w0BCQcxEgwQTUR4clVZNmd6TnZqdWRmNzANBgkqhkiG9w0B > >>AQsFAAOBgQAAKLbWGndYFfa+8IhopufYOEKIOAmcT+Nhr27vFt5I4ymoUwSlKX9L > >>K+KpLho5Q2GsRoItNXJ6VxRcGe1CPZBW2ef7yPdZaKhFmnxXsYVQaqPY5BGI8kAY > >>MMMr75WQcpn+XUpu+FNB4F2j8YY314u2rsplCMbOdR4tcrgc8WqucA== > >> > >>[03/Dec/2014:13:37:59][http-bio-8444-exec-3]: EnrollProfile: parsePKCS10: > >>signature verification enabled > >>[03/Dec/2014:13:37:59][http-bio-8444-exec-3]: EnrollProfile: parsePKCS10: > >>use internal token > >>[03/Dec/2014:13:37:59][http-bio-8444-exec-3]: EnrollProfile: parsePKCS10 > >>setting thread token > >>[03/Dec/2014:13:37:59][http-bio-8444-exec-3]: EnrollProfile: parsePKCS10 > >>java.io.IOException: DerValue.getPrintableString, not a string 12 > >>[03/Dec/2014:13:37:59][http-bio-8444-exec-3]: EnrollProfile: parsePKCS10 > >>restoring thread token > >> > >>So we're wondering what the best approach might be to handle this. Is there > >>a way to configure Dogtag so that it will ignore the challenge password? > >> > >>Thanks very much, > >>Pete Beal > >> > >Hi Pete, > > > >Dogtag tries to decode the request object as a whole (and is > >failing; see below). There is no way to bypass this. > > > >PKCS #9 (RFC 2985) ?5.4.1 "Challenge password" states that "PKCS #9- > >attribute processing systems MUST be able to recognize and process > >all string types in DirectoryString values." Therefore, this is a > >bug in Dogtag, and I will file a ticket. (Incidentally, OpenSSL > >also fails to deal with with this part of the request object, but > >the problem is isolated to the attribute.) > > > >The problem should not present when using PrintableString instead of > >UTF8String. Since according to RFC 7030 (EST) the value of the > >challengePassword attribute is base64 encoded, it is printable, and > >furthermore RFC 2985 also states, "ChallengePassword attribute > >values generated in accordance with this version of this document > >SHOULD use the PrintableString encoding whenever possible." If you > >have control over the clients (I understand you may not) then using > >PrintableString instead of UTF8String is recommended and should get > >you over the line with Dogtag until the decoding issue is fixed on > >our end. > > > >Cheers, > > > >Fraser > From rpb5bnc at gmail.com Fri Dec 5 14:22:34 2014 From: rpb5bnc at gmail.com (Peter Beal) Date: Fri, 05 Dec 2014 09:22:34 -0500 Subject: [Pki-users] Best way to bypass challenge password verification In-Reply-To: <20141205000839.GX8412@dhcp-40-8.bne.redhat.com> References: <547F619F.9010705@gmail.com> <20141204034411.GU8412@dhcp-40-8.bne.redhat.com> <54807F6A.5060404@gmail.com> <20141205000839.GX8412@dhcp-40-8.bne.redhat.com> Message-ID: <5481BFAA.2070708@gmail.com> On 12/4/14 7:08 PM, Fraser Tweedale wrote: > On Thu, Dec 04, 2014 at 10:36:10AM -0500, Peter Beal wrote: >> Hi Fraser, >> >> Thanks for the quick response. >> >> I saw the ticket get opened. Thanks for jumping on that as well. >> >> What I see at our EST based client as it is building the CSR is the >> following value being used for the challenge password >> >> (gdb) p tls_uid >> $35 = 0x7ffff001a4d0 "H9wOU8vX9HX5s/hH" >> (gdb) >> >> We take the TLS UID and run it through a base64 encoding and the above >> string is what is placed in the challenge password field. This appears to be >> a printable string for us as it's placed into the CSR. We verify the CSR at >> the EST server and then send it on to Dogtag unmodified. I haven't go into >> the RA or Dogtag to verify this, but I suspect this string is still set to >> this value when it arrives at Dogtag. >> >> Thanks again for you help, >> Pete >> > The DER data in the Dogtag log output shows that the > challengePassword attribute value has UTF8String encoding (tag > 0x0C), not PrintableString (tag 0x13). Dogtag MUST be able to parse > UTF8String challengePassword attributes, but according to the RFCs > the value SHOULD have PrintableString encoding, so you may want to > look into it. > > I have a patch for the decoding issue in the works; should get it to > the pki-devel list for review this morning. What OS and Dogtag > version are you running? Hopefully we can get that patch in the > next Dogtag release for your distro. > > Regards, > > Fraser Fedora version is 19 and the Dogtag version appears to be Implementation-Version: 10.0.6 Just curious, is there a way to find the version of Dogtag through the web interface? Thanks, Pete >> On 12/3/14 10:44 PM, Fraser Tweedale wrote: >>> On Wed, Dec 03, 2014 at 02:16:47PM -0500, Peter Beal wrote: >>>> Hello, >>>> >>>> Our group is developing its own RA to be part of a PKI solution that >>>> includes Dogtag. Our solution uses EST (RFC 7030) between the the clients >>>> and the RA, with the EST protocol terminating at the RA. The RA then takes >>>> the CSRs and sends them on to Dogtag using REST commands. This project has >>>> been going very well, however we did just hit one issue that we were hoping >>>> others might be able to provide some guidance on. >>>> >>>> The EST protocol defines a feature called Proof Of Possession (PoP) where >>>> the clients insert the TLS unique ID of the TLS session between it and the >>>> EST server, in our case our RA. This TLS UID is sent in the challenge >>>> password attribute field of the CSR so that it can be signed by the client. >>>> The EST server is responsible for verifying this TLS UID, and once this >>>> verification is performed the value in the challenge password field no >>>> longer has any meaning. Because the CSR cannot be resigned at this point, >>>> the challenge password cannot be taken out of the CSR. This CSR is passed >>>> as is along to Dogtag and we're currently finding that Dogtag is checking >>>> the CSR and does not like the challenge password attribute: >>>> >>>> [03/Dec/2014:13:37:59][http-bio-8444-exec-3]: Start parsePKCS10(): >>>> MIIBdDCB3gIBADAUMRIwEAYDVQQDDAkxMjcuMC4wLjEwgZ8wDQYJKoZIhvcNAQEB >>>> BQADgY0AMIGJAoGBAMPNKtwZO82WfR5u/hS+SsVghdS9jD5BQS6Z5ymXrKcr9R4t >>>> DtSeEQ+AtCZ5qVNXcangb00vJgVqgS/7NH4MzSqscgNzZdpx9+mPklvOUuqTuYCv >>>> MFIlMwP/2DJ6TBrmF86vJ1I0GmZAyTSzHg4V4YWaN7r0V7x0RyvFqoBnZU51AgMB >>>> AAGgITAfBgkqhkiG9w0BCQcxEgwQTUR4clVZNmd6TnZqdWRmNzANBgkqhkiG9w0B >>>> AQsFAAOBgQAAKLbWGndYFfa+8IhopufYOEKIOAmcT+Nhr27vFt5I4ymoUwSlKX9L >>>> K+KpLho5Q2GsRoItNXJ6VxRcGe1CPZBW2ef7yPdZaKhFmnxXsYVQaqPY5BGI8kAY >>>> MMMr75WQcpn+XUpu+FNB4F2j8YY314u2rsplCMbOdR4tcrgc8WqucA== >>>> >>>> [03/Dec/2014:13:37:59][http-bio-8444-exec-3]: EnrollProfile: parsePKCS10: >>>> signature verification enabled >>>> [03/Dec/2014:13:37:59][http-bio-8444-exec-3]: EnrollProfile: parsePKCS10: >>>> use internal token >>>> [03/Dec/2014:13:37:59][http-bio-8444-exec-3]: EnrollProfile: parsePKCS10 >>>> setting thread token >>>> [03/Dec/2014:13:37:59][http-bio-8444-exec-3]: EnrollProfile: parsePKCS10 >>>> java.io.IOException: DerValue.getPrintableString, not a string 12 >>>> [03/Dec/2014:13:37:59][http-bio-8444-exec-3]: EnrollProfile: parsePKCS10 >>>> restoring thread token >>>> >>>> So we're wondering what the best approach might be to handle this. Is there >>>> a way to configure Dogtag so that it will ignore the challenge password? >>>> >>>> Thanks very much, >>>> Pete Beal >>>> >>> Hi Pete, >>> >>> Dogtag tries to decode the request object as a whole (and is >>> failing; see below). There is no way to bypass this. >>> >>> PKCS #9 (RFC 2985) ?5.4.1 "Challenge password" states that "PKCS #9- >>> attribute processing systems MUST be able to recognize and process >>> all string types in DirectoryString values." Therefore, this is a >>> bug in Dogtag, and I will file a ticket. (Incidentally, OpenSSL >>> also fails to deal with with this part of the request object, but >>> the problem is isolated to the attribute.) >>> >>> The problem should not present when using PrintableString instead of >>> UTF8String. Since according to RFC 7030 (EST) the value of the >>> challengePassword attribute is base64 encoded, it is printable, and >>> furthermore RFC 2985 also states, "ChallengePassword attribute >>> values generated in accordance with this version of this document >>> SHOULD use the PrintableString encoding whenever possible." If you >>> have control over the clients (I understand you may not) then using >>> PrintableString instead of UTF8String is recommended and should get >>> you over the line with Dogtag until the decoding issue is fixed on >>> our end. >>> >>> Cheers, >>> >>> Fraser From ftweedal at redhat.com Wed Dec 10 04:30:40 2014 From: ftweedal at redhat.com (Fraser Tweedale) Date: Wed, 10 Dec 2014 14:30:40 +1000 Subject: [Pki-users] Best way to bypass challenge password verification In-Reply-To: <5481BFAA.2070708@gmail.com> References: <547F619F.9010705@gmail.com> <20141204034411.GU8412@dhcp-40-8.bne.redhat.com> <54807F6A.5060404@gmail.com> <20141205000839.GX8412@dhcp-40-8.bne.redhat.com> <5481BFAA.2070708@gmail.com> Message-ID: <20141210043040.GF8412@dhcp-40-8.bne.redhat.com> On Fri, Dec 05, 2014 at 09:22:34AM -0500, Peter Beal wrote: > > On 12/4/14 7:08 PM, Fraser Tweedale wrote: > >On Thu, Dec 04, 2014 at 10:36:10AM -0500, Peter Beal wrote: > >>Hi Fraser, > >> > >>Thanks for the quick response. > >> > >>I saw the ticket get opened. Thanks for jumping on that as well. > >> > >>What I see at our EST based client as it is building the CSR is the > >>following value being used for the challenge password > >> > >>(gdb) p tls_uid > >>$35 = 0x7ffff001a4d0 "H9wOU8vX9HX5s/hH" > >>(gdb) > >> > >>We take the TLS UID and run it through a base64 encoding and the above > >>string is what is placed in the challenge password field. This appears to be > >>a printable string for us as it's placed into the CSR. We verify the CSR at > >>the EST server and then send it on to Dogtag unmodified. I haven't go into > >>the RA or Dogtag to verify this, but I suspect this string is still set to > >>this value when it arrives at Dogtag. > >> > >>Thanks again for you help, > >>Pete > >> > >The DER data in the Dogtag log output shows that the > >challengePassword attribute value has UTF8String encoding (tag > >0x0C), not PrintableString (tag 0x13). Dogtag MUST be able to parse > >UTF8String challengePassword attributes, but according to the RFCs > >the value SHOULD have PrintableString encoding, so you may want to > >look into it. > > > >I have a patch for the decoding issue in the works; should get it to > >the pki-devel list for review this morning. What OS and Dogtag > >version are you running? Hopefully we can get that patch in the > >next Dogtag release for your distro. > > > >Regards, > > > >Fraser > Fedora version is 19 and the Dogtag version appears to be > > Implementation-Version: 10.0.6 > I am not sure if the patch will be backported to f19. Stay tuned. > Just curious, is there a way to find the version of Dogtag through the web > interface? > I am not aware of a way. Regards, Fraser > Thanks, > Pete > >>On 12/3/14 10:44 PM, Fraser Tweedale wrote: > >>>On Wed, Dec 03, 2014 at 02:16:47PM -0500, Peter Beal wrote: > >>>>Hello, > >>>> > >>>>Our group is developing its own RA to be part of a PKI solution that > >>>>includes Dogtag. Our solution uses EST (RFC 7030) between the the clients > >>>>and the RA, with the EST protocol terminating at the RA. The RA then takes > >>>>the CSRs and sends them on to Dogtag using REST commands. This project has > >>>>been going very well, however we did just hit one issue that we were hoping > >>>>others might be able to provide some guidance on. > >>>> > >>>>The EST protocol defines a feature called Proof Of Possession (PoP) where > >>>>the clients insert the TLS unique ID of the TLS session between it and the > >>>>EST server, in our case our RA. This TLS UID is sent in the challenge > >>>>password attribute field of the CSR so that it can be signed by the client. > >>>>The EST server is responsible for verifying this TLS UID, and once this > >>>>verification is performed the value in the challenge password field no > >>>>longer has any meaning. Because the CSR cannot be resigned at this point, > >>>>the challenge password cannot be taken out of the CSR. This CSR is passed > >>>>as is along to Dogtag and we're currently finding that Dogtag is checking > >>>>the CSR and does not like the challenge password attribute: > >>>> > >>>>[03/Dec/2014:13:37:59][http-bio-8444-exec-3]: Start parsePKCS10(): > >>>>MIIBdDCB3gIBADAUMRIwEAYDVQQDDAkxMjcuMC4wLjEwgZ8wDQYJKoZIhvcNAQEB > >>>>BQADgY0AMIGJAoGBAMPNKtwZO82WfR5u/hS+SsVghdS9jD5BQS6Z5ymXrKcr9R4t > >>>>DtSeEQ+AtCZ5qVNXcangb00vJgVqgS/7NH4MzSqscgNzZdpx9+mPklvOUuqTuYCv > >>>>MFIlMwP/2DJ6TBrmF86vJ1I0GmZAyTSzHg4V4YWaN7r0V7x0RyvFqoBnZU51AgMB > >>>>AAGgITAfBgkqhkiG9w0BCQcxEgwQTUR4clVZNmd6TnZqdWRmNzANBgkqhkiG9w0B > >>>>AQsFAAOBgQAAKLbWGndYFfa+8IhopufYOEKIOAmcT+Nhr27vFt5I4ymoUwSlKX9L > >>>>K+KpLho5Q2GsRoItNXJ6VxRcGe1CPZBW2ef7yPdZaKhFmnxXsYVQaqPY5BGI8kAY > >>>>MMMr75WQcpn+XUpu+FNB4F2j8YY314u2rsplCMbOdR4tcrgc8WqucA== > >>>> > >>>>[03/Dec/2014:13:37:59][http-bio-8444-exec-3]: EnrollProfile: parsePKCS10: > >>>>signature verification enabled > >>>>[03/Dec/2014:13:37:59][http-bio-8444-exec-3]: EnrollProfile: parsePKCS10: > >>>>use internal token > >>>>[03/Dec/2014:13:37:59][http-bio-8444-exec-3]: EnrollProfile: parsePKCS10 > >>>>setting thread token > >>>>[03/Dec/2014:13:37:59][http-bio-8444-exec-3]: EnrollProfile: parsePKCS10 > >>>>java.io.IOException: DerValue.getPrintableString, not a string 12 > >>>>[03/Dec/2014:13:37:59][http-bio-8444-exec-3]: EnrollProfile: parsePKCS10 > >>>>restoring thread token > >>>> > >>>>So we're wondering what the best approach might be to handle this. Is there > >>>>a way to configure Dogtag so that it will ignore the challenge password? > >>>> > >>>>Thanks very much, > >>>>Pete Beal > >>>> > >>>Hi Pete, > >>> > >>>Dogtag tries to decode the request object as a whole (and is > >>>failing; see below). There is no way to bypass this. > >>> > >>>PKCS #9 (RFC 2985) ?5.4.1 "Challenge password" states that "PKCS #9- > >>>attribute processing systems MUST be able to recognize and process > >>>all string types in DirectoryString values." Therefore, this is a > >>>bug in Dogtag, and I will file a ticket. (Incidentally, OpenSSL > >>>also fails to deal with with this part of the request object, but > >>>the problem is isolated to the attribute.) > >>> > >>>The problem should not present when using PrintableString instead of > >>>UTF8String. Since according to RFC 7030 (EST) the value of the > >>>challengePassword attribute is base64 encoded, it is printable, and > >>>furthermore RFC 2985 also states, "ChallengePassword attribute > >>>values generated in accordance with this version of this document > >>>SHOULD use the PrintableString encoding whenever possible." If you > >>>have control over the clients (I understand you may not) then using > >>>PrintableString instead of UTF8String is recommended and should get > >>>you over the line with Dogtag until the decoding issue is fixed on > >>>our end. > >>> > >>>Cheers, > >>> > >>>Fraser > From ftweedal at redhat.com Thu Dec 11 00:56:14 2014 From: ftweedal at redhat.com (Fraser Tweedale) Date: Thu, 11 Dec 2014 10:56:14 +1000 Subject: [Pki-users] Best way to bypass challenge password verification In-Reply-To: <20141210043040.GF8412@dhcp-40-8.bne.redhat.com> References: <547F619F.9010705@gmail.com> <20141204034411.GU8412@dhcp-40-8.bne.redhat.com> <54807F6A.5060404@gmail.com> <20141205000839.GX8412@dhcp-40-8.bne.redhat.com> <5481BFAA.2070708@gmail.com> <20141210043040.GF8412@dhcp-40-8.bne.redhat.com> Message-ID: <20141211005614.GI8412@dhcp-40-8.bne.redhat.com> On Wed, Dec 10, 2014 at 02:30:40PM +1000, Fraser Tweedale wrote: > On Fri, Dec 05, 2014 at 09:22:34AM -0500, Peter Beal wrote: > > > > On 12/4/14 7:08 PM, Fraser Tweedale wrote: > > >On Thu, Dec 04, 2014 at 10:36:10AM -0500, Peter Beal wrote: > > >>Hi Fraser, > > >> > > >>Thanks for the quick response. > > >> > > >>I saw the ticket get opened. Thanks for jumping on that as well. > > >> > > >>What I see at our EST based client as it is building the CSR is the > > >>following value being used for the challenge password > > >> > > >>(gdb) p tls_uid > > >>$35 = 0x7ffff001a4d0 "H9wOU8vX9HX5s/hH" > > >>(gdb) > > >> > > >>We take the TLS UID and run it through a base64 encoding and the above > > >>string is what is placed in the challenge password field. This appears to be > > >>a printable string for us as it's placed into the CSR. We verify the CSR at > > >>the EST server and then send it on to Dogtag unmodified. I haven't go into > > >>the RA or Dogtag to verify this, but I suspect this string is still set to > > >>this value when it arrives at Dogtag. > > >> > > >>Thanks again for you help, > > >>Pete > > >> > > >The DER data in the Dogtag log output shows that the > > >challengePassword attribute value has UTF8String encoding (tag > > >0x0C), not PrintableString (tag 0x13). Dogtag MUST be able to parse > > >UTF8String challengePassword attributes, but according to the RFCs > > >the value SHOULD have PrintableString encoding, so you may want to > > >look into it. > > > > > >I have a patch for the decoding issue in the works; should get it to > > >the pki-devel list for review this morning. What OS and Dogtag > > >version are you running? Hopefully we can get that patch in the > > >next Dogtag release for your distro. > > > > > >Regards, > > > > > >Fraser > > Fedora version is 19 and the Dogtag version appears to be > > > > Implementation-Version: 10.0.6 > > > I am not sure if the patch will be backported to f19. Stay tuned. > Fedora 21 has just been released, and Fedora 19 will reach End Of Life in a month, and we will not be backporting the patch. We recommend upgrading to Fedora 21 via the fedup tool (https://fedoraproject.org/wiki/FedUp). HTH Fraser > > Just curious, is there a way to find the version of Dogtag through the web > > interface? > > > I am not aware of a way. > > Regards, > > Fraser > > > Thanks, > > Pete > > >>On 12/3/14 10:44 PM, Fraser Tweedale wrote: > > >>>On Wed, Dec 03, 2014 at 02:16:47PM -0500, Peter Beal wrote: > > >>>>Hello, > > >>>> > > >>>>Our group is developing its own RA to be part of a PKI solution that > > >>>>includes Dogtag. Our solution uses EST (RFC 7030) between the the clients > > >>>>and the RA, with the EST protocol terminating at the RA. The RA then takes > > >>>>the CSRs and sends them on to Dogtag using REST commands. This project has > > >>>>been going very well, however we did just hit one issue that we were hoping > > >>>>others might be able to provide some guidance on. > > >>>> > > >>>>The EST protocol defines a feature called Proof Of Possession (PoP) where > > >>>>the clients insert the TLS unique ID of the TLS session between it and the > > >>>>EST server, in our case our RA. This TLS UID is sent in the challenge > > >>>>password attribute field of the CSR so that it can be signed by the client. > > >>>>The EST server is responsible for verifying this TLS UID, and once this > > >>>>verification is performed the value in the challenge password field no > > >>>>longer has any meaning. Because the CSR cannot be resigned at this point, > > >>>>the challenge password cannot be taken out of the CSR. This CSR is passed > > >>>>as is along to Dogtag and we're currently finding that Dogtag is checking > > >>>>the CSR and does not like the challenge password attribute: > > >>>> > > >>>>[03/Dec/2014:13:37:59][http-bio-8444-exec-3]: Start parsePKCS10(): > > >>>>MIIBdDCB3gIBADAUMRIwEAYDVQQDDAkxMjcuMC4wLjEwgZ8wDQYJKoZIhvcNAQEB > > >>>>BQADgY0AMIGJAoGBAMPNKtwZO82WfR5u/hS+SsVghdS9jD5BQS6Z5ymXrKcr9R4t > > >>>>DtSeEQ+AtCZ5qVNXcangb00vJgVqgS/7NH4MzSqscgNzZdpx9+mPklvOUuqTuYCv > > >>>>MFIlMwP/2DJ6TBrmF86vJ1I0GmZAyTSzHg4V4YWaN7r0V7x0RyvFqoBnZU51AgMB > > >>>>AAGgITAfBgkqhkiG9w0BCQcxEgwQTUR4clVZNmd6TnZqdWRmNzANBgkqhkiG9w0B > > >>>>AQsFAAOBgQAAKLbWGndYFfa+8IhopufYOEKIOAmcT+Nhr27vFt5I4ymoUwSlKX9L > > >>>>K+KpLho5Q2GsRoItNXJ6VxRcGe1CPZBW2ef7yPdZaKhFmnxXsYVQaqPY5BGI8kAY > > >>>>MMMr75WQcpn+XUpu+FNB4F2j8YY314u2rsplCMbOdR4tcrgc8WqucA== > > >>>> > > >>>>[03/Dec/2014:13:37:59][http-bio-8444-exec-3]: EnrollProfile: parsePKCS10: > > >>>>signature verification enabled > > >>>>[03/Dec/2014:13:37:59][http-bio-8444-exec-3]: EnrollProfile: parsePKCS10: > > >>>>use internal token > > >>>>[03/Dec/2014:13:37:59][http-bio-8444-exec-3]: EnrollProfile: parsePKCS10 > > >>>>setting thread token > > >>>>[03/Dec/2014:13:37:59][http-bio-8444-exec-3]: EnrollProfile: parsePKCS10 > > >>>>java.io.IOException: DerValue.getPrintableString, not a string 12 > > >>>>[03/Dec/2014:13:37:59][http-bio-8444-exec-3]: EnrollProfile: parsePKCS10 > > >>>>restoring thread token > > >>>> > > >>>>So we're wondering what the best approach might be to handle this. Is there > > >>>>a way to configure Dogtag so that it will ignore the challenge password? > > >>>> > > >>>>Thanks very much, > > >>>>Pete Beal > > >>>> > > >>>Hi Pete, > > >>> > > >>>Dogtag tries to decode the request object as a whole (and is > > >>>failing; see below). There is no way to bypass this. > > >>> > > >>>PKCS #9 (RFC 2985) ?5.4.1 "Challenge password" states that "PKCS #9- > > >>>attribute processing systems MUST be able to recognize and process > > >>>all string types in DirectoryString values." Therefore, this is a > > >>>bug in Dogtag, and I will file a ticket. (Incidentally, OpenSSL > > >>>also fails to deal with with this part of the request object, but > > >>>the problem is isolated to the attribute.) > > >>> > > >>>The problem should not present when using PrintableString instead of > > >>>UTF8String. Since according to RFC 7030 (EST) the value of the > > >>>challengePassword attribute is base64 encoded, it is printable, and > > >>>furthermore RFC 2985 also states, "ChallengePassword attribute > > >>>values generated in accordance with this version of this document > > >>>SHOULD use the PrintableString encoding whenever possible." If you > > >>>have control over the clients (I understand you may not) then using > > >>>PrintableString instead of UTF8String is recommended and should get > > >>>you over the line with Dogtag until the decoding issue is fixed on > > >>>our end. > > >>> > > >>>Cheers, > > >>> > > >>>Fraser > > From rpb5bnc at gmail.com Thu Dec 11 02:30:56 2014 From: rpb5bnc at gmail.com (Peter Beal) Date: Wed, 10 Dec 2014 21:30:56 -0500 Subject: [Pki-users] Best way to bypass challenge password verification In-Reply-To: <20141211005614.GI8412@dhcp-40-8.bne.redhat.com> References: <547F619F.9010705@gmail.com> <20141204034411.GU8412@dhcp-40-8.bne.redhat.com> <54807F6A.5060404@gmail.com> <20141205000839.GX8412@dhcp-40-8.bne.redhat.com> <5481BFAA.2070708@gmail.com> <20141210043040.GF8412@dhcp-40-8.bne.redhat.com> <20141211005614.GI8412@dhcp-40-8.bne.redhat.com> Message-ID: <548901E0.8000302@gmail.com> Ok, thanks for the update. I'll make sure the rest of the team knows this. Pete On 12/10/14 7:56 PM, Fraser Tweedale wrote: > On Wed, Dec 10, 2014 at 02:30:40PM +1000, Fraser Tweedale wrote: >> On Fri, Dec 05, 2014 at 09:22:34AM -0500, Peter Beal wrote: >>> On 12/4/14 7:08 PM, Fraser Tweedale wrote: >>>> On Thu, Dec 04, 2014 at 10:36:10AM -0500, Peter Beal wrote: >>>>> Hi Fraser, >>>>> >>>>> Thanks for the quick response. >>>>> >>>>> I saw the ticket get opened. Thanks for jumping on that as well. >>>>> >>>>> What I see at our EST based client as it is building the CSR is the >>>>> following value being used for the challenge password >>>>> >>>>> (gdb) p tls_uid >>>>> $35 = 0x7ffff001a4d0 "H9wOU8vX9HX5s/hH" >>>>> (gdb) >>>>> >>>>> We take the TLS UID and run it through a base64 encoding and the above >>>>> string is what is placed in the challenge password field. This appears to be >>>>> a printable string for us as it's placed into the CSR. We verify the CSR at >>>>> the EST server and then send it on to Dogtag unmodified. I haven't go into >>>>> the RA or Dogtag to verify this, but I suspect this string is still set to >>>>> this value when it arrives at Dogtag. >>>>> >>>>> Thanks again for you help, >>>>> Pete >>>>> >>>> The DER data in the Dogtag log output shows that the >>>> challengePassword attribute value has UTF8String encoding (tag >>>> 0x0C), not PrintableString (tag 0x13). Dogtag MUST be able to parse >>>> UTF8String challengePassword attributes, but according to the RFCs >>>> the value SHOULD have PrintableString encoding, so you may want to >>>> look into it. >>>> >>>> I have a patch for the decoding issue in the works; should get it to >>>> the pki-devel list for review this morning. What OS and Dogtag >>>> version are you running? Hopefully we can get that patch in the >>>> next Dogtag release for your distro. >>>> >>>> Regards, >>>> >>>> Fraser >>> Fedora version is 19 and the Dogtag version appears to be >>> >>> Implementation-Version: 10.0.6 >>> >> I am not sure if the patch will be backported to f19. Stay tuned. >> > Fedora 21 has just been released, and Fedora 19 will reach End Of > Life in a month, and we will not be backporting the patch. We > recommend upgrading to Fedora 21 via the fedup tool > (https://fedoraproject.org/wiki/FedUp). > > HTH > > Fraser > >>> Just curious, is there a way to find the version of Dogtag through the web >>> interface? >>> >> I am not aware of a way. >> >> Regards, >> >> Fraser >> >>> Thanks, >>> Pete >>>>> On 12/3/14 10:44 PM, Fraser Tweedale wrote: >>>>>> On Wed, Dec 03, 2014 at 02:16:47PM -0500, Peter Beal wrote: >>>>>>> Hello, >>>>>>> >>>>>>> Our group is developing its own RA to be part of a PKI solution that >>>>>>> includes Dogtag. Our solution uses EST (RFC 7030) between the the clients >>>>>>> and the RA, with the EST protocol terminating at the RA. The RA then takes >>>>>>> the CSRs and sends them on to Dogtag using REST commands. This project has >>>>>>> been going very well, however we did just hit one issue that we were hoping >>>>>>> others might be able to provide some guidance on. >>>>>>> >>>>>>> The EST protocol defines a feature called Proof Of Possession (PoP) where >>>>>>> the clients insert the TLS unique ID of the TLS session between it and the >>>>>>> EST server, in our case our RA. This TLS UID is sent in the challenge >>>>>>> password attribute field of the CSR so that it can be signed by the client. >>>>>>> The EST server is responsible for verifying this TLS UID, and once this >>>>>>> verification is performed the value in the challenge password field no >>>>>>> longer has any meaning. Because the CSR cannot be resigned at this point, >>>>>>> the challenge password cannot be taken out of the CSR. This CSR is passed >>>>>>> as is along to Dogtag and we're currently finding that Dogtag is checking >>>>>>> the CSR and does not like the challenge password attribute: >>>>>>> >>>>>>> [03/Dec/2014:13:37:59][http-bio-8444-exec-3]: Start parsePKCS10(): >>>>>>> MIIBdDCB3gIBADAUMRIwEAYDVQQDDAkxMjcuMC4wLjEwgZ8wDQYJKoZIhvcNAQEB >>>>>>> BQADgY0AMIGJAoGBAMPNKtwZO82WfR5u/hS+SsVghdS9jD5BQS6Z5ymXrKcr9R4t >>>>>>> DtSeEQ+AtCZ5qVNXcangb00vJgVqgS/7NH4MzSqscgNzZdpx9+mPklvOUuqTuYCv >>>>>>> MFIlMwP/2DJ6TBrmF86vJ1I0GmZAyTSzHg4V4YWaN7r0V7x0RyvFqoBnZU51AgMB >>>>>>> AAGgITAfBgkqhkiG9w0BCQcxEgwQTUR4clVZNmd6TnZqdWRmNzANBgkqhkiG9w0B >>>>>>> AQsFAAOBgQAAKLbWGndYFfa+8IhopufYOEKIOAmcT+Nhr27vFt5I4ymoUwSlKX9L >>>>>>> K+KpLho5Q2GsRoItNXJ6VxRcGe1CPZBW2ef7yPdZaKhFmnxXsYVQaqPY5BGI8kAY >>>>>>> MMMr75WQcpn+XUpu+FNB4F2j8YY314u2rsplCMbOdR4tcrgc8WqucA== >>>>>>> >>>>>>> [03/Dec/2014:13:37:59][http-bio-8444-exec-3]: EnrollProfile: parsePKCS10: >>>>>>> signature verification enabled >>>>>>> [03/Dec/2014:13:37:59][http-bio-8444-exec-3]: EnrollProfile: parsePKCS10: >>>>>>> use internal token >>>>>>> [03/Dec/2014:13:37:59][http-bio-8444-exec-3]: EnrollProfile: parsePKCS10 >>>>>>> setting thread token >>>>>>> [03/Dec/2014:13:37:59][http-bio-8444-exec-3]: EnrollProfile: parsePKCS10 >>>>>>> java.io.IOException: DerValue.getPrintableString, not a string 12 >>>>>>> [03/Dec/2014:13:37:59][http-bio-8444-exec-3]: EnrollProfile: parsePKCS10 >>>>>>> restoring thread token >>>>>>> >>>>>>> So we're wondering what the best approach might be to handle this. Is there >>>>>>> a way to configure Dogtag so that it will ignore the challenge password? >>>>>>> >>>>>>> Thanks very much, >>>>>>> Pete Beal >>>>>>> >>>>>> Hi Pete, >>>>>> >>>>>> Dogtag tries to decode the request object as a whole (and is >>>>>> failing; see below). There is no way to bypass this. >>>>>> >>>>>> PKCS #9 (RFC 2985) ?5.4.1 "Challenge password" states that "PKCS #9- >>>>>> attribute processing systems MUST be able to recognize and process >>>>>> all string types in DirectoryString values." Therefore, this is a >>>>>> bug in Dogtag, and I will file a ticket. (Incidentally, OpenSSL >>>>>> also fails to deal with with this part of the request object, but >>>>>> the problem is isolated to the attribute.) >>>>>> >>>>>> The problem should not present when using PrintableString instead of >>>>>> UTF8String. Since according to RFC 7030 (EST) the value of the >>>>>> challengePassword attribute is base64 encoded, it is printable, and >>>>>> furthermore RFC 2985 also states, "ChallengePassword attribute >>>>>> values generated in accordance with this version of this document >>>>>> SHOULD use the PrintableString encoding whenever possible." If you >>>>>> have control over the clients (I understand you may not) then using >>>>>> PrintableString instead of UTF8String is recommended and should get >>>>>> you over the line with Dogtag until the decoding issue is fixed on >>>>>> our end. >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Fraser From rperez at pgjtabasco.gob.mx Thu Dec 18 06:56:27 2014 From: rperez at pgjtabasco.gob.mx (Ricardo Alexander Alexander Perez Ricardez) Date: Thu, 18 Dec 2014 00:56:27 -0600 (CST) Subject: [Pki-users] Examples of use PHP or ASP.NET Rest API of Dogtag Certificate System Message-ID: <1188152546.148848.1418885787993.JavaMail.root@pgjtabasco.gob.mx> Hi any examples about use of PHP or ASP.NET with REST API of Dogtag Certificate System? From dgnatowski at yahoo.com Thu Dec 18 18:14:08 2014 From: dgnatowski at yahoo.com (Dennis Gnatowski) Date: Thu, 18 Dec 2014 18:14:08 +0000 (UTC) Subject: [Pki-users] Subordinate CA setup procedures Message-ID: <1123264437.890348.1418926448780.JavaMail.yahoo@jws10684.mail.bf1.yahoo.com> Can someone provide or point me to documentation on setting up a subordinate CA? ?I have a Root CA running DogTag 10.1.1 on Fedora 20 and I just want to create a subordinate CA to this Root CA (also using DogTag). ?----------------------------------------------------------- Dennis Gnatowski dgnatowski at yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ftweedal at redhat.com Fri Dec 19 00:37:41 2014 From: ftweedal at redhat.com (Fraser Tweedale) Date: Fri, 19 Dec 2014 10:37:41 +1000 Subject: [Pki-users] Examples of use PHP or ASP.NET Rest API of Dogtag Certificate System In-Reply-To: <1188152546.148848.1418885787993.JavaMail.root@pgjtabasco.gob.mx> References: <1188152546.148848.1418885787993.JavaMail.root@pgjtabasco.gob.mx> Message-ID: <20141219003741.GK4163@dhcp-40-8.bne.redhat.com> On Thu, Dec 18, 2014 at 12:56:27AM -0600, Ricardo Alexander Alexander Perez Ricardez wrote: > Hi any examples about use of PHP or ASP.NET with REST API of Dogtag Certificate System? > I do not know of any examples in these langauges. However, you should find many general examples online of using REST APIs in those languages, and we can help with any specific questions you have about the Dogtag API. HTH, Fraser > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users From ftweedal at redhat.com Fri Dec 19 05:04:00 2014 From: ftweedal at redhat.com (Fraser Tweedale) Date: Fri, 19 Dec 2014 15:04:00 +1000 Subject: [Pki-users] Subordinate CA setup procedures In-Reply-To: <1123264437.890348.1418926448780.JavaMail.yahoo@jws10684.mail.bf1.yahoo.com> References: <1123264437.890348.1418926448780.JavaMail.yahoo@jws10684.mail.bf1.yahoo.com> Message-ID: <20141219050400.GL4163@dhcp-40-8.bne.redhat.com> On Thu, Dec 18, 2014 at 06:14:08PM +0000, Dennis Gnatowski wrote: > > Can someone provide or point me to documentation on setting up a subordinate CA? ?I have a Root CA running DogTag 10.1.1 on Fedora 20 and I just want to create a subordinate CA to this Root CA (also using DogTag). > ?----------------------------------------------------------- > Dennis Gnatowski > dgnatowski at yahoo.com Hi Dennis, You need to provide a config file to pkispawn(8) to install a subordinate CA. See section "Installing a subordinate CA" in the pkispawn(8) man page for more information. Regards, Fraser From alee at redhat.com Fri Dec 19 18:01:04 2014 From: alee at redhat.com (Ade Lee) Date: Fri, 19 Dec 2014 13:01:04 -0500 Subject: [Pki-users] Subordinate CA setup procedures In-Reply-To: <20141219050400.GL4163@dhcp-40-8.bne.redhat.com> References: <1123264437.890348.1418926448780.JavaMail.yahoo@jws10684.mail.bf1.yahoo.com> <20141219050400.GL4163@dhcp-40-8.bne.redhat.com> Message-ID: <1419012064.5825.4.camel@aleeredhat.laptop> pkispawn -s CA -f subca.cfg Here's a sample config file: [DEFAULT] pki_admin_password=password123 pki_client_database_password=password123 pki_client_pkcs12_password=password123 pki_ds_password=password123 pki_security_domain_password=password123 pki_security_domain_hostname=dogtag.example.com pki_security_domain_https_port=8443 pki_security_domain_user=caadmin pki_ajp_port=8010 pki_tomcat_server_port=8006 pki_https_port=8453 pki_http_port=8090 pki_instance_name=pki-subca [CA] pki_subordinate=True pki_issuing_ca=https://dogtag.example.com:8443 pki_ca_signing_subject_dn=cn=subca signing, o=example.com Some notes: 1. The issuing CA and security domain port settings are for the root CA. 2. The other port settings and the pki_instance_name are set because I installed the sub CA on the same host as the root CA. You can take the defaults on these if the subCA is on a different host. On Fri, 2014-12-19 at 15:04 +1000, Fraser Tweedale wrote: > On Thu, Dec 18, 2014 at 06:14:08PM +0000, Dennis Gnatowski wrote: > > > > Can someone provide or point me to documentation on setting up a subordinate CA? I have a Root CA running DogTag 10.1.1 on Fedora 20 and I just want to create a subordinate CA to this Root CA (also using DogTag). > > ----------------------------------------------------------- > > Dennis Gnatowski > > dgnatowski at yahoo.com > > Hi Dennis, > > You need to provide a config file to pkispawn(8) to install a > subordinate CA. See section "Installing a subordinate CA" in the > pkispawn(8) man page for more information. > > Regards, > > Fraser > > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users