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

From: David Chadwick <[email-masked]>
Date: Wed, 01 Aug 2012 12:26:33 +0100

Hi Patrick

one problem  see with this is as follows

The RP typically gives a binary blob to the PKI and asks it to validate 
the signature on the binary blob. The PKI has no knowledge about the 
semantic content of this blob. So it cannot tell the difference between 
a SAML assertion, OpenID assertion, Oauth assertion, Word document, or a 
love letter.

I dont think we should be building this sort of semantics into signature 
verification.

regards

David

On 01/08/2012 03:11, Patrick Patterson wrote:
> 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):
>>
>>   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
>>
>> On 7/31/12 10:55 AM, Stefan Santesson wrote:
>>> 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
>>>
>>>
>>>
>>>
>>> On 12-07-31 10:37 AM, "David A. Cooper" <[email-masked]> wrote:
>>>
>>>> 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_comme
>>>> nts_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
>>>>
>>>> On 07/30/2012 03:04 PM, Stefan Santesson wrote:
>>>>> 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
>>>
>>>
>>> _______________________________________________
>>> pkix mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/pkix
>>>
>> _______________________________________________
>> pkix mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/pkix
>
> ---
> 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
>
>
>
>
>
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix
>

---

From: Patrick Patterson <[email-masked]>
Date: Wed, 1 Aug 2012 09:47:16 -0400

Hi David,

I'm not at all sure what you are talking about - I've never seen a world where an RP gives anything to the PKI to verify - it usually (when it is well behaved) extracts the certificate (after making sure that the public key in the cert is the same that was used to sign the message) and does RFC5280 Section 6 validation on it, or at least makes sure this Certificate chains to a Trust Anchor that it has pre-configured. This is all done on the RP itself. The RP knows the semantics of the message that it has, and presumably (in the case of SAML) knows who the authorised IDPs are (which may include, in this case, checking to see if the claimSigning EKU is present).

I'm not asking for, or saying anything about signature semantics - Stefan and Sean wanted a definition of a claim to be used when asserting the "claimSigning" EKU, and I gave it to them.

Cheers,

Patrick.

On 2012-08-01, at 7:26 AM, David Chadwick wrote:

> The RP typically gives a binary blob to the PKI and asks it to validate the signature on the binary blob. The PKI has no knowledge about the semantic content of this blob. So it cannot tell the difference between a SAML assertion, OpenID assertion, Oauth assertion, Word document, or a love letter.
> 
> I dont think we should be building this sort of semantics into signature verification.
> 
> regards
> 
> David
> 
> 

---
Patrick Patterson

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

---

From: David Chadwick <[email-masked]>
Date: Wed, 01 Aug 2012 16:50:48 +0100

Hi Patrick

I am talking from the perspective of the RP which, in the case of SAML,
would be the SAML SP, which has received a SAML assertion which it needs 
to verify.

On 01/08/2012 14:47, Patrick Patterson wrote:
> Hi David,
>
> I'm not at all sure what you are talking about - I've never seen a
> world where an RP gives anything to the PKI to verify - it usually
> (when it is well behaved) extracts the certificate (after making sure
> that the public key in the cert is the same that was used to sign the
> message)  and does RFC5280 Section 6 validation on it, or at least
> makes sure this Certificate chains to a Trust Anchor that it has
> pre-configured.

In my opinion this is part of the PKI validation, not the PMI validation 
(section 6 is entitled certification path validation). The PKI roots of 
trust are configured into the PKI, not the PMI. The PMI would only have 
one or more PKI roots of trust configured into it, if it did not know 
who its trusted IDPs were, and was relying on the PKI to tell it.

This is all done on the RP itself.

the RP is the SAML IDP in the case of SAML assertions. It is relying on 
the PKI to validate the signatures on the signed messages (SAML 
assertions) that it receives.

  The RP knows the
> semantics of the message that it has, and presumably (in the case of
> SAML) knows who the authorised IDPs are (which may include, in this
> case, checking to see if the claimSigning EKU is present).

If the RP already knows who the trusted IDPs are, then there is no point 
in having the EKU field. All that is important is that the assertion is 
signed by the IDP, regardless of which key or certificate it used. The 
SAML SP should be insulated from the IDP migrating between keys and 
certificates - let the PKI component take care of this. I know that 
today's implementations pass around certificates in meta-data, but I 
regard this is as deficiency in trust validation.

regards

David

>
> I'm not asking for, or saying anything about signature semantics -
> Stefan and Sean wanted a definition of a claim to be used when
> asserting the "claimSigning" EKU, and I gave it to them.
>
> Cheers,
>
> Patrick.
>
>> The RP typically gives a binary blob to the PKI and asks it to
>> validate the signature on the binary blob. The PKI has no knowledge
>> about the semantic content of this blob. So it cannot tell the
>> difference between a SAML assertion, OpenID assertion, Oauth
>> assertion, Word document, or a love letter.
>>
>>> "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 "
>>>
>>> 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.
>>>
>>>> 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
>>>>
>>>>> 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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> 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
>>>>>> 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
>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>> 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
>>>>>
>>>>>
>>>>> _______________________________________________ pkix mailing
>>>>> list [email-masked]
>>>> _______________________________________________ pkix mailing
>>>> list [email-masked] https://www.ietf.org/mailman/listinfo/pkix
>>>
>>> --- 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
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________ pkix mailing
>>> list [email-masked] https://www.ietf.org/mailman/listinfo/pkix
>>>
>
> --- 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
>
>
>
>
>

---

From: Peter Rybar <[email-masked]>
Date: Wed, 1 Aug 2012 13:47:30 +0200

Hi,

The contentHint in CMS can be used for processing type identification
of signed binary blob

Attribute SEQUENCE {
  attrType OBJECT IDENTIFIER 1.2.840.113549.1.9.16.2.4 id-aa-contentHint
  attrValues SET {
   ContentHints SEQUENCE {
    contentDescription UTF8String ‘MIME-Version: 1.0
      Content-Type: text/plain; charset=UTF-8; name="Document.txt"
      Content-Disposition: attachment; filename="Document.txt"‘
    contentType OBJECT IDENTIFIER 1.2.840.113549.1.7.1 id-data
   }
  }
}

Interoperability profile...
http://www.nbusr.sk/en/electronic-signature/verification.1.html

Peter

2012/8/1 David Chadwick <[email-masked]>:
> The RP typically gives a binary blob to the PKI and asks it to validate the
> signature on the binary blob. The PKI has no knowledge about the semantic
> content of this blob. So it cannot tell the difference between a SAML
> assertion, OpenID assertion, Oauth assertion, Word document, or a love
> letter.
>
>> "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 "
>>
>> 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.
>>
>>> 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
>>>

---

From: Trevor Freeman <[email-masked]>
Date: Wed, 1 Aug 2012 17:50:41 +0000

David,

I am somewhat baffled by your comment. There is a long precedence for refining the sign semantics of the key used extension via the eku extension to express sign what. We have signed code, signed documents, signed revocation responses eku purposes. The whole purpose of the EKU extension was to enable this kind of expression. The RP absolutely understands if it is processing claims so can filter based on EKU.
We should not be inventing new semantics for different kinds of signing.

Trevor
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of David Chadwick
Sent: Wednesday, August 01, 2012 8:51 AM
To: Patrick Patterson
Cc: [email-masked] PKIX
Subject: Re: [pkix] Updated claimSigning EKU Internet Draft

Hi Patrick

I am talking from the perspective of the RP which, in the case of SAML, would be the SAML SP, which has received a SAML assertion which it needs to verify.

> makes sure this Certificate chains to a Trust Anchor that it has 

In my opinion this is part of the PKI validation, not the PMI validation (section 6 is entitled certification path validation). The PKI roots of trust are configured into the PKI, not the PMI. The PMI would only have one or more PKI roots of trust configured into it, if it did not know who its trusted IDPs were, and was relying on the PKI to tell it.

the RP is the SAML IDP in the case of SAML assertions. It is relying on the PKI to validate the signatures on the signed messages (SAML
assertions) that it receives.

  The RP knows the
> case, checking to see if the claimSigning EKU is present).

If the RP already knows who the trusted IDPs are, then there is no point in having the EKU field. All that is important is that the assertion is signed by the IDP, regardless of which key or certificate it used. The SAML SP should be insulated from the IDP migrating between keys and certificates - let the PKI component take care of this. I know that today's implementations pass around certificates in meta-data, but I regard this is as deficiency in trust validation.

regards

David

>>> "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.
>>>
>>> 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 "
>>>
>>> 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).
>>>
>>> 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.
>>>
>>>> I'm confused how a vague definition of a claim lines up with the 
>>>> need for a specific EKU (from Patrick's earlier message):
>>>>
>>>> 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
>>>>
>>>>> 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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> 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 
>>>>>> 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
>>>>>>
>>>>>>> 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.
>>>>>>> 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.
>>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>> 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. 
>>>>> _______________________________________________ pkix mailing list 
>>>>> [email-masked] https://www.ietf.org/mailman/listinfo/pkix
>>>>>
>>>> _______________________________________________ pkix mailing list 
>>>> [email-masked] https://www.ietf.org/mailman/listinfo/pkix
>>>
>>> _______________________________________________ pkix mailing list 
>>> [email-masked] https://www.ietf.org/mailman/listinfo/pkix
>>>
>

---

From: David Chadwick <[email-masked]>
Date: Wed, 01 Aug 2012 21:34:51 +0100

Hi Trevor

there is one big difference in all these cases your mention and that of
a PMI claim which I mention, namely, the RPs are either all applications 
(signed code, signed documents) or PKI components (revocation) that are 
using the PKI to validate its signed documents. Thus the PKI is the 
*only* security component the RP is relying on, whilst in the case of 
validating a PMI claim, the PMI is actually part of the security 
infrastructure itself (on a par with the PKI). Thus the PMI does not 
need to rely on the PKI to the same extent as the other components. It 
is fully capable of validating its own trust chains. The PMI forms a 
parallel infrastructure to the PKI.

regards

David

On 01/08/2012 18:50, Trevor Freeman wrote:
> David,
>
> I am somewhat baffled by your comment. There is a long precedence for
> refining the sign semantics of the key used extension via the eku
> extension to express sign what. We have signed code, signed
> documents, signed revocation responses eku purposes. The whole
> purpose of the EKU extension was to enable this kind of expression.
> The RP absolutely understands if it is processing claims so can
> filter based on EKU. We should not be inventing new semantics for
> different kinds of signing.
>
> Trevor -----Original Message----- From: [email-masked]
> [mailto:[email-masked]] On Behalf Of David Chadwick Sent:
> Wednesday, August 01, 2012 8:51 AM To: Patrick Patterson Cc:
> [email-masked] PKIX Subject: Re: [pkix] Updated claimSigning EKU
> Internet Draft
>
> Hi Patrick
>
> I am talking from the perspective of the RP which, in the case of
> SAML, would be the SAML SP, which has received a SAML assertion which
> it needs to verify.
>
>> (when it is well behaved) extracts the certificate (after making
>> sure that the public key in the cert is the same that was used to
>> sign the message)  and does RFC5280 Section 6 validation on it, or
>> at least makes sure this Certificate chains to a Trust Anchor that
>> it has pre-configured.
>
> In my opinion this is part of the PKI validation, not the PMI
> validation (section 6 is entitled certification path validation). The
> PKI roots of trust are configured into the PKI, not the PMI. The PMI
> would only have one or more PKI roots of trust configured into it, if
> it did not know who its trusted IDPs were, and was relying on the PKI
> to tell it.
>
> the RP is the SAML IDP in the case of SAML assertions. It is relying
> on the PKI to validate the signatures on the signed messages (SAML
>> semantics of the message that it has, and presumably (in the case
>> of SAML) knows who the authorised IDPs are (which may include, in
>> this case, checking to see if the claimSigning EKU is present).
>
> If the RP already knows who the trusted IDPs are, then there is no
> point in having the EKU field. All that is important is that the
> assertion is signed by the IDP, regardless of which key or
> certificate it used. The SAML SP should be insulated from the IDP
> migrating between keys and certificates - let the PKI component take
> care of this. I know that today's implementations pass around
> certificates in meta-data, but I regard this is as deficiency in
> trust validation.
>
> regards
>
> David
>
>
>>
>>> validate the signature on the binary blob. The PKI has no
>>> knowledge about the semantic content of this blob. So it cannot
>>> tell the difference between a SAML assertion, OpenID assertion,
>>> Oauth assertion, Word document, or a love letter.
>>>
>>>> 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 "
>>>>
>>>> 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.
>>>>
>>>>> 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.
>>>>>
>>>>>> need to be one. Absent a definition, the EKU becomes
>>>>>> somewhat pointless as usage declaration.
>>>>>>
>>>>>> /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.
>>>>>>>
>>>>>>> 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
>>>>>>> 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-20
>>>>>>>
>>>>>>>
1-2_comme
>>>>>>>> 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.
>>>>>>>>
>>>>>>>> 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
>>>>>>
>>>>>>
>>>>>> _______________________________________________ pkix
>>>>>> mailing list [email-masked]
>>>> --- Patrick Patterson President and Chief PKI Architect
>>>> Carillon Information Security Inc. http://www.carillon.ca
>>>>

---

From: Patrick Patterson <[email-masked]>
Date: Wed, 1 Aug 2012 16:59:48 -0400

Hello David,

I think that your assumption only works in the case where the PMI operates their own CA (that signs only Metadata and/or IDP certificates). 

In a couple of cases that I am aware of, the same CA that issues Identity Certificates, general Purpose Device Certificates, there is a desire issue IDP Certs, and distinguish these from general purpose Device certificates. 

Furthermore, IDPs may be part of a dynamic Federation (it is sufficient to be part of the same PKI Community - we're treating Attribute Assurance separately), and therefore there IS no metadata. Consequently, the PMI and the PKI may be part of the same Trust Infrastructure, and therefore are not considered independent.

There are many models for Federation that are emerging, and we need to have a way to support these.

Cheers,

Patrick.

On 2012-08-01, at 4:34 PM, David Chadwick wrote:

> a PMI claim which I mention, namely, the RPs are either all applications (signed code, signed documents) or PKI components (revocation) that are using the PKI to validate its signed documents. Thus the PKI is the *only* security component the RP is relying on, whilst in the case of validating a PMI claim, the PMI is actually part of the security infrastructure itself (on a par with the PKI). Thus the PMI does not need to rely on the PKI to the same extent as the other components. It is fully capable of validating its own trust chains. The PMI forms a parallel infrastructure to the PKI.
> 
> regards
> 
> David
> 

---
Patrick Patterson

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

---

From: Trevor Freeman <[email-masked]>
Date: Wed, 1 Aug 2012 21:40:41 +0000

Hi David,

The message I hear loud and clear from organization is their pain due to escalating management cost because so many technologies are management stove pipes. So while most of us are trying to find ways to make management shared across applications,  hear you are suggesting this is a good thing.
If it looks like a pkix certificate, smells like a pkix certificate it should be managed like a pkix certificate. 
Trevor

-----Original Message-----
From: David Chadwick [mailto:[email-masked]] 
Sent: Wednesday, August 01, 2012 1:35 PM
To: Trevor Freeman
Cc: Patrick Patterson; [email-masked] PKIX
Subject: Re: [pkix] Updated claimSigning EKU Internet Draft

Hi Trevor

there is one big difference in all these cases your mention and that of a PMI claim which I mention, namely, the RPs are either all applications (signed code, signed documents) or PKI components (revocation) that are using the PKI to validate its signed documents. Thus the PKI is the
*only* security component the RP is relying on, whilst in the case of validating a PMI claim, the PMI is actually part of the security infrastructure itself (on a par with the PKI). Thus the PMI does not need to rely on the PKI to the same extent as the other components. It is fully capable of validating its own trust chains. The PMI forms a parallel infrastructure to the PKI.

regards

David

1-2_comme

---

From: David Chadwick <[email-masked]>
Date: Wed, 01 Aug 2012 23:40:21 +0100

Hi Patrick

On 01/08/2012 21:59, Patrick Patterson wrote:
> Hello David,
>
> I think that your assumption only works in the case where the PMI
> operates their own CA (that signs only Metadata and/or IDP
> certificates).

Absolutely not. PMIs should always be designed to work with general 
purpose PKIs and software (e.g. we use bouncy castle in our PMI).

>
> In a couple of cases that I am aware of, the same CA that issues
> Identity Certificates, general Purpose Device Certificates, there is
> a desire issue IDP Certs, and distinguish these from general purpose
> Device certificates.

"there is a desire" by whom? The CA operator? The federation operator? 
The RP/SP? The PMI?

>
> Furthermore, IDPs may be part of a dynamic Federation (it is
> sufficient to be part of the same PKI Community - we're treating
> Attribute Assurance separately), and therefore there IS no metadata.

Fine, I like that model much better. Metadata harks back to pre-DNS days 
when sites used to be email the name-address mappings nightly. You would 
have thought that federations would have learnt from that experience 
that using metadata does not scale well. (The UK Access Federation has 
belatedly found this out).

> Consequently, the PMI and the PKI may be part of the same Trust
> Infrastructure, and therefore are not considered independent.

They are always independent. Just as authn is separate from authz, trust 
in who issues claims is independent from who issues PKCs. Mixing them 
together is a big mistake. (this does not mean that the same entity 
cannot be trusted to do both, but logically they are separate roles)

regards

David

>> there is one big difference in all these cases your mention and
>> that of a PMI claim which I mention, namely, the RPs are either all
>> applications (signed code, signed documents) or PKI components
>> (revocation) that are using the PKI to validate its signed
>> documents. Thus the PKI is the *only* security component the RP is
>> relying on, whilst in the case of validating a PMI claim, the PMI
>> is actually part of the security infrastructure itself (on a par
>> with the PKI). Thus the PMI does not need to rely on the PKI to the
>> same extent as the other components. It is fully capable of
>> validating its own trust chains. The PMI forms a parallel
>> infrastructure to the PKI.
>>
>> regards
>>
>> David
>>
>>> I am somewhat baffled by your comment. There is a long precedence
>>> for refining the sign semantics of the key used extension via the
>>> eku extension to express sign what. We have signed code, signed
>>> purpose of the EKU extension was to enable this kind of
>>> expression. The RP absolutely understands if it is processing
>>> claims so can filter based on EKU. We should not be inventing new
>>> semantics for different kinds of signing.
>>>
>>> I am talking from the perspective of the RP which, in the case
>>> of SAML, would be the SAML SP, which has received a SAML
>>> assertion which it needs to verify.
>>>
>>>> I'm not at all sure what you are talking about - I've never
>>>> seen a world where an RP gives anything to the PKI to verify -
>>>> it usually (when it is well behaved) extracts the certificate
>>>> (after making sure that the public key in the cert is the same
>>>> that was used to sign the message)  and does RFC5280 Section 6
>>>> validation on it, or at least makes sure this Certificate
>>>> chains to a Trust Anchor that it has pre-configured.
>>>
>>> validation (section 6 is entitled certification path validation).
>>> The PKI roots of trust are configured into the PKI, not the PMI.
>>> The PMI would only have one or more PKI roots of trust configured
>>> into it, if it did not know who its trusted IDPs were, and was
>>> relying on the PKI to tell it.
>>>
>>> the RP is the SAML IDP in the case of SAML assertions. It is
>>> relying on the PKI to validate the signatures on the signed
>>> messages (SAML assertions) that it receives.
>>>
>>> The RP knows the
>>>> semantics of the message that it has, and presumably (in the
>>>> case of SAML) knows who the authorised IDPs are (which may
>>>> include, in this case, checking to see if the claimSigning EKU
>>>> is present).
>>>
>>> If the RP already knows who the trusted IDPs are, then there is
>>> no point in having the EKU field. All that is important is that
>>> the assertion is signed by the IDP, regardless of which key or
>>> certificate it used. The SAML SP should be insulated from the
>>> IDP migrating between keys and certificates - let the PKI
>>> component take care of this. I know that today's implementations
>>> pass around certificates in meta-data, but I regard this is as
>>> deficiency in trust validation.
>>>
>>> regards
>>>
>>> David
>>>
>>>
>>>>
>>>> I'm not asking for, or saying anything about signature
>>>> semantics - Stefan and Sean wanted a definition of a claim to
>>>> be used when asserting the "claimSigning" EKU, and I gave it to
>>>> them.
>>>>
>>>> Cheers,
>>>>
>>>> Patrick.
>>>>
>>>>> The RP typically gives a binary blob to the PKI and asks it
>>>>> to validate the signature on the binary blob. The PKI has no
>>>>> knowledge about the semantic content of this blob. So it
>>>>> cannot tell the difference between a SAML assertion, OpenID
>>>>> assertion, Oauth assertion, Word document, or a love letter.
>>>>>
>>>>>> 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 "
>>>>>>
>>>>>> 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).
>>>>>>
>>>>>> 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
>>>>>>> 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
>>>>>>>
>>>>>>>> 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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> 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
>>>>>>>>> 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
1-2_comme
>>>>>>>>> asking that FIPS 201 specify the use of the
>>>>>>>>> claimSigning OID being discussed in the PKIX WG
>>>>>>>>> rather than (or in addition to) the
>>>>>>>>>> 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
>>>>>>>>>> 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
>>>>>>>>>> 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
>>>>>>>>
>>>>>>>>

---

From: Patrick Patterson <[email-masked]>
Date: Wed, 1 Aug 2012 19:14:19 -0400

Hello David,

On 2012-08-01, at 6:40 PM, David Chadwick wrote:

> Absolutely not. PMIs should always be designed to work with general purpose PKIs and software (e.g. we use bouncy castle in our PMI).
> 

General Purpose PKIs != PKI Products - I mean a PKI (regardless of product, and meaning a collection of technology and processes that enforce a policy regarding the binding of credentials to people and things) that is used for every function in a given corporation / community - including producing certificates for Identity of users (used to log into web sites, VPNs, physical facilities, etc.), Signature certificates to sign documents/data/etc., Encryption Certificates to facilitate data security, Code Signing Certificates stating that a given individual or organisation is allowed to sign trusted code, Device Certificate used to provide identity assurance for web sites, etc. Device Signature Certificates to prove origination of Data from an automated Data source, etc., and now Device Certificates that say that a given site is authorised to Sign "claims". 

The products used to issue these Certificates should no have bearing on this discussion, nor do the products used to consume or validate the certificates. We don't make a distinction between Thunderbird (which deals in Email) and LibNSS (which resolves certificate Trust) - why should we distinguish between ADFS and CAPI (or whatever your Federation product is and the underlying library that evaluates trust) - they are (from a high level, user-oriented standpoint) indistinguishable - unless they both work, the result is useless. As Trevor said - the stovepiping of terminology that is currently happening is only causing confusion and problems with comprehension in the folks that want to deploy this.

> "there is a desire" by whom? The CA operator? The federation operator? The RP/SP? The PMI?
> 

The companies that have invested heavily in PKI. They are the CA Operator, the RP and the Federation Operator, all at the same time. The PMI is a community agreed Arbiter of Federation Trust, of which the companies involved MAY be a part owner.

> Fine, I like that model much better. Metadata harks back to pre-DNS days when sites used to be email the name-address mappings nightly. You would have thought that federations would have learnt from that experience that using metadata does not scale well. (The UK Access Federation has belatedly found this out).
> 

Agreed.

> They are always independent. Just as authn is separate from authz, trust in who issues claims is independent from who issues PKCs. Mixing them together is a big mistake. (this does not mean that the same entity cannot be trusted to do both, but logically they are separate roles)
> 

Well, no - there is no reason why a PMI and a PKI Bridge operator have to be separate - they provide the same function - arbitrating Trust between organisations - the only difference is a semantic one that a PMA (A PKI is simply the entirety of stuff that carries out the will of a PMA) deals in Identity Trust, and a PMI deals in Attribute Trust.

Cheers,

---
Patrick Patterson
Chief PKI Architect

---

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

Hi Patrick

It seems that we do not share a common viewpoint. I say that PKI and PMI 
are separate functions and that an AA and CA are separate roles, but the 
same entity can act in both roles. However you said they provide the 
same function. I should like you to justify this, and perhaps you can 
use as an example a university AA which issues degree attributes and a 
CA which issues PKCs.

regards

David

On 02/08/2012 00:14, Patrick Patterson wrote:
>>> I think that your assumption only works in the case where the
>>> PMI operates their own CA (that signs only Metadata and/or IDP
>>> certificates).
>>
> General Purpose PKIs != PKI Products - I mean a PKI (regardless of
> product, and meaning a collection of technology and processes that
> enforce a policy regarding the binding of credentials to people and
> things) that is used for every function in a given corporation /
> community - including producing certificates for Identity of users
> (used to log into web sites, VPNs, physical facilities, etc.),
> Signature certificates to sign documents/data/etc., Encryption
> Certificates to facilitate data security, Code Signing Certificates
> stating that a given individual or organisation is allowed to sign
> trusted code, Device Certificate used to provide identity assurance
> for web sites, etc. Device Signature Certificates to prove
> origination of Data from an automated Data source, etc., and now
> Device Certificates that say that a given site is authorised to Sign
> "claims".
>
> The products used to issue these Certificates should no have bearing
> on this discussion, nor do the products used to consume or validate
> the certificates. We don't make a distinction between Thunderbird
> (which deals in Email) and LibNSS (which resolves certificate Trust)
> - why should we distinguish between ADFS and CAPI (or whatever your
> Federation product is and the underlying library that evaluates
> trust) - they are (from a high level, user-oriented standpoint)
> indistinguishable - unless they both work, the result is useless. As
> Trevor said - the stovepiping of terminology that is currently
> happening is only causing confusion and problems with comprehension
> in the folks that want to deploy this.
>
>
>>>
>>> Identity Certificates, general Purpose Device Certificates, there
>>> is a desire issue IDP Certs, and distinguish these from general
>>> purpose Device certificates.
>>
> The companies that have invested heavily in PKI. They are the CA
> Operator, the RP and the Federation Operator, all at the same time.
> The PMI is a community agreed Arbiter of Federation Trust, of which
> the companies involved MAY be a part owner.
>
>>>
>> Fine, I like that model much better. Metadata harks back to pre-DNS
>> days when sites used to be email the name-address mappings nightly.
>> You would have thought that federations would have learnt from that
>> experience that using metadata does not scale well. (The UK Access
>> Federation has belatedly found this out).
>>
>
> Agreed.
>
>>
>> They are always independent. Just as authn is separate from authz,
>> trust in who issues claims is independent from who issues PKCs.
>> Mixing them together is a big mistake. (this does not mean that the
>> same entity cannot be trusted to do both, but logically they are
>> separate roles)
>>
>
> Well, no - there is no reason why a PMI and a PKI Bridge operator
> have to be separate - they provide the same function - arbitrating
> Trust between organisations - the only difference is a semantic one
> that a PMA (A PKI is simply the entirety of stuff that carries out
> the will of a PMA) deals in Identity Trust, and a PMI deals in
> Attribute Trust.
>
> Cheers,
>
> --- Patrick Patterson Chief PKI Architect Carillon Information
> Security Inc. http://www.carillon.ca
>
>
>
>
>