Subject: [pkix] Updated claimSigning EKU Internet Draft

From: Matt King <[email-masked]>
Date: Thu, 26 Jul 2012 10:50:58 -0400

Dear PKIX Members

Patrick Patterson and I respectfully submit the updated claimSigning
EKU internet draft titled “draft-king-pkix-claimsigning-extn-0.txt”
(abstract below and updated version attached) for your review prior to
our discussion at next week's PKIX WG meeting.

We have addressed comments provided in the March meeting and believe
this version is ready to move forward.

I will post this version using the I-D Submission Tool on July 30th.

Abstract

   This document specifies an Extended Key Usage (EKU) value which
   indicates that the certificate holder is authorized to sign security
   tokens to assert claims, or attributes, about a subject.

   When a certificate that asserts the claimSigning EKU signs a claim,
   the owner of the service holding that certificate is asserting that a
   statement about the subject is true. For example, a IdP secure token
   service (STS) would use an X.509 certificate containing the
   claimSigning EKU to sign SAML assertions containing an identifier and
   attributes about a user. This EKU value would allow for a separation
   between the designation that a given Identity belongs within a given
   Federation, and the empowerment of that entity within the federation
   to sign claims..  This approach allows for greater flexibility for
   the operators of Federated systems and for Certification Authorities
   and avoids the overloading of other, already established methods
   (such as Assurance Level designation via certificatePolicy OID).

Matt
--
Matt King
Protiviti, Inc.
Government Services
[email-masked]
[email-masked]
410-271-5624 (Mobile)

---

From: David Chadwick <[email-masked]>
Date: Thu, 26 Jul 2012 17:17:41 +0100

Dear Matt

I dont think this ID is needed since the X.509 standard already defines 
the extension you are looking for. Its called SOA identifier (source of 
authority identifier), and the standard states

  "the certificate subject may ..... use the private-key corresponding 
to the certified public-key to issue certificates that
assign privilege to holders."

So this extra extension confers the administrative authority you are 
looking for. Whilst the X.509 text was written before SAML assertions 
were widely known about it does not specifically state "issue SAML 
assertions". But since SAML assertions as a type of certificate, XML 
encoded rather than ASN.1 encoded, then one can interpret the text as 
covering SAML assertions as well as X.509 certificates.

regards

David

On 26/07/2012 15:50, Matt King wrote:
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix
>

---

From: Patrick Patterson <[email-masked]>
Date: Fri, 27 Jul 2012 11:44:25 -0400

Hello David,

On 2012-07-26, at 12:17 PM, David Chadwick wrote:

> Dear Matt
> 
> I dont think this ID is needed since the X.509 standard already defines the extension you are looking for. Its called SOA identifier (source of authority identifier), and the standard states
> 
> "the certificate subject may ..... use the private-key corresponding to the certified public-key to issue certificates that
> So this extra extension confers the administrative authority you are looking for. Whilst the X.509 text was written before SAML assertions were widely known about it does not specifically state "issue SAML assertions". But since SAML assertions as a type of certificate, XML encoded rather than ASN.1 encoded, then one can interpret the text as covering SAML assertions as well as X.509 certificates.
> 

Ok - so how would this work in practice? I've not seen too many relying party applications that know what to do with this extension.  Also, is the SOA extension allowed within an X.509 Identity Certificate? All of the references I can find to it talk about its use in an Attribute Certificate. What would be the keyUsage parameters then?

The other thing is that a given IDP may NOT be the Source of Authority for an attribute asserted in the claim - it could be operated according to some Federation rules that may allow it to pull from the true Source of Authority (for instance, an Active Directory instance, the DUNS database, Department of Commerce CAGE code registry, etc.) and bundle those attributes into one or more SAML Assertions. So I think that even if SOA is valid in Identity Certificates (which it will have to be, since I know of very few PKIs that deal in ACs), this may not confer the right information from my reading of X.509.

The concept with the EKU value is that it simply indicates that the holder of the cert can be used to sign claims - but in a way that doesn't pollute or overload the certificatePolicy extension like some have been doing to indicate a certificate may be used to sign PIV cards, for instance :) As it states in the ID, Federation Realm designation is out of scope.

Cheers,

---
Patrick Patterson
Chief PKI Architect
Carillon Information Security Inc.
http://www.carillon.ca

---

From: David Chadwick <[email-masked]>
Date: Fri, 27 Jul 2012 17:43:49 +0100

Hi Patrick

On 27/07/2012 16:44, Patrick Patterson wrote:
>> I dont think this ID is needed since the X.509 standard already
>> defines the extension you are looking for. Its called SOA
>> identifier (source of authority identifier), and the standard
>> states
>>
>> "the certificate subject may ..... use the private-key
>> corresponding to the certified public-key to issue certificates
>> that assign privilege to holders."
>>
>> So this extra extension confers the administrative authority you
>> are looking for. Whilst the X.509 text was written before SAML
>> assertions were widely known about it does not specifically state
>> "issue SAML assertions". But since SAML assertions as a type of
>> certificate, XML encoded rather than ASN.1 encoded, then one can
>> interpret the text as covering SAML assertions as well as X.509
>> certificates.
>>
>
> Ok - so how would this work in practice?

Very similar to your proposed EKU. The concept is the same. A subject's 
PKC is given an extension to say that they are the attribute authority 
for issuing privilege attributes to other entities. (Note in the 
discussion below I am using AA rather than SOA since most people 
currently do not support delegation of authority but assume the AA is 
the SOA. But once you introduce dynamic delegation of authority you need 
to differentiate between the SOA and the subordinate AAs (as in trust 
anchor CAs and subordinate CAs)).

In terms of encoding, there is an OID for the SOAidentifier extension 
(whose content is null), whereas with EKU there is an OID for the new 
key usage. Once you have detected this OID in your PKC, thereafter the 
code you need for validating certs/assertions/claims is the same.

  I've not seen too many
> relying party applications that know what to do with this extension.

You do the same as you propose with your extension.
If the certificate/assertion/claim (these are all synonymous 
conceptually) is signed by an authority who has a PKC with the 
extension, then the signer is authorised by the CA to issue 
certs/assertions/claims. If no such extension exists in the signer's 
PKC, then it is up to the relying party to determine who the trusted 
attribute authorities are. What this extension effectively does is 
remove the set of trusted AAs from the RP's configured trust store, and 
replaces it with a trusted CA, and the trusted CA then dynamically says 
who the trusted AAs are (by inserting this extension in their PKCs).

Of course on its own this one extension is not enough, since the RP 
needs to know the following (at least)

i) who are the trusted AAs.
ii) which attributes is each AA trusted to issue
iii) who can the AA issue these attributes to.

so for example, you might trust Bank of America AA to issue visa 
attributes to anyone, the university of kent to issue student attributes 
to anyone with a kent email address etc.

> Also, is the SOA extension allowed within an X.509 Identity
> Certificate?

yes its only allowed in PKCs and not in ACs.
Remember that the PMI infrastructure is conceptually separate from the 
PKI infrastructure.

All of the references I can find to it talk about its
> use in an Attribute Certificate.

No, its not allowed in ACs. I will copy the standard text for you at the 
end of this message in case you dont have access to it.

  What would be the keyUsage
> parameters then?

Key usage is a PKI concept not a PMI concept.
SOAIdentifier is the bridge between PKI and PMI. It allows the PKI to 
transitively pass trust to the root of the PMI.

>
> The other thing is that a given IDP may NOT be the Source of
> Authority for an attribute asserted in the claim - it could be
> operated according to some Federation rules that may allow it to pull
> from the true Source of Authority (for instance, an Active Directory
> instance, the DUNS database, Department of Commerce CAGE code
> registry, etc.) and bundle those attributes into one or more SAML
> Assertions.

this is confused thinking. If the SAML assertion has no history of its 
origin, but only contains attributes signed by the SAML authority, then 
by definition that SAML authority is the root of trust (otherwise the 
assertion is not trusted). The only way you can have an intermediate 
authority issue an attribute assertion for which it is not 
authoritative, is if the SOA has delegated authority to it. In which 
case the RP must have a delegation certificate (or set of trust rules) 
which state that the intermediate authority is trusted to issue the 
following attributes on behalf of the SOA.

So I think that even if SOA is valid in Identity
> Certificates (which it will have to be, since I know of very few PKIs
> that deal in ACs), this may not confer the right information from my
> reading of X.509.

you can read the X.509 extension text below

>
> The concept with the EKU value is that it simply indicates that the
> holder of the cert can be used to sign claims

which is the same concept as SOAidentifier.

- but in a way that
> doesn't pollute or overload the certificatePolicy extension

this is irrelevant isnt it, since certificatePolicy is to do with PKI 
validation, but the new extension is to do with PMI validation.

  like some
> have been doing to indicate a certificate may be used to sign PIV
> cards, for instance :) As it states in the ID, Federation Realm
> designation is out of scope.

regards

David

15.3.2      SOA extension fields
The following extension fields are defined:
a)     SOA identifier;
b)    Attribute descriptor.
15.3.2.1   SOA identifier extension
15.3.2.1.1  SOA identifier extension definition
The SOA identifier extension indicates that the certificate subject may 
act as an SOA for purposes of privilege
management. As such, the certificate subject may define attributes that 
assign privilege, issue attribute descriptor
certificates for those attributes and use the private-key corresponding 
to the certified public-key to issue certificates that
assign privilege to holders. Those subsequent certificates may be 
attribute certificates or public-key certificates with a
subjectDirectoryAttributes extension containing the privileges.
In some environments, this extension is not required and other 
mechanisms may be used to determine the entities that
may act as SOAs. This extension is required only in environments where 
tight centralized control by a CA is required to
manage the entities that act as SOAs.

This field is defined as follows:
sOAIdentifier EXTENSION  ::=  {
   SYNTAX            NULL
   IDENTIFIED BY         id-ce-sOAIdentifier }
If this extension is not present in a certificate, the subject/holder 
ability to act as an SOA shall be determined by other
means.
This field may only be present in a public-key certificate issued to an 
SOA. It shall not be included in attribute
certificates or public-key certificates issued to other AAs or to 
end-entity privilege holders.
Cross-certification applies only to public-key certificates and not to 
attribute certificates. Therefore, a cross-certificate
issued to the CA that is the issuer of a certificate containing the SOA 
identifier extension does not provide transitive trust
to the SOA identified in this extension.
This extension is always non-critical

>
> Cheers,
>
> --- Patrick Patterson Chief PKI Architect Carillon Information
> Security Inc. http://www.carillon.ca
>
>
>
>
>

---

From: Patrick Patterson <[email-masked]>
Date: Sun, 29 Jul 2012 17:36:57 -0400

Hello David,

On 2012-07-27, at 12:43 PM, David Chadwick wrote:

> Very similar to your proposed EKU. The concept is the same. A subject's PKC is given an extension to say that they are the attribute authority for issuing privilege attributes to other entities. (Note in the discussion below I am using AA rather than SOA since most people currently do not support delegation of authority but assume the AA is the SOA. But once you introduce dynamic delegation of authority you need to differentiate between the SOA and the subordinate AAs (as in trust anchor CAs and subordinate CAs)).
> 
> In terms of encoding, there is an OID for the SOAidentifier extension (whose content is null), whereas with EKU there is an OID for the new key usage. Once you have detected this OID in your PKC, thereafter the code you need for validating certs/assertions/claims is the same.
> 

Ok - however, with a number of the new certificate policies that are being put in place due to recent events, the trend is towards moving to a mandatory, restrictive EKU for certificates that assert both digitalSignature and nonRepudiation/contentCommitment KU bits, with anyEKU specifically disallowed. Since I would presume that any SOA would require both of these, and RFC5280 processing rules prohibit relying party applications from allowing a certificate for a purpose that is not allowed by the EKU value, I still don't see how this would help?

> If the certificate/assertion/claim (these are all synonymous conceptually) is signed by an authority who has a PKC with the extension, then the signer is authorised by the CA to issue certs/assertions/claims. If no such extension exists in the signer's PKC, then it is up to the relying party to determine who the trusted attribute authorities are. What this extension effectively does is remove the set of trusted AAs from the RP's configured trust store, and replaces it with a trusted CA, and the trusted CA then dynamically says who the trusted AAs are (by inserting this extension in their PKCs).
> 

Ok - but there is a difference between implementing a simple check for an OID value of an already understood extension, and implementing support for an extension that hitherto has not traditionally been understood. Furthermore, from what you included, this extension cannot be marked critical, which is not what is desired for the claimSigning EKU. 

> Of course on its own this one extension is not enough, since the RP needs to know the following (at least)
> 
> so for example, you might trust Bank of America AA to issue visa attributes to anyone, the university of kent to issue student attributes to anyone with a kent email address etc.
> 

As I said in the draft, Federation Realm designation, and the marking of who is authorised as a Trust point (either CA or IDP) is out of scope for this ID. 

So, I would suggest that there is still a requirement for this ID. :)

Best Regards,

---
Patrick Patterson
Chief PKI Architect

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 30 Jul 2012 12:04:40 -0700

I have a number of issues/questions regarding this draft (still).

1) Definition of "Claim"
This EKU is said to state that the subject is appropriate to sign
"claims", but the draft does not make an effort to define what a claim is.
It provides the examples SAML assertions and Attribute Assertions, but
does not state what else could be regarded as a claim.
Thus this EKU could be used for virtually anything in absence of a clear
definition.

2) Explain when this EKU is needed, relative to metadata and
pre-configured trust.
The only examples are SAML. In SAML it is common to either preconfigure
trust in assertion signers, removing the need for an EKU, or by placing
the cert in signed metadata also removing the need for an EKU. What are
the particular use-case where you would neither use metadata, nor
pre-configured trust?
A clarification of this would help the reader to understand when this EKU
is appropriate.

3) Discussion about assurance levels and policy OIDs.
When would you convey information about assurance level of an assertion in
a certificate policy of the signing certificate?
Information about assurance level is provided in SAML requests and
responses.
Information about what assurance level the IdP is trusted to provide
(certified for) is normally provided in signed metadata (SAML) or may be
implicit in the case of pre-configured trust.
When would it be appropriate to solve this using cert policies?
Is there any deployed examples of this?

/Stefan

On 12-07-26 9:50 AM, "Matt King" <[email-masked]> wrote:

>EKU internet draft titled ³draft-king-pkix-claimsigning-extn-0.txt²

---

From: Patrick Patterson <[email-masked]>
Date: Mon, 30 Jul 2012 17:35:09 -0400

Hello Stefan:

> Thus this EKU could be used for virtually anything in absence of a clear

Ok - I'll work with Matt to come up with this kind of wording.

> A clarification of this would help the reader to understand when this EKU

The necessity of this EKU does not mean that Federations do not use Metadata to exchange information regarding who is a trusted IDP in their environment. The main reason for this EKU is to allow a Certificate to be used by an IDP to sign claims. As we state in the draft, if we don't have this EKU, then we have to have a certificate that doesn't have an EKU value to sign claims. 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. 

> Is there any deployed examples of this?

Since this I-D isn't part of a protocol definition, is this really appropriate? 

---
Patrick Patterson
Chief PKI Architect

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 30 Jul 2012 14:52:16 -0700

In line;

On 12-07-30 2:35 PM, "Patrick Patterson" <[email-masked]> wrote:

>The necessity of this EKU does not mean that Federations do not use
>Metadata to exchange information regarding who is a trusted IDP in their
>environment. The main reason for this EKU is to allow a Certificate to be
>used by an IDP to sign claims. As we state in the draft, if we don't have
>this EKU, then we have to have a certificate that doesn't have an EKU
>value to sign claims. 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.

>Since this I-D isn't part of a protocol definition, is this really

Well, I think you need to clarify under what type of implementation, what
you write makes sense.
I would for example consider this quite odd in a SAML federation using
SAML metadata. And I don't think a SAML federation with pre-configured
trust cares.

/Stefan

---

From: "David A. Cooper" <[email-masked]>
Date: Tue, 31 Jul 2012 13:37:27 -0400

Stefan,

Based on earlier discussions that I've had with some of the editors of 
this document, I believe that the reason the draft isn't entirely clear 
about what might constitute a "Claim" is that there is a desire for the 
definition of this OID to be somewhat generic so that in the future, 
when a key purpose OID is needed to indicate that the subject is 
authorized to sign "claims," this OID can be used rather than having to 
define a new OID for each specific application.

As an example, there are some signed CMS objects on PIV Cards. The CMS 
objects contain such things as biometric data of the cardholder and/or a 
unique identifier that has been assigned to the card.  In FIPS 201, a 
key purpose OID was defined, id-PIV-content-signing, and there is a 
requirement that the signer of the CMS objects on the PIV Card must have 
a certificate that asserts the id-PIV-content-signing key purpose OID.  
When PIV-Interoperable cards were defined (similar to PIV Cards, but not 
issued by the U.S. Federal government), a new key purpose OID needed to 
be defined for the signers of the CMS objects on those cards, 
id-fpki-pivi-content-signing.  It was noted that if there were a generic 
"claim signing" OID, then that OID could be used for both PIV and PIV-I 
Cards in addition to other cards that don't qualify as either PIV or 
PIV-I.  We even received a comment on the current draft of FIPS 201 
(http://csrc.nist.gov/publications/drafts/fips201-2/draft-fips-201-2_comments_disposition-for-2011-draft.pdf) 
asking that FIPS 201 specify the use of the claimSigning OID being 
discussed in the PKIX WG rather than (or in addition to) the 
id-PIV-content-signing OID.

Dave

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 31 Jul 2012 10:55:38 -0700

David,

A broad definition of "Claim" may be appropriate, but there need to be one.
Absent a definition, the EKU becomes somewhat pointless as usage
declaration.

/Stefan

---

From: Sean Turner <[email-masked]>
Date: Tue, 31 Jul 2012 14:02:20 -0700

I'm confused how a vague definition of a claim lines up with the need 
for a specific EKU (from Patrick's earlier message):

   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.

You need a specific EKU to indicate you can sign a nebulous thing. 
What's the client going to check to know whether it's signing a claim or 
not?

spt

---

From: David Chadwick <[email-masked]>
Date: Tue, 31 Jul 2012 22:02:30 +0100

Hi Patrick

On 29/07/2012 22:36, Patrick Patterson wrote:
>> Very similar to your proposed EKU. The concept is the same. A
>> subject's PKC is given an extension to say that they are the
>> attribute authority for issuing privilege attributes to other
>> entities. (Note in the discussion below I am using AA rather than
>> SOA since most people currently do not support delegation of
>> authority but assume the AA is the SOA. But once you introduce
>> dynamic delegation of authority you need to differentiate between
>> the SOA and the subordinate AAs (as in trust anchor CAs and
>> subordinate CAs)).
>>
>> In terms of encoding, there is an OID for the SOAidentifier
>> extension (whose content is null), whereas with EKU there is an OID
>> for the new key usage. Once you have detected this OID in your PKC,
>> thereafter the code you need for validating certs/assertions/claims
>> is the same.
>>
>
> Ok - however, with a number of the new certificate policies that are
> being put in place due to recent events, the trend is towards moving
> to a mandatory, restrictive EKU for certificates that assert both
> digitalSignature and nonRepudiation/contentCommitment KU bits,

Well if you have a requirement for a mandatory EKU, then you either have 
to have an EKU, or remove the mandatory requirement. I dont see an 
alternative to this. (Of course this is not a requirement of X.509, but 
is a much more recent operational development as you say below.)

  with
> anyEKU specifically disallowed. Since I would presume that any SOA
> would require both of these, and RFC5280 processing rules prohibit
> relying party applications from allowing a certificate for a purpose
> that is not allowed by the EKU value, I still don't see how this
> would help?
>
>> I've not seen too many
>> You do the same as you propose with your extension. If the
>> certificate/assertion/claim (these are all synonymous conceptually)
>> is signed by an authority who has a PKC with the extension, then
>> the signer is authorised by the CA to issue
>> certs/assertions/claims. If no such extension exists in the
>> signer's PKC, then it is up to the relying party to determine who
>> the trusted attribute authorities are. What this extension
>> effectively does is remove the set of trusted AAs from the RP's
>> configured trust store, and replaces it with a trusted CA, and the
>> trusted CA then dynamically says who the trusted AAs are (by
>> inserting this extension in their PKCs).
>>
>
> Ok - but there is a difference between implementing a simple check
> for an OID value of an already understood extension, and implementing
> support for an extension that hitherto has not traditionally been
> understood.

I dont believe so. The code is essentially the same, looking for an OID 
in a certificate extension. The semantics come from the text that 
describe the OID, and those semantics are built into the code that 
executes after the OID has been found. And this code is the same for 
both extensions. (we implemented this many years ago).

  Furthermore, from what you included, this extension
> cannot be marked critical, which is not what is desired for the
> claimSigning EKU.

The distinction between critical and non-critical is actually not there 
for code that understands the extension. Both critical and non-critical 
extensions have to be obeyed if the RP understands the extension. The 
use of non-critical is there to help RPs that dont understand the 
extension and have other means of configuring in the trust e.g. through 
IDP meta-data. So I think making the extension critical is a negative 
aspect and is self defeating since it means that RPs that use IDP-meta 
data to configure in trust cannot work once the extension is marked 
critical. Thus non-critical seems to be the correct approach to me.

Furthermore the process of PKI checking is different to and separate 
from PMI checking. An RP has a signed assertion/claim/certificate that 
it needs to validate. If it has its own trust rules for which IDPs it 
trusts to issue which claims then it does not want or need the PKI to do 
this for it. All it requires from the PKI is assurance that the 
signature is from an IDP that it trusts. End of story. It does not need 
the PKI to tell it if the signer has used the correct key with the 
correct EKU in it. It has its own rules for this.

It appears to me that what the EKU is trying to do is implement the thin 
end of the authorisation wedge into the PKI authentication mechanism. 
But EKU is too blunt an instrument to implement PMI in.

>> i) who are the trusted AAs. ii) which attributes is each AA trusted
>> to issue iii) who can the AA issue these attributes to.
>>
>> attributes to anyone, the university of kent to issue student
>> attributes to anyone with a kent email address etc.
>>
>
> As I said in the draft, Federation Realm designation, and the marking
> of who is authorised as a Trust point (either CA or IDP) is out of
> scope for this ID.

Agreed. Doing authorisation is not part of a PKI. So draw the line at 
passing over the root of trust from the PKI to a PMI entity, and then 
leave the PMI to work out everything else.

regards

David

---

From: Peter Sylvester <[email-masked]>
Date: Tue, 31 Jul 2012 23:27:03 +0200

On 07/31/2012 11:02 PM, Sean Turner wrote:
> I'm confused how a vague definition of a claim lines up with the need for a specific EKU (from 
> Patrick's earlier message):
>
> You need a specific EKU to indicate you can sign a nebulous thing. What's the client going to 
> check to know whether it's signing a claim or not?
>
> spt

+1

---

From: Patrick Patterson <[email-masked]>
Date: Tue, 31 Jul 2012 22:11:11 -0400

Hi Sean,

We're currently working the definition of "claim" that we're going to use and have come up with:

"A signed claim is a set of attributes bound to a particular subject using a digital signature in a way that relying parties can make access or authorization decisions.  

The presence of the claimSigning EKU indicates that a CA has approved the certificate holder to sign claims for use within a specific community of interest (e.g., a Federation) according to the rules of that community. In other words, the holder of a certificate that asserts the claimSigning EKU can bind attributes to a subject for processing by a relying party "

What do people think about that?

We'll be further augmenting this definition with clearer examples, but the original one for use by an IDP is still my main target (Matt has his own which will be made clear in the updated draft :). We'll also be addressing a bit why the current status quo may not work for everyone (and may not continue to work for anyone if all certificates issued by major CAs that assert digSig and nonRep start having mandatory populated EKU values).

I'll talk to Stefan tomorrow, but I'm leaning towards withdrawing our spot on the Agenda tomorrow, until we can come up with a Draft that addresses the concerns posted. (There's also the matter that Matt's not here, and I've got to leave before PKIX tomorrow :(  )

Cheers,

Patrick.

On 2012-07-31, at 5:02 PM, Sean Turner wrote:

> I'm confused how a vague definition of a claim lines up with the need for a specific EKU (from Patrick's earlier message):
> 
> You need a specific EKU to indicate you can sign a nebulous thing. What's the client going to check to know whether it's signing a claim or not?
> 
> spt
> 

---
Patrick Patterson
President and Chief PKI Architect
Carillon Information Security Inc.
http://www.carillon.ca

tel: +1 514 485 0789
mobile: +1 514 994 8699
fax: +1 450 424 9559