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

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Michael Ross
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."

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."

Where is the code that fulfills this requirement? I have not been able
to locate it.

I am sorry for asking such a stupid question. I am new here.

Thank you.

Very Respectfully,

Michael Ross



smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

MEGAN WOODS-3
Hi Michael,


On 1 Feb 2019, at 8:51 am, Michael Ross <[hidden email]> 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