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