Subject: [Spasm] Comments on draft-housley-spasm-eku-constraints-00

From: "Jim Schaad" <[email-masked]>
Date: Fri, 13 May 2016 22:14:21 -0700

Russ,

I have a few comments on your draft.

1. I believe that doing the restriction to just CA certificates is
incorrect.  I believe that this is just as useful for an AA certificate.  I
would request that this restriction be relaxed and potentially removed.

2.  I believe that in section 3.1 an application should be able to require
that an EKU be permitted.  This seems to be a logical location to specified
that.  This is commonly done for Microsoft in saying that this root may be
used for specific key usages but not for others.

3.  I believe that step (p) (1) is missing a step, although it could
potentially go into step (h) in section 3.5
	(2) if excludedKeyPurposesIds is present in the certificate, set the
excluded_key_purpose_ids state varble to..   Set the permittedKeyPurposeIds
to the intersection of the result from step (1) and the inverse of the
excludedKeyPurposesIds.

	(3) if the excludedKeyPurposesId is the empty set, then fail the
validation procedure

	The certificate should be considered invalid regardless of the
presence of the EKU extension in the EE certificate.

4.  I recognize that this is the method that you feel is correct.  However,
justification text about why the current method used by Msft et al is not
correct is probably required.  At a minimum a recognition that this has been
the Msft behavior since day 1 is needed.

Jim

---

From: "Tom Gindin" <[email-masked]>
Date: Sat, 14 May 2016 13:22:31 -0400

Jim:

        On point 1, do AC's actually contain EKU extensions?  Your points 
2 and 3 appear to need another initialization variable to replace Russ' 
proposal in 3.2 (L).  That variable would be (J) 
initial-permitted-key-purpose-ids replacing the null in Russ' 3.1, and 
would be "a set of key purpose ID's permitted in extendedKeyUsage 
extensions appearing within the certification path".  The initial value in 
Russ' proposal should probably be anyExtendedKeyUsage (already defined in 
5280), and that would be the suggested default for this variable as well.
        My own justification text for point 4 would be something like 
"This extension is defined as separate from the extendedKeyUsage extension 
in order to avoid conflicts between the natural interpretation of that 
extension as constraining the behavior of the certificate subject and use 
as a path constraint.  Some current software uses the extendedKeyUsage 
extension within any issuer certificate as a path constraint, while RFC 
5280 4.2.1.12 states that in general it appears only in EE certificates."

Tom Gindin
P.S.    The above suggestions are mine, and not necessarily those of my 
employer.

From:   "Jim Schaad" <[email-masked]>
To:     <[email-masked]>
Cc:     [email-masked]
Date:   05/14/2016 01:14 AM
Subject:        [Spasm] Comments on draft-housley-spasm-eku-constraints-00
Sent by:        "Spasm" <[email-masked]>

Russ,

2.  I believe that in section 3.1 an application should be able to require
that an EKU be permitted.  This seems to be a logical location to 
specified
that.  This is commonly done for Microsoft in saying that this root may be
used for specific key usages but not for others.

3.  I believe that step (p) (1) is missing a step, although it could
potentially go into step (h) in section 3.5
                 (2) if excludedKeyPurposesIds is present in the 
certificate, set the
excluded_key_purpose_ids state varble to..   Set the 
permittedKeyPurposeIds
to the intersection of the result from step (1) and the inverse of the
excludedKeyPurposesIds.

                 (3) if the excludedKeyPurposesId is the empty set, then 
fail the
validation procedure

                 The certificate should be considered invalid regardless 
of the
presence of the EKU extension in the EE certificate.

4.  I recognize that this is the method that you feel is correct. However,
justification text about why the current method used by Msft et al is not
correct is probably required.  At a minimum a recognition that this has 
been
the Msft behavior since day 1 is needed.

Jim

_______________________________________________
Spasm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/spasm

---

From: "Jim Schaad" <[email-masked]>
Date: Sat, 14 May 2016 12:04:34 -0700

While the EKU extension is not listed as being an AA cert extension in RFC
5755, I can easily envision cases where one would put an EKU extension in an
AA certificate to restrict the permitted usages of that AA certificate.

I would not want to rule it out from future usage.

Yes, I would expect that the justification text would be along those lines.
I would like to see something along the lines of you cannot do X if you use
the old method and you can with the new method as well.  After all, this
document is changing the existing behavior in a significant number of places
and thus needs some solid reasons to do so other than "We think this is a
better idea".

Jim

From: Spasm [mailto:[email-masked]] On Behalf Of Tom Gindin
Sent: Saturday, May 14, 2016 10:23 AM
To: Jim Schaad <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [Spasm] Comments on draft-housley-spasm-eku-constraints-00

        Jim:

        On point 1, do AC's actually contain EKU extensions?  Your points 2
and 3 appear to need another initialization variable to replace Russ'
proposal in 3.2 (L).  That variable would be (J)
initial-permitted-key-purpose-ids replacing the null in Russ' 3.1, and would
be "a set of key purpose ID's permitted in extendedKeyUsage extensions
appearing within the certification path".  The initial value in Russ'
proposal should probably be anyExtendedKeyUsage (already defined in 5280),
and that would be the suggested default for this variable as well.
        My own justification text for point 4 would be something like "This
extension is defined as separate from the extendedKeyUsage extension in
order to avoid conflicts between the natural interpretation of that
extension as constraining the behavior of the certificate subject and use as
a path constraint.  Some current software uses the extendedKeyUsage
extension within any issuer certificate as a path constraint, while RFC 5280
4.2.1.12 states that in general it appears only in EE certificates."

Tom Gindin

From:        "Jim Schaad" <[email-masked]
<mailto:[email-masked]> >
To:        <[email-masked]
<mailto:[email-masked]> >
Cc:        [email-masked] <mailto:[email-masked]> 
Date:        05/14/2016 01:14 AM
Subject:        [Spasm] Comments on draft-housley-spasm-eku-constraints-00
Sent by:        "Spasm" <[email-masked]
<mailto:[email-masked]> >

  _____  

Russ,

                (2) if excludedKeyPurposesIds is present in the certificate,
set the

                (3) if the excludedKeyPurposesId is the empty set, then fail
the
validation procedure

                The certificate should be considered invalid regardless of
the
presence of the EKU extension in the EE certificate.

Jim

_______________________________________________
Spasm mailing list
[email-masked] <mailto:[email-masked]> 
 <https://www.ietf.org/mailman/listinfo/spasm>
https://www.ietf.org/mailman/listinfo/spasm

---

From: Michael Richardson <[email-masked]>
Date: Mon, 16 May 2016 09:18:20 -0400

Jim Schaad <[email-masked]> wrote:
    > 2.  I believe that in section 3.1 an application should be able to
    > require that an EKU be permitted.  This seems to be a logical location
    > to specified that.  This is commonly done for Microsoft in saying that
    > this root may be used for specific key usages but not for others.

So, I think you are saying that the application has an EKU list "above" the
CA. (in essence, in the trust store), and that this EKU list would restrict
which roots can even be picked for validation, regardless of what the root's
EKU list says.
I.e. my application trusts VendorFOO for Web anchors, but not javascript signing.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 16 May 2016 15:33:02 +0100

Hi Jim,

(In the same spirit as my mail to Santosh a minute ago...)

> would request that this restriction be relaxed and potentially removed.

Who operates an AA and wants to use this? If nobody, (as
I suspect), then I'd argue that it'd be better to be
entirely silent about AA's and ACs. If there niches of
networks where ACs are in use, then I don't think this
proposed WG is the place to argue about those, esp as
the folks who might be using that technology aren't
afaik likely to engage here. And if at some point someone
does want to re-use an extension in AA certs, then they
could update the relevant RFC or use another OID. In
the meantime, I would argue that this list does not need
to argue about ACs at all, as doing so would just be
likely wasted effort and distracting. And absent any
real usage, anyone writing code is also better off not
considering ACs at all as such code would for almost
all implementations just be dead code that's likely to
have more bugs than code that gets exercised.

S.

---

From: Russ Housley <[email-masked]>
Date: Mon, 16 May 2016 11:29:52 -0400

> would request that this restriction be relaxed and potentially removed.

Section 4.5 of RFC 3281 says that an AA cannot also be a CA, and the attribute certificate issued by the AA will not contain an EKU extension since the attribute certificate does not contain a public key.

The certification path for the AA certificate could include this certificate extension.

So, I am not seeing the benefit.  Please share the use case that you envision.

> used for specific key usages but not for others.

That could be done.  That would seem to have a greater impact on the APIs for path processing libraries.  And, it is not needed to fulfill the issue that was originally raised here:
https://mailarchive.ietf.org/arch/msg/pkix/MHwcSWuuzezj4qHuzSmbYeGUbdI

If we add a required-key-purpose-id input parameter, then it needs to have an empty set as the default.  I need to hear from others if it is needed.

> to the intersection of the result from step (1) and the inverse of the

I do not think this is needed.  The corrected logic below in the wrap-up step should be enough.

> presence of the EKU extension in the EE certificate.

Swapping the order probably make things more clear:

   (h)  If the EKU extension is included in the end-entity certificate,
        then confirm that the values meet the restrictions in the
        permitted_key_purpose_ids and excluded_key_purpose_ids state
        variables as follows:

        (1)  If excluded_key_purpose_ids state variable is empty, then
             return a failure indication and an appropriate reason.

        (2)  If excluded_key_purpose_ids state variable is not empty,
             then confirm that none of the key purpose identifiers are
             present in the set.  If any are present, then return a
             failure indication and an appropriate reason.

        (3)  If permitted_key_purpose_ids state variable is not special
             value that represents the universal set, then confirm that
             all of the key purpose identifiers are present in the set.
             If any are missing, then returning a failure indication and
             an appropriate reason.

> the Msft behavior since day 1 is needed.

We may need to develop some background text.  I’m willing to work on that text if there is support for this approach going forward.

Russ

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 16 May 2016 11:11:41 -0700

Russ,

-----Original Message-----
From: Russ Housley [mailto:[email-masked]] 
Sent: Monday, May 16, 2016 8:30 AM
To: Jim Schaad <[email-masked]>
Cc: [email-masked]
Subject: Re: Comments on draft-housley-spasm-eku-constraints-00 

Jim:

> incorrect.  I believe that this is just as useful for an AA 
> certificate.  I would request that this restriction be relaxed and
potentially removed.

Section 4.5 of RFC 3281 says that an AA cannot also be a CA, and the
attribute certificate issued by the AA will not contain an EKU extension
since the attribute certificate does not contain a public key.

The certification path for the AA certificate could include this certificate
extension.

So, I am not seeing the benefit.  Please share the use case that you
envision.

[JLS] I don't have a specific idea in mind at the moment.  I was just
running on a feeling.

> this root may be used for specific key usages but not for others.

That could be done.  That would seem to have a greater impact on the APIs
for path processing libraries.  And, it is not needed to fulfill the issue
that was originally raised here:
https://mailarchive.ietf.org/arch/msg/pkix/MHwcSWuuzezj4qHuzSmbYeGUbdI

If we add a required-key-purpose-id input parameter, then it needs to have
an empty set as the default.  I need to hear from others if it is needed.

[JLS] I would need to look at how the algorithm was specified to use this.
However, I would have thought that the default would be any key usage in the
permitted set rather than the empty set.  

permittedKeyPurposeIds
> to the intersection of the result from step (1) and the inverse of the 

I do not think this is needed.  The corrected logic below in the wrap-up
step should be enough.

        (1)  If excluded_key_purpose_ids state variable is empty, then
             return a failure indication and an appropriate reason.
[JLS] I think this is not a correct test - I would look at the permitted set
being empty not the excluded set.

[JLS] And if the EKU extension is not included in the end-entity certificate
what happens if the permitted_key_usage_purpose_ids state variable is the
empty set?

> 4.  I recognize that this is the method that you feel is correct.  
> However, justification text about why the current method used by Msft 
> et al is not correct is probably required.  At a minimum a recognition 
> that this has been the Msft behavior since day 1 is needed.

We may need to develop some background text.  I'm willing to work on that
text if there is support for this approach going forward.

Russ

---

From: Michael Richardson <[email-masked]>
Date: Mon, 16 May 2016 16:41:40 -0400

Stephen Farrell <[email-masked]> wrote:
    > Who operates an AA and wants to use this? If nobody, (as I suspect),
    > then I'd argue that it'd be better to be entirely silent about AA's and

Aren't SIDR objects AAs?

---

From: Russ Housley <[email-masked]>
Date: Mon, 16 May 2016 16:59:14 -0400

Jim:

> While the EKU extension is not listed as being an AA cert extension in RFC 5755, I can easily envision cases where one would put an EKU extension in an AA certificate to restrict the permitted usages of that AA certificate.

I do not see it.  There is not a key in an attribute certificate, so there cannot be a key usage or extended key usage.

Russ

---

From: Russ Housley <[email-masked]>
Date: Mon, 16 May 2016 17:40:04 -0400

> being empty not the excluded set.

Indeed.  Cut-and-paste error.

> what happens if the permitted_key_usage_purpose_ids state variable is the

Then the validation is successful because the constraints are not violated.

Russ