[Pki-users] Best way to bypass challenge password verification

[Peter Beal]

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