Re: [lamps] The problem with EKU for document signing demonstrated

[Stefan Santesson <[e-mail]>]

1) One or more EKU = Restricted to those usages

2) One or more EKU + anyExtendedKeyUsage = Suitable for the listed
usages but MAY be used for any purpose

3) No EKU = Unrestricted.


This means that case 2 can be suitable for document signing at the
discretion of the verifier and case 3 is suitable for document signing.
No EKU definition can change that.

There simply is no place for your broad claim that: "Clients MUST reject
documents signed by certificates without this EKU, except if being
operated in a legacy-compatibility mode."

The only way you can change this is by defining a new protocol for
document signing that requires this EKU. But no such generic standard
for document signing exists where such requirement could be stated. And
it would still just affect those who operate under the context of that
standard.


This is what makes document signing fundamentally different from, say
TLS client auth. or Timestamping. In those cases we have distinct
standards that can state requirement on the presence of an EKU.


/Stefan



On 2021-11-30 01:50, Ryan Sleevi wrote:
> That description seems to be in direct conflict with RFC 5280’s
> definition of EKU:
>
> https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.12
>
> > Certificate using applications MAY require that the extended key
> usage extension be present and that a particular purpose be indicated
> in order for the certificate to be acceptable to that application.
>
> And
> > Applications that require the presence of a particular purpose MAY
> reject certificates that include the anyExtendedKeyUsage OID but not
> the particular OID expected for the application.
>
> This matches the rough consensus of the IETF, such as RFC 6960 [1],
> and running code [2][3], so perhaps this explains my difficulty in
> understanding the concern/position/objection.
>
> [1] 
> https://datatracker.ietf.org/doc/html/rfc6960#section-4.2.2.2
> [2] 
> https://support.apple.com/en-us/HT210176
> [3] 
> https://docs.microsoft.com/en-us/security/trusted-root/program-requirements
>
> On Mon, Nov 29, 2021 at 7:38 PM Stefan Santesson <[e-mail]>
> wrote:
>
>     "Clients MUST reject documents signed by certificates without this
>     EKU, except if being operated in a legacy-compatibility mode."
>
>
>     That would be fundamentally in conflict with the definition of the
>     EKU extension. A certificate without EKU extension is not
>     restricted and a standard defining an EKU can only define its
>     meaning withing the context defined by the EKU extension itself.
>
>     It certainly has no mandate to regulate the behavior of
>     implementations that do not implement this standard (don't use
>     this EKU).
>
>     /Stefan
>
>
>
>     On 2021-11-30 01:04, Ryan Sleevi wrote:
>>     Then I’m not sure the point you’re making?
>>
>>     Russ highlighted that the sooner we can specify, the sooner that
>>     relying party applications can look to transition. Rich pointed
>>     out that this transition is predominantly for X and Y to sort out
>>     - the CAs issuing the certificates and the software verifying it.
>>
>>     There’s good reason to require the EKU present, and it’s
>>     precisely what EKU was designed for. There doesn’t seem anything
>>     inherently wrong in the spec spelling out the transition - that
>>     is, that clients MUST reject documents signed by certificates
>>     without this EKU, except if being operated in a
>>     legacy-compatibility mode.
>>
>>     We certainly don’t need the spec to detail what, exactly, that
>>     legacy date is - the UTF8String transition failures of PKIX show
>>     that - but that doesn’t seem to be an argument against.
>>
>>     This is why I’m struggling to follow your concern: it’s unclear
>>     if you oppose any transition at all, based on the reply to Russ,
>>     if you only oppose the draft mentioning any transition (e.g. as
>>     part of security considerations or as outlined above), or
>>     something else entirely. It’s still possible to write a MUST
>>     (with one exception), without resorting to a SHOULD (with
>>     unbounded exceptions), and it’s still possible to have a MUST
>>     with a transition.
>>
>>     On Mon, Nov 29, 2021 at 6:34 PM Stefan Santesson
>>     <[e-mail]> wrote:
>>
>>         Ryan,
>>
>>         You say the same as I:
>>
>>         "Y are free to change their requirements at any time"
>>
>>         In other words, the standard will not mandate that Y MUST
>>         reject the signature.
>>
>>         This is fine with me.
>>
>>         /Stefan
>>
>>
>>         On 2021-11-30 00:23, Ryan Sleevi wrote:
>>>
>>>
>>>         On Mon, Nov 29, 2021 at 6:09 PM Stefan Santesson
>>>         <[e-mail]> wrote:
>>>
>>>             Russ,
>>>
>>>             Without (or before) making any objections, I would like
>>>             to understand what "transition" this is.
>>>
>>>             If this is a transition towards -> Documents signed with
>>>             a cert where this EKU is not present, MUST be rejected,
>>>             then I would be worried.
>>>
>>>         It's unclear why this is problematic, and hopefully you can
>>>         be more explicit here.
>>>
>>>         The scenarios boil down to:
>>>         - X controls the issuing pipeline (e.g. the CA)
>>>         - Y controls the validation pipeline (e.g. the software vendor)
>>>         - Z controls the signing pipeline (e.g. you, the document
>>>         signer)
>>>
>>>         The certificates that Z is using have a lifetime dictated by
>>>         X, and a profile dictated by Y. X and Y are free to change
>>>         their requirements at any time; we see this regularly,
>>>         whether a software vendor requiring conformance to a
>>>         particular profile, or a policy authority dictating such
>>>         certificates conform to a profile. This is generally done
>>>         independent of Z, and the certificates that Z uses have
>>>         natural replacement cycles, in addition to any unusual
>>>         replacements.
>>>
>>>         Why should Z have any bearing on X or Y?
>>>
>>>         If Y decides to reject such signatures, and X doesn't issue
>>>         certificates with the EKU, isn't that primarily an issue
>>>         between X and Y? It doesn't impact how Z functions at all.
>>>
>
> _______________________________________________
> Spasm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spasm