Re: [stir] Questions on the draft-ietf-stir-passport-rcd-04 integrity mechanism

[Ben Campbell <[e-mail]>]

Hi Chris,


Please see inline.

Also, I forgot one comment unrelated to the integrity mechanism: in section 5.1, the wikimedia folks would probably appreciate it we do not include a link to content hosted there in an example in an RFC :-)

Thanks!

Ben.

> On Sep 9, 2019, at 2:02 PM, Chris Wendt <[e-mail]> wrote:
> 
> Hi Ben,
> 
> For 1, simple answer is yes the intention was to make the content tied to the cert.  My experience is that calling name and other info is not changed often, however, assuming your premise, why would that be a problem?  If you want to be changing your RCD info once a year, once a month, or once a day then why is it a problem to push everything through the integrity mechanism and generate a new cert each time?  I think this is pretty logical.  If you don’t do that, what is the alternative to keep the properties of integrity of the information protected by a signature?

I agree that tying the content to the cert makes sense for some use cases where there is a content policy “authority” either as part of the CA, or that easily fits in the workflow for issuing the cert (perhaps via some ACME-ish token) But I think there will also be use cases where it does not. In particular, cases where either there is no such authority, or the signer of the RCD PASSporT _is_ the authority.

For example, the policy authority could be a third-party signer as described in section 7. Why would such an authority need to tie content to the signing certificate? It would just make life more complicated for them. (I started to ask why a 3rd party signer would need the integrity mechanism at all, but perhaps they need to protect referenced content.).

I don’t object to having the _ability_ to tie content to the cert. But I think making that a MUST when using the integrity mechanism is too strong. I’d argue for a MAY, along with motivating text on why/when you might want to use it.

For similar reasons, I lean towards thinking the SHOULD for using the rcdi claim in the first place might be a bit strong. For example, it would serve little purpose in the third-party example above if the policy authority simply did not allow referenced content.

> 
> For 2, yes the intent was to iterate at each level of the URLs.  I suspect the number of nested URLs for most of the “common” cases, like name, logo and address, would be limited, but would need a framework that supports multiple levels of nesting or limit the number of levels or something if we are concerned.  I don’t think there is a lot of reason to be concerned but maybe i’m missing a case that would actually use a ton of nesting in any practical way.

If that is the intent, it needs to be clarified. I read 4.1.1 as iterating across all the URLs in the RCD input. I assume from your response that step 7 was intended to apply to retrieved content, but I initially assumed you mean to iterate over additionally identified URLs in the RCD claim itself.

Given the intent to recurse over multiple layers of indirect content, I think some operational guidance is even more important. My concerns were not so much around legitimate use cases for long URI chains so much as for more nefarious use cases (e.g. trying to sneak in uncontrolled web content, DOS attacks, etc.)  (Basically the concerns that Eric stated separately.)

> 
> -Chris
> 
>> On Sep 7, 2019, at 12:50 PM, Ben Campbell <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> Minor correction below:
>> 
>>> On Sep 6, 2019, at 4:31 PM, Ben Campbell <[e-mail] <mailto:[e-mail]>> wrote:
>>> 
>>> Signed PGP part
>>> Hi,
>>> 
>>> I have a couple of high level questions about the new integrity mechanism in draft-ietf-stir-passport-04. Apologies if these have already been discussed.
>>> 
>>> 1) Do I understand correctly that the certificate used to sign a PASSporT with an rcdi claim MUST include a constraint for the _value_ of the digest? That is, if someone makes any change to any of the information they would normally include in an rcd claim, the signing party must get a new cert?
>>> 
>>> My concern is that, for good or bad, commercial callers really like to control the customer experience. Many like to change things up all the time. I can imagine things like special date-specific logos (e.g. Google doodles), “sale” badges on logos, distinctive branding for different “campaigns”, etc.  I realize things like ACME make the process of getting a new cert lighter weight than it used to be, but is it reasonable to require a new cert for any change?
>>> 
>>> This might be worse for third-party signers who may sign on behalf of many callers, each of which keeps changing things.
>>> 
>>> 2) If I understand correctly, if anything in the rcd claim includes a URL, the rcdi claim incorporates the associated content. What about URLs?
>> 
>> Uhm, I meant to say additional URLs
>> 
>>> For example, lets say a jcl key links to a jCard, and that jCard has a LOGO element with a URI? Is the alleged logo content at that URI protected?
>>> 
>>> I assume the answer is that the answer is no; otherwise it could be URLs all the way down and we have to stop somewhere. This is probably a matter of signer or issuer) policy. If so, it might be worth having some operational guidance that they need to think about such things.
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
>> _______________________________________________
>> stir mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/stir <https://www.ietf.org/mailman/listinfo/stir>