Re: [icnrg] recursive key Lookup in CCNX

[Ken Calvert <[e-mail]>]

Marc -

> I wanted to follow-up on list with some discussions Ken and I have had in private.

Thanks for clarifying things for me.  I do understand the constraint more precisely now, and (I think) the reasoning behind it.  Part of my dismay was because I worry that requiring trust to be characterized through X.509 certificates would lead to reliance on existing web PKI, which IMO would not be a good outcome - though obviously opinions on that may vary.

Thanks also for clarifying the ways to do what I wanted to do, for example by defining new fields, as you describe below.

Ken

> One of the goals we had in writing 8569 / 8609 is for a given field perform only one job.  It should be clear what a KeyLink is and how to interpret it, just like other fields.  At times in CCNx 0.x, one field would be interpreted one way in one context (often implied by the publisher or based on external data) and interpreted another way in another context.
> 
> In the case of recursive key lookup to validate signatures, the processing would go something like this:
> 
> 1.	Content object O1 has signature S1 with keyid K1 and a KeyLink to name N2.  A verifier without a corresponding public key to K1 would need to fetch N2 to verify the signature S1.
> 2.	Content object O2 with name N2 has a signature S2 with keyed K1 and a payload of a certificate C1 that wraps public key with keyid K1.  The verifier in step 1 now has the public key that it can verify matches K1 and verifies signature S1.  It is done.  Trust is a separate issue from mechanical verification of the signature.
> 3.	In CCNx 0.x, content object O2 usually continued with another KeyLink (called KeyLocator back then) to the certificate of the signer of C1 to establish the trust chain.  This second KeyLink in the ValidationAlogrithm section (to use current terms) is not used to verify a ValidationAlogirthm signature, but to establish trust by fetching the next step in the certificate chain of C1.  The retrieved content object would not be used to verify the signature of O2, but a completely different purpose.
> 
> If one were to propose a trust mechanism that uses a field in the ValidationAlgorithm section to fetch the next certificate in a chain, one  should make a new field, for example CertificateChainLink, for that purpose.  The KeyLink is to verify a signature, the CertificateChainLink is to fetch an issuer’s certificate.
> 
> Another possibility is to use the Issuer Alternative Name to embed a URI in the certificate with a ccnx: schema link rather than use an external field CertificateChainLink.
> 
> If one were to develop a CCNx-native certificate, rather than using X.509, based on the ValidationAlgorithm, I think one would likely define additional ValidationDependentData, like CertificateChainLink, to realize that structure -- or even use a more flexible mechanism like SPKI/SDSI or newer mechanisms that can transfer the whole trust chain digests at once.
> 
> Marc
>