Subject: [pkix] review of draft-wallace-est-alt-challenge

From: "Dan Harkins" <[email-masked]>
Date: Mon, 29 Feb 2016 15:08:44 -0800 (PST)

Hi,

  RFC 7030 says in 4.5.2 that "If an EST server requires the linking
of identity and POP information (see Section 3.5), it MUST include
the challengePassword OID in the CSR Attributes Response." Now if
a server wants to use the disambiguated estIdentityLinking OID
instead it will be forced to include both in its CSR Attrs response
which might cause a client to violate the SHOULD NOT in section 4
of this draft through simply trying to comply with the server's
request. I suggest having this draft modify RFC 7030 and remove that
"MUST" if the server sends the estIdentityLinking OID in its CSR
Attrs response.

  Also, why does it say "The EST server MAY indicate any or all of
these [attributes] in the /csrattrs"? Servers don't (won't) just
include random junk in a CSR Attrs response, they use the CSR Attrs
response to tell the client how to construct the CSR. If it wants to
use any of these new attributes this should, at least, be a SHOULD.
Using the description in RFC 2119, there may be valid reasons for
an EST server not to indicate these attributes in a CSR Attrs response
this but the full implications of this (i.e. the CA possibly rejecting
certificate signing requests that it would've otherwise not rejected)
must be understood. In other words, SHOULD.

  Otherwise, looks good! I'll implement this as soon as the OIDs
get assigned.

  regards,

  Dan.

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Tue, 1 Mar 2016 01:38:32 +0000

> On Feb 29, 2016, at 4:08 PM, Dan Harkins <[email-masked]> wrote:
> 
> 
>  Hi,
> 

Thanks for the review comments!

I agree, the new text will have to clarify what a server does. From a backwards compatibility perspective (maybe it has an old client on the line) doesn’t it logically want to include both ‘challengePassword” and ‘estIdentityLinking’? Newer clients can be instructed that they MAY drop the ‘challengePassword’ since it is duplicate information.

Carl and I were also discussing what happens when a new client communicates with an older server:

(from our thread):
What if a newer client includes id-otpChallenge, id-revocationChallenge,
and id-estIdentityLinking along with a duplicate value for
id-estIdentityLinking stashed in the challengePassword field. Is an older
EST server wrong to accept this CSR even though it did not meet the above
language in s4? I think this is Ok, the old server simply doesn’t meet
the new RFC. Do you agree?

Any comments on this direction?

> must be understood. In other words, SHOULD.

The server “SHOULD indicate any or all of these attributes that are relevant”? Thus they MAY skip including any that are not relevant? That works for me. It just isn’t a MUST. 

- max