Subject: Re: [pkix] Updated claimSigning EKU Internet Draft

From: [email-masked] (Martin Rex)
Date: Thu, 2 Aug 2012 07:09:21 +0200 (CEST)

Stefan Santesson wrote:
> >
> >                      Unfortunately, due to recent events regarding the
> >abuse of certificates asserting Key Usage values of digitalSignature and
> >nonRepudiation, a number of policy authorities are mandating strict EKU
> >values in all certificates asserting these key usage values, and
> >mandating by policy that the anyEKU OID not be present. This means, that
> >absent this EKU value, we can't have claims signed by IDPs using PKI
> >Certificate credentials, due to strict RFC5280 enforcement.
> 
> I'm sorry, I still don't get this. If you find the cert in the metadata,
> you know that it is suitable to sign assertions. All verifier of the
> assertion consume metadata.
> Major implementations of SAML can handle this. They don't need any EKU.
> 
> I'm just asking you to clarify the use case and to position it relative to
> SAML metadata usage, which obviously works today.

The request seems to be motivated by a bureaucratic cover-your-ass
policy approach of some CAs or "policy authorities", rather than from
a genuine need to change the security properties of SAML.

It is close to impossible to change the security properties of
a long deployed installed base of a technology such as SAML
just by throwing an EKU definition after them.

The necessary sequence of events is probably:

  1. an EKU needs to be selected or assigned
     (since this is a plain ASN.1 OID, *ANY* OID will do,
      asking PKIX for an OID is just adding pain...)

  2. add the EKU and the desired semantics to a revision or
     new version of the SAML spec (or whatever).

  3. wait for implementations to adopt the new features

  4. wait for updated implementations to get deployed

  5. decide when to start "enforcing" that EKUs are present on
     the certs that signed claims.

-Martin

---

From: David Chadwick <[email-masked]>
Date: Thu, 02 Aug 2012 08:32:50 +0100

The series of events is even simpler than you suggest, see below

>        asking PKIX for an OID is just adding pain...)

use the existing standard SOAidentifier extension and the OID defined 
for this. Note that this extension is NOT critical, which is what you 
need in order for the migration to succeed successfully. Using a 
critical extension will screw up any chance of migration or interworking.

>       new version of the SAML spec (or whatever).

add this to profile of SAML

>       the certs that signed claims.

You dont need to enforce it ever, since the rules for non-critical 
extension processing mean that once an implementation understands the 
extension is must follow it. So enforcement becomes automatic once the 
certificate processing code is updated.

regards

David

>
>
> -Martin
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix
>

---

From: [email-masked] (Martin Rex)
Date: Thu, 2 Aug 2012 09:49:46 +0200 (CEST)

> critical extension will screw up any chance of migration or interworking.

This might be somewhat optimistic (IMHO unrealistic) about the
meaning of criticality of a certificate extension that by itself
is fairly meaningless to the PKIX certificate path validation function.

An application that doesn't care about EKU will often ... simply
not care about EKU.

> add this to profile of SAML

This addition would also have to specify whether
"anyKeyPurpose" is OK.

> certificate processing code is updated.

"Enforcing" means that the "app" (SAML) would have to check whether
the certificate contained an EKU cert extension, and when it did,
check whether the EKU extension contained the specific KeyPurpose(O)ID in
question, and abort with an error if EKU was present, but the
specific SAML KeyPurpose(O)ID was missing (or anyKeyPurpose is present
and acceptable).

-Martin