Subject: [Drip] terminology: certificates & claims

From: "Stuart W. Card" <[email-masked]>
Date: Wed, 28 Oct 2020 01:24:40 -0400

Some confusion in our discussions appears to have arisen from loose use 
of the terms "certificate" and "claim". As there will be discussions 
involving both tomorrow, I would like to state my understanding of them, 
which I am willing to revise if someone can authoritatively correct me.

(1) Certificates and claims are not the same thing, but are related.

(2) Claims are often a binding of the form "A is B", "A is of type B", 
"A has property B", "A owns B", etc.

(3) Certificates consist of one or more claims, plus some evidence 
supporting those claims, typically a signature of a trusted [third] 
party attesting to the truth of the claims.

(4) Claims can be signed by the claimant rather than a third party, 
which technically still constitutes a certificate; but typically the 
term certificate is reserved for claims signed by a third party rather 
than the claimant.

(5) Claims signed by the claimant thus generally depend upon a separate 
certificate, signed by a trusted third party, attesting that the public 
key of the claimant is indeed associated with that particular claimant, 
and perhaps that the claimant has been registered, vetted, etc.

(6) Claims can be made self-contained, not requiring reference to a 
separate certificate as in 5 above, by embedding the latter certificate 
in the claim.

My reference for this is the _Handbook of Applied Cryptography_, which 
does not state all of the above in those terms, but the above is my 
understanding of what it does say and my inferences therefrom.

Carsten? Michael? Anyone? Thanks!

-- 
-----------------------------------------
Stuart W. Card, PhD, Principal Engineer
AX Enterprize, LLC  www.axenterprize.com
4947 Commercial Drive, Yorkville NY 13495

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 28 Oct 2020 08:31:08 +0100

Hi Stu,

in an ideal world, that would be our terminology.

In practice, “certificate” is often understood as a shorthand for “X.509 certificate”.  These are in practice limited to a signed statement associating a public key (then used in some proof of possession for authentication) with some claims about the “holder” of that key (owner of the key pair); to add confusion, the key pair is often nebulously considered to be part of the “certificate” (“my certificate has been compromised”, “the TLS Diffie-Hellman public value is signed with the server’s certificate”, ...).

So when we started work on this area for the constrained space, we simply used “signed claims” for just that.  The downside is that it leaves the term “certificate” to the X.509 world, and since the industry has been hammered with the claim [sic] that only certificates provide security, this terminology is not entirely suit-proof.

Note that JWT (and thus CWT) also misuse the term “claim” to be a single attribute (key/value pair) of a claim in your sense.  So we have been using “assertion” to mean the whole thing (a set of JWT/CWT “claims” that together describe what is claimed — note that this may not be equivalent in semantics to a conjunction of assertions built from each of the individual JWT/CWT “claims”).

In summary, we have been drifting towards “assertions” and “signed assertions”; a (not very well-defined) subset of the latter can also be called “certificates”, and the individual components/attributes of a (signed) assertion are called “claims” as in JWT/CWT.

(Generally, we call what you call “claimant” the “subject” of the assertion, because “claimant” isn’t quite unambiguous on whether it is the one that states the claim [asserter], or the one that presents the claim for which it putatively is the holder but that is asserted by someone else (your “third party”).)

Grüße, Carsten

> On 2020-10-28, at 06:24, Stuart W. Card <[email-masked]> wrote:
> 
> Some confusion in our discussions appears to have arisen from loose use of the terms "certificate" and "claim". As there will be discussions involving both tomorrow, I would like to state my understanding of them, which I am willing to revise if someone can authoritatively correct me.
> 
> (2) Claims are often a binding of the form "A is B", "A is of type B", "A has property B", "A owns B", etc.
> 
> (3) Certificates consist of one or more claims, plus some evidence supporting those claims, typically a signature of a trusted [third] party attesting to the truth of the claims.
> 
> (4) Claims can be signed by the claimant rather than a third party, which technically still constitutes a certificate; but typically the term certificate is reserved for claims signed by a third party rather than the claimant.
> 
> (5) Claims signed by the claimant thus generally depend upon a separate certificate, signed by a trusted third party, attesting that the public key of the claimant is indeed associated with that particular claimant, and perhaps that the claimant has been registered, vetted, etc.
> 
> (6) Claims can be made self-contained, not requiring reference to a separate certificate as in 5 above, by embedding the latter certificate in the claim.
> 
> My reference for this is the _Handbook of Applied Cryptography_, which does not state all of the above in those terms, but the above is my understanding of what it does say and my inferences therefrom.
> 
> Tm-rid mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tm-rid

---

From: Henk Birkholz <[email-masked]>
Date: Wed, 28 Oct 2020 10:47:02 +0100

Hi Stu,
hi Carsten,

Carsten presented a spot-on illustration on why this can be so confusing 
sometimes.

In a nutshell:

Certificates are identity documents.
Identity documents are signed assertions including a pub-key (smallest 
identity document -> just a signed pub-key)
Possession of the corresponding private key now means something and 
supports a level of assurance wrt to authenticity.
Protection of the private key is therefore... key.

Trusting an identity document means to believe the signer of the 
identity document.

Hence, there can be certification paths (formerly known as certificate 
chains) from the identity document "up to" a trust anchor. In X.509 
these trust anchors are called CAs.

In general, Assertion and Claim are basically synonyms. X.1252 asserts:
"The terms assertion and claim are agreed to be very similar."

As Carsten pointed out, JWT introduced a discrepancy here. In IETF, a 
Claim means something different: key/value pair in an information model, 
or - looking at the JWT specification - also in the scope of a data model.

With respect to your list:

(1) Outside of the IETF, Claims can be seen as content of identity 
documents. Inside the IETF, Assertions are the content of identity 
documents, as the term Claims is repurposed a bit.

(2) Your examples look a bit more like Assertions than Claims (actually 
they look like Subject/Predicate/Object triples). Claims typically don't 
express a predicate - it can be implied by the subject (Claim label) though.

(3) The "proof of validity" must either be a conveyance method that uses 
a trusted channel or a signature for the identity document. The former 
is more common for generic "believable assertions" than identity 
documents, I think. In X.509 its always a signature.

(4) Not all signed assertions are identity documents / pub-key 
certificates. Signed assertions that include a pub-key are often misused 
as identity documents (although not being the origial intent)

(5) Apart from the Claimant / Asserter confusion, that sounds about right

(6) I assume you mean Claims set and not Claim value? In general, 
inclusion of an identity document of course is a substitute for 
referencing an identity document.

This is meant as a clarifying comment and not in any way meant as an 
exhaustive set of definitions! :-)

Viele Grüße,

Henk

---

From: Michael Richardson <[email-masked]>
Date: Wed, 28 Oct 2020 06:57:05 -0400

Stuart W. Card <[email-masked]> wrote:
    > (3) Certificates consist of one or more claims, plus some evidence supporting
    > those claims, typically a signature of a trusted [third] party attesting to
    > the truth of the claims.

What Carsten and Henk said.
I haven't seen
  "evidence supporting those claims"

in any actual (PKIX) certificates.  The point of the third party is usually
that it provides the service of evaluating the evidence, and this has, until
RFC8555 (ACME) been completely non-standard as to process.

    > Carsten? Michael? Anyone? Thanks!

Remember that it works best if you say our name three times in front of the
bathroom mirror.  :-)

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 28 Oct 2020 09:05:42 -0400

I have called the 84 byte Self-Claim a claim because it is basically a 
claim of ownership of the keypair.

But wait, it is also an assertion of the RAA|HDA as a source of more 
information about the entity...

And the Offline Self Claim is really a set of assertions.  It contains 
the HDA's assertion of registration of the entity with the HITT and HI, 
AND the entities assertion about owning the HHIT.

So from this it would seem I /should/ change my terminology to 
Self-Assertion and Offline-Self-Assertion.

Bob

On 10/28/20 5:47 AM, Henk Birkholz wrote:
> Hi Stu,
> hi Carsten,
>
> Carsten presented a spot-on illustration on why this can be so 
> confusing sometimes.
>
> In a nutshell:
>
> Claim means something different: key/value pair in an information 
> model, or - looking at the JWT specification - also in the scope of a 
> data model.
>
> (2) Your examples look a bit more like Assertions than Claims 
> (actually they look like Subject/Predicate/Object triples). Claims 
> typically don't express a predicate - it can be implied by the subject 
> (Claim label) though.
>
> (3) The "proof of validity" must either be a conveyance method that 
> uses a trusted channel or a signature for the identity document. The 
> former is more common for generic "believable assertions" than 
> identity documents, I think. In X.509 its always a signature.
>
> certificates. Signed assertions that include a pub-key are often 
> misused as identity documents (although not being the origial intent)
>
>> In practice, “certificate” is often understood as a shorthand for 
>> “X.509 certificate”.  These are in practice limited to a signed 
>> statement associating a public key (then used in some proof of 
>> possession for authentication) with some claims about the “holder” of 
>> that key (owner of the key pair); to add confusion, the key pair is 
>> often nebulously considered to be part of the “certificate” (“my 
>> certificate has been compromised”, “the TLS Diffie-Hellman public 
>> value is signed with the server’s certificate”, ...).
>>
>> So when we started work on this area for the constrained space, we 
>> simply used “signed claims” for just that.  The downside is that it 
>> leaves the term “certificate” to the X.509 world, and since the 
>> industry has been hammered with the claim [sic] that only 
>> certificates provide security, this terminology is not entirely 
>> suit-proof.
>>
>> Note that JWT (and thus CWT) also misuse the term “claim” to be a 
>> single attribute (key/value pair) of a claim in your sense. So we 
>> have been using “assertion” to mean the whole thing (a set of JWT/CWT 
>> “claims” that together describe what is claimed — note that this may 
>> not be equivalent in semantics to a conjunction of assertions built 
>> from each of the individual JWT/CWT “claims”).
>>
>> In summary, we have been drifting towards “assertions” and “signed 
>> assertions”; a (not very well-defined) subset of the latter can also 
>> be called “certificates”, and the individual components/attributes of 
>> a (signed) assertion are called “claims” as in JWT/CWT.
>>
>> (Generally, we call what you call “claimant” the “subject” of the 
>> assertion, because “claimant” isn’t quite unambiguous on whether it 
>> is the one that states the claim [asserter], or the one that presents 
>> the claim for which it putatively is the holder but that is asserted 
>> by someone else (your “third party”).)
>>
>> Grüße, Carsten
>>
>>> Some confusion in our discussions appears to have arisen from loose 
>>> use of the terms "certificate" and "claim". As there will be 
>>> discussions involving both tomorrow, I would like to state my 
>>> understanding of them, which I am willing to revise if someone can 
>>> authoritatively correct me.
>>>
>>> term certificate is reserved for claims signed by a third party 
>>> rather than the claimant.
>>>
>>> (5) Claims signed by the claimant thus generally depend upon a 
>>> separate certificate, signed by a trusted third party, attesting 
>>> that the public key of the claimant is indeed associated with that 
>>> particular claimant, and perhaps that the claimant has been 
>>> registered, vetted, etc.
>>>
>>> separate certificate as in 5 above, by embedding the latter 
>>> certificate in the claim.
>>>
>>> My reference for this is the _Handbook of Applied Cryptography_, 
>>> which does not state all of the above in those terms, but the above 
>>> is my understanding of what it does say and my inferences therefrom.
>>>

---

From: <[email-masked]>
Date: Wed, 28 Oct 2020 11:50:38 -0400

Hello All,

Attached is a document that I created in connection with some identity work that I have been doing in the medical space. I created it because there was confusion about certain definitional terms across different standards and frameworks between the lawyers and the engineers.  I find this matrix is an interesting cheat sheet to make sure that everyone is operating from a common definitional framework.  

If the group finds any value I could expand the matrix to include some of the DRIP definitional terms.

Best regards,

Michael

-----Original Message-----
From: Tm-rid <[email-masked]> On Behalf Of Michael Richardson
Sent: Wednesday, October 28, 2020 6:57 AM
To: Stuart W. Card <[email-masked]>; [email-masked]
Subject: Re: [Drip] terminology: certificates & claims

in any actual (PKIX) certificates.  The point of the third party is usually that it provides the service of evaluating the evidence, and this has, until
RFC8555 (ACME) been completely non-standard as to process.

    > Carsten? Michael? Anyone? Thanks!

Remember that it works best if you say our name three times in front of the bathroom mirror.  :-)

---

From: Henk Birkholz <[email-masked]>
Date: Wed, 28 Oct 2020 16:57:42 +0100

Hi Michael,

a very preliminary observation:

This table could definitely use an RFC4949 (or IETF, but that is way 
more effort) column.

Viele Grüße,

Henk

p.s. as a hint - Claim, Relying Party, and Verifier are used extensively 
in the RATS WG:

---

From: <[email-masked]>
Date: Wed, 28 Oct 2020 12:02:06 -0400

Henk,

Totally agree the matrix needs to be extended.  My original choice was based upon some of the internal discussion within the medical community. I just found out that the matrix helped steer the discussion and provided a nice internal document for the engineers that were focused on standards and the lawyers that were focused on national laws.

If others see potential benefit, I would be open to adding a RFC4949 column and a DRIPs column. 

Best regards,

Michael

-----Original Message-----
From: Henk Birkholz <[email-masked]> 
Sent: Wednesday, October 28, 2020 11:58 AM
To: [email-masked]; 'Michael Richardson' <[email-masked]>; 'Stuart W. Card' <[email-masked]>; [email-masked]
Subject: Re: [Drip] terminology: certificates & claims

Hi Michael,

This table could definitely use an RFC4949 (or IETF, but that is way more effort) column.

Viele Grüße,

Henk

p.s. as a hint - Claim, Relying Party, and Verifier are used extensively in the RATS WG:

---

From: "Card, Stu" <[email-masked]>
Date: Wed, 28 Oct 2020 13:22:54 -0400

I hate to chime in agreeing that anyone (myself or another) should do
additional work, but if you have the cycles, it should be a useful
reference for authors and editors.

On Wed, Oct 28, 2020 at 12:02 PM <[email-masked]> wrote:

> Henk,
>
> Totally agree the matrix needs to be extended.  My original choice was
> based upon some of the internal discussion within the medical community. I
> just found out that the matrix helped steer the discussion and provided a
> nice internal document for the engineers that were focused on standards and
> the lawyers that were focused on national laws.
>
> To: [email-masked]; 'Michael Richardson' <[email-masked]>;
> 'Stuart W. Card' <[email-masked]>; [email-masked]
> > Attached is a document that I created in connection with some identity
> work that I have been doing in the medical space. I created it because
> there was confusion about certain definitional terms across different
> standards and frameworks between the lawyers and the engineers.  I find
> this matrix is an interesting cheat sheet to make sure that everyone is
> operating from a common definitional framework.
> >
> > in any actual (PKIX) certificates.  The point of the third party is
> usually that it provides the service of evaluating the evidence, and this
> has, until