Re: RFC 7030 and CSR recreation due to new session causing new tls-unique value

Hi Michael,


> On 1 Feb 2019, at 8:51 am, Michael Ross <[email protected]> wrote:
> 
> RFC 7030 section 3.2.1 at https://tools.ietf.org/html/rfc7030#section-3.2.1 states "Additionally, if the client has already generated a CSR that includes linking identity and POP information (Section 3.5), then the CSR will need to be recreated to incorporate the tls-unique from the new, redirected session."
> 

Take a look at ESTService simpleEnrollPop( ... ), particularly the listener defined around line 353 of the same file as that method is defined within.

<bc-java>/pkix/src/main/java/org/bouncycastle/est/ESTService.java




> RFC 7030 section 4.2.3 at https://tools.ietf.org/html/rfc7030#section-4.2.3 states "If the client closes the TLS connections while waiting for the Retry-After time to expire, then the client initiates a new TLS connection and performs all applicable security checks.  If the client has already generated a CSR that includes linking identity and POP information (Section 3.5), then the CSR will need to be recreated to incorporate the tls-unique from the new, redirected session."
> 


The actual CSR is generated via a callback that is invoked when the connection is established. 
So in this case the user is supplying a builder that is called when the tls-unique is known rather than a completed CSR.

The redirection logic:

Take a look at  
	public ESTResponse doRequest(ESTRequest req throws IOException of DefaultESTClient.java (<bc-java>/pkix/src/main/java/org/bouncycastle/est/jcajce/DefaultESTClient.java)
and
	protected ESTRequest redirectURL(ESTResponse response) throws IOException



Let me know how you go.

MW