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

From: Carl Wallace <[email-masked]>
Date: Tue, 01 Mar 2016 10:52:09 -0500

Inline...

On 2/29/16, 8:38 PM, "Max Pritikin (pritikin)" <[email-masked]> wrote:

>
>> On Feb 29, 2016, at 4:08 PM, Dan Harkins <[email-masked]> wrote:
>> 
>> 
>>  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.
>
>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.

I think we should leave 7030 as-is and go stronger on Max's last sentence.
I think we should say "MUST drop the challengePassword when both options
are present in /csrattrs" for clients with server still required to check
any and all that are presented. This should be accompanied by some words
noting the server MAY include both OIDs for backwards compatibility.

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

I have a hard time seeing "SHOULD indicate" the attributes the CA desires
as an improvement over "MAY indicate" which captures the fact that the CA
may not desire any of these. If the server aims to reject requests that
are missing a given attribute, MUST is more appropriate and more
consistent with 7030. How about:

"The EST server MAY indicate any or all of the alternative challenge
password attributes in the HTTP control URI path /csrattrs (see Sections
3.2.2 and 4.5 of [RFC7030]). Where the server requires a particular
challenge password attribute to be present in a certificate request, the
server MUST include the corresponding OID in the CSR Attributes Response.
The EST client SHOULD include the indicated attributes in the subsequent
CSR. The EST server can of course refuse enrollment requests that are not
encoded according to the CA's policy."

>
>- max
>
>>  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 16:50:46 +0000

> On Mar 1, 2016, at 8:52 AM, Carl Wallace <[email-masked]> wrote:
> 
> Inline...
> 

This works for me. Below we clarify a nuance for the challengePassword in the csrattribs,

> server MUST include the corresponding OID in the CSR Attributes Response.

This is consistent with the current language about ‘MUST’ include challengePassword in the csrattributes if linking is expected. The nuance is that for RFC7030 compliance they both are required.

Looking forward to Dan’s perspective,

- max

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 1 Mar 2016 09:21:06 -0800 (PST)

On Mon, February 29, 2016 5:38 pm, Max Pritikin (pritikin) wrote:
> 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.

  I think the behavior specified by your I-D should be that it is OK
for a new server to send both in a CSR Attrs response. If a client sees
estIdentityLinking it should prefer that and use it in lieu of
challengePassword.

  That way if a new server interacted with an old client the old client
would not understand estIdentityLinking and skip over it and use
challengePassword. If a new client interacted with an old server it
would not see estIdentityLinking and the old server would be following
the MUST above so the client would get a challengePassword in the
CSR Attrs response.

> Any comments on this direction?

  If the client uses /csrattrs to get some instruction from the
server on how to construct the CSR then I don't see this as an issue.
It will do what the server indicates and there's no problem.

  How unlikely is this though? The premise of this draft is that
the server (and presumably the CA it is fronting for) wants to use
additional OTP authentication or have some revocation challenge.
If it doesn't, or if it's old, then why would the client presume
that the server needs this?

  That said, I guess I would agree with the thread snippit. The older
server doesn't recognize this information and should not refuse the
CSR on that account. They'd be discarded by the CA when it signs the
request.

> works for me. It just isn’t a MUST.

  As a libertarian I'm overjoyed that no one is trying to tell me
what to do. As someone who's trying to write code I would like to
see interoperate with others I think I'd like to see some direction,
as much for me as for my faith in the expected behavior of my peer.
It sounds kind of totally free-form optional "yea, include any or all,
or dance a jig, or wear a funny hat...or not, it's up to you!"

  Given that /csrattrs itself is optional what is your opposition
to making those into MUSTs? You're not forced to do /csrattrs and if
you don't you will have the issues discussed in the thread snippet
as a consequence, but that's your problem for not using available
tools. _IF_ on the other hand, the client elects to do /csrattrs and
asks the server what it should do then section 4 should say:

  "The EST server MUST indicate these attributes, as the particular
use case requires, in every CSR Attributes Response. The client MUST
include every indicated attribute for which it has values in the
subsequent CSR.

  "Note that the 'estIdentityLinking' attribute is a disambiguated
alternative to the overloading of the 'challengePassword' in section
3.5 of [RFC7030]. In order to support legacy clients, the EST server
MUST check the [RFC7030] 'challengePassword' as specified in [RFC7030]
if an 'estIdentityLinking' attribute is not present. Similarly, EST
clients that do not perform /csrattrs SHOULD include both the
'estIdentityLinking' attribute and the 'challengePassword' attribute
as specified in [RFC7030] to support legacy servers."

  How's that? If they do /csrattrs then all works as defined. If
they don't then they'll support their legacy peer as appropriate.

  Dan.

---

From: Carl Wallace <[email-masked]>
Date: Tue, 01 Mar 2016 13:42:48 -0500

Here's an attempt at addressing Dan's comments in the new section 4 (this
also includes a few mods already made in response to the genart review).
There is some minor friction between the MUST drop challengePassword
attribute and the MAY include both in the second. The client in the second
paragraph may be working with a server that does not support csrattrs, so
sending both is safest. This seems OK to me. Thoughts?

4.  Indicating Support for the Alternative Challenge Password Attributes

   The EST server MAY indicate any or all of these in the HTTP control
   URI path /csrattrs (see Sections 3.2.2 and 4.5 of [RFC7030]).  Where
   the server requires a particular challenge password attribute to be
   present in a certificate request, the server MUST include the
   corresponding OID in the CSR Attributes Response.  The EST client
   SHOULD include the indicated attributes in the subsequent CSR except
   where estIdentityLinking and challengePassword are both present.  In
   these cases, the EST client MUST ignore the presence of the
   challengePassword and use estIdentityLinking in the certificate
   request.  EST servers MAY include both estIdentityLinking and
   challengePassword in the CSR Attributes Response to provide for
   backwards compatibility.  The EST server can of course refuse
   enrollment requests that are not encoded according to the CA's
   policy.

   Note that the "estIdentityLinking" attribute is a disambiguated
   alternative to the overloading of the "challengePassword" in section
   3.5 of [RFC7030], therefore any EST server that requests
   "estIdentityLinking" MUST check the [RFC7030] "challengePassword" as
   specified in [RFC7030] as well as the "estIdentityLinking" requested
   in order to support legacy EST clients.  EST clients that include the
   "estIdentityLinking" attribute MAY also include the
   "challengePassword" attribute.  EST servers MUST evaluate each
   challenge password attribute independently.  All challenge password
   attributes included by an EST client MUST be successfully verified by
   an EST server for a request to be considered valid.

On 3/1/16, 12:21 PM, "Dan Harkins" <[email-masked]> wrote:

>> 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.
>
>> language in s4? I think this is Ok, the old server simply doesnât meet
>> 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.
>

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Tue, 1 Mar 2016 20:05:08 +0000

It is a little silly to state, 

[Dan’s text]
> "The EST server MUST indicate these attributes, as the particular use case requires” 

since the server isn’t required to indicate the attributes. Meaning the “MUST” is an overstatement where the deciding factor is the use case. 

Carl’s text captures the flexibility of this by using MAY, and then needs to include a bunch of clarifying text to keep alignment with RFC7030 text:
[Carl’s text]
>   corresponding OID in the CSR Attributes Response.

But even though it is silly the use of MUST is shorter, easier to read, consistent with the way this was worded in RFC7030 and ultimate might be clearer. 

Some additional comments inline, 

> On Mar 1, 2016, at 11:42 AM, Carl Wallace <[email-masked]> wrote:
> 
>   corresponding OID in the CSR Attributes Response.

Right about here I feel the paragraph starts to veer from client to server and back again. Perhaps group the sentences differently? Like the following. Note that it is three paragraphs, 1) server behavior 2) client behavior 3) server behavior in the order the messages are prepared:

> The EST server MUST indicate these attributes, as the particular use case requires, in every CSR Attributes Response. An EST server MAY send both the "estIdentityLinking" and also the RFC7030 “challengePassword" in a CSR Attrs response to ensure support for legacy RFC7030 clients. 
> The client MUST include every indicated attribute for which it has values in the subsequent CSR. If a client sees "estIdentityLinking” in a CSR Attributes Response it SHOULD prefer that and not include an RFC7030 “challengePassword” in the resulting CSR. EST clients that include an unsolicited "estIdentityLinking" attribute MAY also include the RFC7030 "challengePassword” attribute to ensure support for legacy RFC7030 servers. 
> EST servers MUST evaluate each challenge attribute independently.  All challenge attributes included by an EST client MUST be successfully processed by an EST server for a request to be considered valid. The EST server MAY ignore challenge attributes according to local policy, for example if the EST client is an authenticated Registration Authority the EST server ignores the “estIdentityLinking” within a CSR (see RFC7030, s3.7 second paragraph). The EST server MAY refuse enrollment requests that are not encoded according to the CA’s policy.

Here I used Dan’s phrasing because it is quicker and easier to type.

- max

>  The EST client

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 1 Mar 2016 12:47:05 -0800 (PST)

Hi Carl,

> sending both is safest. This seems OK to me. Thoughts?

 I really like this. But I'd like to explore this RFC 2119
language a bit more.

>    enrollment requests that are not encoded according to the CA's

  The whole point of this draft is to address use cases where there
may be some ambiguity or difficulty in how to express what the server
requires. To quote section 1:

  "For example an EST server might require the client to authenticate
   itself using the existing client X.509 certificate, the user's
   username and password and to include a One-Time Password within
   the Certificate Signing Request all while maintaining identity
   linking to bind the CSR to the secure transport. The overloading
   of a single attribute type should not be the limiting factor for
   administrators attempting to meet their security requirements."

  Now MAY is truly optional, one vendor may include it and another
may not. Now how does allowing one vendor to decide not to implement
a coherent expression of requirements serve the goals of this draft?
I say it doesn't.

  EST supports the case where the server wants to do both X.509
certificate authentication and username/password authentication. And
now there is a desire to also require an OTP in the CSR. But the
implementer decided that as a truly optional MAY he didn't implement
that. So the client issues a /csrattrs and the server did his MAY
include anything or nothing as he sees fit and as a result the client
doesn't send the OTP in his CSR and it got rejected. Too bad, so sad.

  The thing is, there is a mechanism in EST to address the problem
this draft says is its motivation-- /csrattrs-- and you're deciding
to kind of muddy the semantics of that mechanism to make it likely
that the problem will persist.

  Since /csrattrs are already optional I don't see a problem with
requiring some particular semantics in the event that it is used.
Can someone explain that problem to me?

  regards,

  Dan.

---

From: Carl Wallace <[email-masked]>
Date: Tue, 01 Mar 2016 15:53:44 -0500

It finally clicked for me...

On 3/1/16, 3:47 PM, "Dan Harkins" <[email-masked]> wrote:

><snip>
>may not. 

Right. I was locked into thinking about what would be configured at
runtime. Thank you for taking the time to jar me out of my fog.

>Now how does allowing one vendor to decide not to implement

Max and I have been exchanging text in a side thread. Here is the latest,
which uses your words liberally:

4.  Indicating Support for the Alternative Challenge Attributes

   The EST server MUST indicate these attributes, as the particular use
   case requires, in every CSR Attributes Response.  An EST server MAY
   send both the "estIdentityLinking" and also the [RFC7030]
   "challengePassword" in a CSR Attrs response to ensure support for
   legacy [RFC7030] clients.

   The client MUST include every indicated attribute for which it has
   values in the subsequent CSR.  If a client sees "estIdentityLinking"
   in a CSR Attributes Response it SHOULD prefer that and not include an
   [RFC7030] "challengePassword" in the resulting CSR.  EST clients that
   include an unsolicited "estIdentityLinking" attribute MAY also
   include the [RFC7030] "challengePassword" attribute to ensure support
   for legacy [RFC7030] servers.

   EST servers MUST evaluate each challenge attribute independently.
   All challenge attributes included by an EST client MUST be
   successfully processed by an EST server for a request to be
   considered valid.  The EST server MAY ignore challenge attributes
   according to local policy, for example if the EST client is an
   authenticated Registration Authority the EST server ignores the
   "estIdentityLinking" within a CSR (see [RFC7030], s3.7 second
   paragraph).  The EST server MAY refuse enrollment requests that are
   not encoded according to the CA's policy.

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 1 Mar 2016 15:46:43 -0800 (PST)

Hi Carl,

>    not encoded according to the CA's policy.

  This look marvelous! Thank you very much. Please consider my comments
addressed.

  regards,

  Dan.