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

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?

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.

-Chris

> On Sep 7, 2019, at 12:50 PM, Ben Campbell <ben@nostrum.com> wrote:
> 
> Minor correction below:
> 
>> On Sep 6, 2019, at 4:31 PM, Ben Campbell <ben@nostrum.com <mailto:ben@nostrum.com>> 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
> stir@ietf.org
> https://www.ietf.org/mailman/listinfo/stir