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

[Fraser Tweedale]

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