New C2PA table proposal

[brogdonm]

This is a formal request for inclusion of a new table in the
ISO/IEC 14496-22:2019 Information technology — Coding of audio-visual objects — Part 22: Open Font Format
in order to support either embedding or referencing a
C2PA Manifest Store.

For more information on the Coalition for Content Provenance and Authenticity
(C2PA) visit https://c2pa.org.

Proposed Open Font Format updates by section

All of the sub-sections contained in this section correspond to (existing, or
proposed new) sections of the Open Font Format.

Each sub-section below may contain a mixture of regular text, and other text
delineated as a Markdown block-quote syntax.

The block-quoted text is the literal text proposed for inclusion in the Open Font Format; the regular text, when present, contains editorial
commentary.

2 Normative references

At the end of the existing list of references (following IETF BCP 47 spec...), an entry for the C2PA Tech Spec:

C2PA Technical Specification 1.4, https://c2pa.org/specifications/specifications/1.4/specs/C2PA_Specification.html

3.2 Abbreviated terms

C2PA Coalition for Content Provenance and Authenticity

5.7

Tag	Name
C2PA	Provenance and Authenticity

Probably 5.7.13

The font's C2PA table contains either an embedded
C2PA Manifest Store
or a URL reference to a remote C2PA Manifest Store in a
Manifest Repository.

The C2PA Technical Working Group has worked to develop open standards to
certify the source and provenance of digital content. To understand more,
please refer to the C2PA Explainer.

The C2PA table is organized as follows.

Type	Name	Description
uint16	majorVersion	Specifies the major version of the C2PA font table.
uint16	minorVersion	Specifies the minor version of the C2PA font table.
Offset32	activeManifestUriOffset	Offset from the beginning of the C2PA font table to the section containing a URI to the active manifest. If a URI is not provided, this MUST be set to zero (0).
uint16	activeManifestUriLength	Length of URI in bytes.
uint16	reserved	Reserved for future use.
Offset32	manifestStoreOffset	Offset from the beginning of the C2PA font table to the section containing a C2PA Manifest Store. If a Manifest Store is not provided, this MUST be set to zero (0).
uint32	manifestStoreLength	Length of the C2PA Manifest Store data in bytes.

Note that when the C2PA table is present it is expected the DSIG table is not present. If it is, the hashed data in either table may not appropriately match.

EDIT: Updated the manifestStoreLength to be a uint32 instead of the Offset32, thanks @behdad
EDIT: Added a reserved field

[lrosenthol]

As chair of the Technical Working Group for the C2PA, I fully support this proposal. (all conflicts of interest recognized ;).

[HinTak]

Since you mentioned DSIG, how does your proposal different from DSIG, and why did you not propose a new version of DSIG instead? These are important questions - what exactly does an upgrade of current system not do? Message ID: ***@***.***>

[kenmcd]

Just another way to do copy protection.
Wrapped-up in a phony save-the-world "trusted source" wrapper.
That it makes it easier to monetize everything is just a side effect.
Liars making sure they will get paid for their lies.

[simoncozens]

I'm not convinced by this, which I guess is a gentle way of saying that I'm opposed. I feel like it misunderstands the specification in a couple of important ways.

First, I can obviously see the point of specification changes which enable technical development, i.e. we can now do things which we couldn't do before. But if all you want to do is store arbitrary metadata, OFF already allows two ways of doing this: you can put it in your own user-defined (mixed-case) table, or you can put it in the meta table. Either of those would work for this use case. So why does it need a formally specced-out table?

Second, I can't see why this is needed now. Since there are already ways to store arbitrary metadata inside a font, if this is a real need then we would see people already trying to do this. Can you point to a critical mass of fonts with C2PA data embedded inside them? I suspect not. People often want to spec out an "official" table not because something is already happening, but because they want to encourage something to happen in the future. But the OFF spec is littered with areas which have been specified "speculatively" (DSIG being a very good example; the JSTF table and many of the registered features also being the case), and now it's just a mess. There's practically no evidence that adding a table to the spec actually encourages adoption; no guarantees that it's going to get used any more than a user-defined table would.

This isn't a comment on C2PA. It may be a great thing or a terrible thing. I don't know and I'm not really familiar with it. It may even belong inside a font, who knows. I just don't see why it belongs in the spec.

[davelab6]

Also see MicrosoftDocs/typography-issues#1066

[brogdonm]

Since you mentioned DSIG, how does your proposal different from DSIG, and why did you not propose a new version of DSIG instead? These are important questions - what exactly does an upgrade of current system not do? Message ID: @.***>

@HinTak awesome query, forgive me for a basic copy/paste of an answer. But I think the same applies to your query.

Some of my thoughts around why I think C2PA might succeed where DSIG failed, is DSIG was only intended (from my understanding) to check if a font was meddled with or changed. Although this is true for C2PA as well, C2PA offers a way to make claims about an asset with a mechanism in place to keep track if the claim is valid. For example, if I created an instance of a variable font, it would be possible to assert the parameters (or any other variables) used to extract the instance.

Another reason, is support for C2PA is included in many different assets already. When looking at the embeddable formats in the C2PA 1.3 specification, one may see the benefit of using a specification already supported by other well-known asset types. This is bigger than just font software and would have plenty of benefits. For example, since most image formats support C2PA, it would be awesome to look at the C2PA manifest of the image and see listed in the ingredients which font was used for a specific text. I have used "reverse lookup" methods in the past to figure out which possible fonts were used in an image; use of the ingredient would eliminate the need for guessing based on the rasterization of vectors.

My latter reason is, in my opinion, a good reason not to propose a DSIG 2.0. Proposing a new DSIG 2.0 would be font specific and would lack the benefits of linking in with assets that use font software. I don't think DSIG was ever really fully utilized for the original purpose and turned out where very few fonts used proper digital signatures. Would creating a DSIG 2.0 fix the reasons why DSIG failed? Or would a DSIG 2.0 fail just like DSIG did? Personally, I think going with C2PA makes more sense and has a better chance.

[lrosenthol]

To follow up a bit on one of @brogdonm 's comments...

C2PA is included in many different assets already. When looking at the embeddable formats in the C2PA 1.3 specification, one may see the benefit of using a specification already supported by other well-known asset types. This is bigger than just font software and would have plenty of benefits.

Consider the benefits specifically with the use of fonts in PDF. If the provenance of the font is included in the PDF, even though the subsetting process, consider the business and practical benefits that would offer to both end users as well as font authors/foundaries.

Here is a picture that I drew showing how this would work...

And, as noted, because C2PA support is already out in the world (though not yet for fonts, of course) both in commercial as well as open source solutions, the chance of adoption (for fonts) would be a higher due to the much lighter weight lift to get there.

[tiroj]

In the 1990s, digital signatures were also ‘out there in the world’, and part of the promise of DSIG at the time was that fonts would plug into these existing systems of digital signature certification and signed data checks etc.. A big part of why this failed to take off was simply that font makers mostly did not see the benefit in paying fees to certification authorities, when the only practical benefit to DSIG at the time (recognition of TTF OT fonts as such within Windows and Office) could be achieved with an empty stub DSIG table.

My reading of the C2PA explainer document indicates that this technology is also dependent on certification authorities:

To enable consumers to make informed decisions about the provenance of an asset, and prevent unknown attackers from impersonating others, it is critical that each application and ecosystem reliably identify the actor to whom a signing credential (also known as a digital certificate) is issued. A certification authority (CA) performs this real-world due diligence to ensure signing credentials are only issued to actors who are whom they claim to be.

I wonder whether there is any grounds to suppose that this would not meet exactly the same end as DSIG in the context of fonts?

[tphinney]

It is hard not to wonder if perhaps those proposing to add C2PA to fonts (Monotype) have… more specific use case(s) in mind that have not been called out.

Whether some or all of these use cases might resemble DRM, either in general, in some situations, or at least in some people’s eyes, is also a good question.

On the upside, this could be a good answer to @tiroj in explaining why this tech might see more/better adoption than DSIG.

[HinTak]

The reference to embedded font usage in pdf is invalid, really - typical font subsetting operations drop "unnecessary tables" (and also "invalid data" - if your new table contains checksums, etc, subsetting would void it), and DSIG actually being one of them.

Google fonts' web-font subsetting operation AFAIK also aggressively drop "unnecessary" tables, this being for reason of network bandwidth/ disk usage.

So you'll have a problem just convincing a few parties to not drop your new table by default.

Also, as other points out, it isn't necessary to propose new tables to use them. VTT uses a few of its own while editing fonts; and I believe some dynalab fonts carry unusual / non-opentype-spec tables too. So, please feel free to add them and use them for your purpose. Proposing them as part of the spec is a different matter.

[lrosenthol]

@HinTak as Adobe's PDF Architect and chair of ISO TC 171/SC 2, where PDF is standardized (as ISO 32000), I am well aware of how things work with fonts and PDF today. And that same "removal of unnecessary tables to reduce size" happens with image formats today on the web for the same reasons.

However, the world of "deep fakes", "generative AI", "mis/disinformation" and an overall lack of trust amongst end users towards the content that they consume online is significant enough to change that behavior - favoring provenance information over file size. End user studies are showing it and governmental legislation is headed in that direction in various countries world wide.

Those of us proposing this, as part of the C2PA, believe that it will succeed where DSIG did not...or we wouldn't have proposed it. And you are correct that we could/would "do it on our own"...we have done that for other formats when we needed to. But our preference in all cases is to reach out to owners of the standard and ask them how they wish us to proceed. So its up to you folks - we will proceed with the work either way...but we'd prefer to have your support in the matter, even if we don't put it in the standard proper.

[davelab6]

@lrosenthol do you have any pointers to existing rebuttals against claims that C2PA is a DRM system?

[lrosenthol]

@tiroj Yes, all X.509-based digital signature technology has its trust model rooted in Certificate Authorities. It's the same technology used to secure web sites and documents, so I would expect that anyone who manages their own site and/or produces contracts, has already acquired such a certificate.

[lrosenthol]

@davelab6 Absolutely!

@lrosenthol do you have any pointers to existing rebuttals against claims that C2PA is a DRM system?

In the Security Considerations document (https://c2pa.org/specifications/specifications/1.0/security/Security_Considerations.html#_security_model), under Confidentiality it very clearly states

C2PA does not specify Digital Rights Management (DRM) technology.

I will also note that the C2PA specification is designed around a set of Design Principles (https://c2pa.org/principles/) that specifically call out the needs of human rights around the world - something that DRM would fly in the face of. And this area isn't stagnant either, you can read about our ongoing "Harms Modeling" process at https://c2pa.org/specifications/specifications/1.0/security/Harms_Modelling.html that ensures that every feature that is added to our specification undergoes deep "Threats and Harms" review before approval.

[HinTak]

@lrosenthol that doesn't really address @tiroj 's point. @tiroj basically said the actual number of font owners who have x509 certificates are low. So I am not sure who exactly this new table is created by, and who will read it. Between the two of you, @tiroj basically said font owners/designers won't create the table. @lrosenthol but you seem to be suggesting that it is a table inserted by a 3rd party (neither the font designer/owners nor the font user), and inspected by a 4th party?

Still struggle to understand who is supposed to create/insert that table, and who read/inspect it.

It sounds as if this is a table made by nobody and read by nobody 😉

[lrosenthol]

@HinTak I am not sure who a "font owner" is. In my view of fonts, there are font authors/creators. These authors/creator would most likely be the one who has the table inserted as part of creation of the font - just as those authoring images, videos and documents would have the C2PA Manifest added at authoring time.

These authors either self-publish their creations or they are published by larger entities, which historically we may have called "font foundaries" (e.g., Monotype, Adobe, Google, etc.). And such publishers may also want to extend (or potentially replace) that provenance, and would then update/replace the table.

Certainly all of the larger publishers have web sites and therefore have certificates that they have acquired for those sites. I suspect that many self-publishers also have their own sites for commerce - and therefore also have their own certificates. So I guess my question back to @tiroj is what font author doesn't have a certificate? Maybe the hobbyist making free fonts in github? But I would think that's the minority...

Who would read the table? That's a more interesting question, IMO. From my perspective, I can see authoring tools and PDF production tools doing validation of the C2PA Manifest as part of using the font in their creations/documents as a way to record that the font has not been modified since being published/distributed. It could be used as part of a Brand's QE process - making sure that all the proper fonts were used. In fact, we just saw something like this with the new Adobe Express, where a company discovered (because of our new "bring your own fonts" model) that their employees had previously been using their own versions of the corporate font instead of the approved one!

[HinTak]

About the x509 certificates, that's an interesting dilemma - people who cannot afford it, don't have it. People who can afford it (large foundry and distributors/aggregators) tend to keep the certificates in a secure location under lock and key, and access on a need-to basis. So none of the large foundry/aggregators routinely take their certificate out to sign new releases. Including Adobe CC, of all places.

How are you going to convince the Google Fonts folks, for example, to unlock the private certificate every week when new releases come in every week? Or the Adobe CC folks, for that matter?

The adoption of DSIG was low, partly because of this "practical" reason: if a certificate is important, it goes under lock and key, and the signing process itself becomes a heavily audited/monitored process for privileged few in a large organisation.

The only people I know who reliably/routinely sign their fonts are the Microsoft OS fonts. The signing process is a once-in-a-few-years event.

DSIG itself supports counter-signatures, (i.e. modifications, signing off on others' signatures), but again, that feature itself is rarely seen in the wild.

[lrosenthol]

Modern key management actually keeps the key safe in an HSM (Hardware Security Module, https://en.wikipedia.org/wiki/Hardware_security_module) and it is accessed as part of some form of server-based software process. This is how Photoshop signs all of the images that users are creating for our Content Credential (aka C2PA) functionality - https://helpx.adobe.com/photoshop/using/content-credentials.html. Ps has no direct access to they key.

I would expect that font production software/systems would integrate with similar server-based solutions and the process would become automated - in ways I suspect it already is anyway.

It is also worth noting that no one is suggesting that this table - or that the technology itself - is mandatory for fonts or any other asset type. It will be a useful addition to those fonts that wish to add it...

[HinTak]

Fact is not even many of the Adobe fonts shipped with products (photoshop/acrobat etc) are signed, not least the recent more frequently(?) Updated Adobe Source font family...

I think there is an additional dimension with fonts vs images, of 3rd party (distributors/resales) signing and vouching for creators: it has been possible to crash windows with carefully crafted web fonts, by remote means, just tricking an end user to visit a specific web site which in turn gets it served from a web font host. I'd be slightly uncomfortable "distributing" a font as a resaler to put my digital signature on it, due to legal liability, for example.

I think so far the questions are fairly clear: addressing the questions against DSIG: why equivalent functionality isn't done through DSIG v2 or even clarifying DSIG v1, and why do you expect this will have better adoption than DSIG (which have essentially the same technical requirements: certificates, signing and checking tools); and the questions about usage: who put the signatures in (and counter-sign additional credentials), and who read/check it.

[davelab6]

font makers mostly did not see the benefit in paying fees to certification authorities

But that was before EFF offered letsencrypt.org in 2015 ;)

https://letsencrypt.org/stats/

https://devel.nmsprime.com/confluence/display/NMS/Getting+a+X.509+certificate+via+Let%27s+Encrypt

[atillakorap]

@HinTak at Monotype we discussed the very same thing internally. Should we store C2PA information in the DSIG table? Technically it is a strong argument to avoid redundancy. But you could argue that CFF and glyf tables essentially do the same thing. So do OpenType Layout and AAT (probably not fair to compare as they live in different specs). And think about the different color font formats. I don't even remember how many there are. I believe, they exist because they are supported by at least one platform with a huge user base.

It's interesting that the different formats exist and none of them seems entirely redundant, while DSIG is one of a kind (in the spec) and never got accepted.

• It's a one company show
• there was only poor tooling around it
• type designer's found it useless and complicated
• users never knew about it
• other software vendors ignored it
  In other words: DSIG has the reputation of enabling the OpenType icon on Windows and is otherwise useless, since it doesn't even need to be a valid DSIG table.

20+ years later the world is a different place. Every website better has a certificate nowadays. Security is much more present than at the time of OT Spec v1.0. C2PA is a collaboration of many software companies, not just one. It is geared towards the authenticity of design resources. We think (among other things) fonts are that too. Through the other formats that C2PA supports, there are templates for tooling and use cases that benefit all parties: font users, website visitors, foundries, software vendors. Hopefully, users will know about C2PA, because they know it from the context of images and videos. We think all these things put C2PA in a different spot than DSIG at the time. That's why we think it should be a distinguished from DSIG.
I also think that these arguments answer the question about why C2PA should succeed.

[behdad]

I'm also skeptical of C2PA. But that aside, from a technical point of view, I like to see at least one implementation before it's put in the spec. Currently it's not clear to me how one can sign a font and include it in, while also adjusting the font's checksum. The DSIG table specifies how to do that. This table doesn't.

Also, the last Offset32 should be uint16 or uint32.

[atillakorap]

I agree, that will make it less abstract. @brogdonm and his team have worked on a Rust implementation and they've also set up services and a demo website. I hope he can point to that and the repo.

[brogdonm]

Thanks @atillakorap. @behdad you can find a proof of concept in a fork of Content Authenticity Initiative's Rust repository with updates to add C2PA data to a OTF/TTF fonts:

https://github.com/Monotype/c2patool/tree/monotype/fontSupport