Subject: [lamps] draft-ietf-lamps-rfc3709bis-01 security, reliability, and privacy considerations

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 25 Mar 2022 16:14:10 -0400

I did a quick skim of
https://www.ietf.org/archive/id/draft-ietf-lamps-rfc3709bis-01.html and
observed that while the Security Considerations section describes some
of the "phone home" or "web bug" concerns about logotypes-by-reference,
they aren't particularly well fleshed out.

The current text is:

  > Logotype data is fetched from a server when it is needed. By
  > watching activity on the network, an observer can determine which
  > clients are making use of certificates that contain particular
  > logotype data. This observation can potentially introduce privacy
  > issues. Since clients are expected to locally cache logotype data,
  > network traffic to the server containing the logotype data will not
  > be generated every time the certificate is used. In cases where
  > logotype data is not cashed, monitoring would reveal usage
  > frequency. In cases where logotype data is cached, monitoring would
  > reveal when a certain logotype image or audio sequence is used for
  > the first time.

This and at least one other paragraph in the Security Considerations
section might belong better in a separate Privacy Considerations
section.

Below i unpack a bit why these "web bugs" features are not well-fleshed
out in the draft as it stands.  This spec is surprisingly twisty and
complex, so i'm not sure that this covers everything:

 a) there are at least two different things that a relying party might
    need to make a network call when trying to render a certificate:

    - an indirect LogotypeData object
    - the image or audio file referenced from a LogotypeData object

    If the client is going to cache these things to avoid leaking
    information on the network, it presumably needs to cache both types
    of object.

 b) to minimize the number of network requests the relying party's cache
    should be indexed by cryptographic digest of the objects it
    holds. Since a single object might be referenced by multiple
    cryptographic digests, a maximally privacy-protective local cache
    should probably contain one index per supported digest algorithm.

 c) If any one of the elements in logotypeHash is already in the relying
    party's local cache, the privacy-preservng thing for the client to
    do is to ignore all logotypeURI elements, even if some of the
    logotypeHash objects are not found in the cache.

 d) note that the *lack* of a network request for a given URI can also
    be used for fingerprinting (depending on how the client deals with
    newly-encountered certs, this could be analogous to HSTS
    fingerprinting, for example:
    https://datatracker.ietf.org/doc/html/rfc6797#section-14.9)

 e) If a subscriber asks the issuer to include an image or audio via
    URL, or if they ask the issuer for an indirect logotype, the issuer
    can't be sure that any logo data suggested by the subscriber is
    going to be available for the lifetime of the certificate at the URL
    proposed.  Furthermore, the issuer has no control over privacy
    policies that govern metadata collection by the host of any remote
    resource.  This draft should encourage an issuer who cares about
    potential privacy risks for its relying parties to copy any
    referenced data to a server that it already controls and can make
    reasonable guarantees about privacy, reliability, etc.  Note also
    that if the subscriber asks the issuer to refer to an indirect
    LogotypeData object, and the issuer decides to host that data itself
    in addition to hosting the underlying image or audio resource, the
    logotypeData object will need to be rewritten to change the
    underlying URLs (and will therefore have a different digest than the
    requested object).  This at least makes the privacy situation
    comparable to CA-controlled OCSP, rather than subscriber-controlled
    resources.

 f) i didn't see any guidance to relying parties about how to handle a
    mismatch between the MIME type referenced in the mediaType field of
    the logotypeData and the Content-Type HTTP header of the retrieved
    resource.  Consider a polymorphic bytestream that could be
    interpreted by either a png renderer or a pdf renderer.  As the spec
    is currently written, it looks like a client could accept a
    Content-Type from the https server that doesn't match the mediaType
    field, and it might accept the HTTP header as ground truth.

 g) the draft should offer additional guidance for a CA that wants to
    demonstrate a commitment to not planting web bugs in its
    certificates.  here are several approaches, including:

      - Always using direct LogotypeInfo objects (no network access)

      - Self-host referenced objects (as in (e))
      
      - Consolidate hosted objects (all objects with the same hash are
        always at the same URI, to avoid path-based fingerprinting)

      - ensure that encoded non-data URIs are as low-entropy as
        possible, to limit the amount of individualized tracking that
        could be done (a distinct URL per cert would be the most
        dangerous)

 h) advise relying parties on how to constrain their HTTP resource
    fetches to minimize fingerprinting (e.g., no cookies, no e-tags,
    anonymized user-agent, no client certificates, and so on) -- is
    there some sort of anonymous HTTP client profile we could point to?
    (note that this might contradict the guidance about performing
    "appropriate security controls" for privacy-sensitive logos)

A few additional concerns about the draft (sorry this is all smushed
into a single e-mail -- if there is an issue tracker for this draft,
please reference it in subsequent versions of the draft so that these
notes can be broken out separately):

 i) not clear how to map the elements in the logotypeHash sequence of
    hashes to the elements in the logotypeURI sequence of URIs.  Should
    every reference within a given logotypeDetails refer to the same
    underlying object?  (this is related to (c) above).

 j) this might be an ASN.1 confusion on my part, but the index
    parameters within LogotypeImageInfo object seem off to me.  they
    start with [0] for the "type" field, but then language is [4] and
    there are four fields in between (fileSize, xSize, ySize, and
    resolution).  Shouldn't language be [5] or am i misunderstanding
    ASN.1?

 k) this draft implies a range of types of logotype: subjects, issuers,
    loyalty schemes, etc.  It's pretty easy to see this as expanding
    beyond use of logos (e.g. photo IDs for an S/MIME cert).  i'd hope
    to see some considerations either explicitly ruling out non-logo use
    of these objects, or at least addressing the privacy implications of
    using them for non-logo use.

 l) when fetching an indirect logotype, what Content-Type should the
    relying party expect for the LogotypeData?   I'm assuming it's
    supposed to be DER-encoded?

 m) no security considerations for folding polymorphic image renderers
    into certificate handling code?  we have recent evidence that there
    can be pretty disastrous bugs lurking there:
    https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-into-nso-zero-click.html
    guidance about ensuring narrow, well-audited codepaths would be
    great.

Sorry this review is so long and yet still incomplete.  There are a lot
of moving parts in this draft.

i welcome comments, feedback, questions about anything that's unclear here.

   --dkg

PS the Security Considerations section contains the word "cashed" when i
   think it means "cached"

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 28 Mar 2022 22:38:29 +0200

Thanks for the review Daniel,

Thank you also to take your time to explain in such details the many
issues and challenges involved with retrieval, caching, storing and
preserving data.

I would like to respond to this on a conceptual level rather that
attempting to comment on each point.

I don't think each specification that allows data to be referenced using
a URI has the obligation to educate and specify every aspect and issue
related to retrieval, caching, storing and preserving data. The question
is not as much what the potential problems are, but what this document
must say about it.

I'm not convinced that this document is the palace to regulate or advice
on caching or storage. My main motivation for this position is that the
potential use-cases are not specific to the degree where you can give
specific meaningful guidance. Any guidance will therefore be generic to
the degree that it should belong in generic documents. Implementers can
chose their approach to this issue from the context of how the
certificates are issued and used.

Obviously things becomes much easier if all data is embedded, but this
has the the cost of larger size.

Another argument for not giving specific guidance here is that caching
may also be handled on another layer that is completely independent of
this specification and its implementation, such as generic http caching
by the application or the network.

On all other issues, I include comments below.

> section might belong better in a separate Privacy Considerations

I have no opinion or preference here.

>     underlying object?  (this is related to (c) above).

The text says: "Both direct and indirect addressing accommodate
alternative URIs to obtain exactly the same item"

>     resolution).  Shouldn't language be [5] or am i misunderstanding

Tags do not need to be in an unbroken sequence. The tag is just an
identifier, not an index. And not all items must be tagged.

I don't remember exactly, but the reason for [4] may have been chosen as
resolution is optional.

The key is that there is no ambiguity for the parser what field each
present integer specifies.

>     using them for non-logo use.

There are already non-logo use. Se section 4.4.3, and that is one of the
RFCs that used to be a spin-off RFC (6170) that not is merged into this
document.

>     supposed to be DER-encoded?

You are right. This is not specified, nor is the encoding of the present
data. This should be fixed.

I would suggest application/octet-stream and DER encoding

>     guidance about ensuring narrow, well-audited codepaths would be

I don't feel qualified to answer this one. If there is something that
should be said, then we should say that.

> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 29 Mar 2022 18:17:02 -0400

Hi Stefan--

Thanks for your followup!  comments inline.

> certificates are issued and used.

I'm sure you didn't mean it this way, but this kind of reads like "as
protocol designers we can't be bothered to think through the privacy
implications of our work" or "privacy implications are left as an
exercise to the reader".

I'm not suggesting that every single detail i outlined in my earlier
message belongs explicitly in the draft.  But i don't think it's
reasonable in 2022 to omit privacy considerations entirely on a document
that is going to ask the relying party to fetch some (possibly multiple)
additional network resources in some circumstances, especially in
security-critical circumstances (like inspecting the certificate of a
communications partner).

The systems we design and specify in the IETF and other SDOs are
routinely used across the globe to identify and target people, for
purposes ranging from counting advertising conversions to offering
customized content to tracking down criminals, debtors, and dissidents
to deliberate killing.

I'm not saying that this mechanism on its own is necessarily going to
result in any of these outcomes, but i am saying that how it is deployed
in the world will have an effect on people's lives and the risks they
face.  As designers and specifiers we need to consider that, and to help
implementers consider it and implement responsibly.

> has the the cost of larger size.

I understand this constraint, and agree that there is an inherent
tradeoff between certificate size, caching behavior, and privacy
concerns.  Unfortunately, that tradeoff is not adequately discussed in
the draft.

Furthermore, the draft doesn't do much to try to alleviate size concerns
at all -- it almost looks like an afterthought.  For example, if the
draft really wanted to prioritize minimizing certificate size, then it
would offer an ASN.1 native OCTET STRING representation for the embedded
objects, rather than stuffing another layer of base64-encoding with the
data: URL.

Even worse, the text in the draft says:

   There is no need to significantly increase the size of the
   certificate by including image and audio data of logotypes when a URI
   identifying the location to the logotype data and a one-way hash of
   the referenced data is included in the certificate.

This "no need" appears to encompass the privacy rationale, if i'm
reading it right.

So as it stands, the document not only dismisses the privacy concerns,
but appears to actively discourage privacy-motivated embedding by
inflating the size of an embedded resource by base64's 33% overhead.

It even warns against embedding with scary-but-unquantified,
non-actionable guidance like:

     NOTE: Implementations need to be cautious about the size of images
     included in a certificate in order to ensure that the size of the
     certificate does not prevent the certificate from being used as
     intended.

What are these limits?  Where do they come from?  Do they also apply to
the size of images fetched over the network?  I'm fine with establishing
sensible, even arbitrary limits for the sake of interoperability.  But
then they need to be well-defined and measurable limits with clear scope
as to where they apply.

If the draft tried to take privacy seriously, it would at least
contemplate the following questions:

 - If i'm a certificate issuer, and i want to avoid my relying parties
   from being tracked, and i'm asked to produce a certificate by a
   subscriber, what should i do to minimize the risk of harm to my
   relying parties? At what cost?  what if i'm concerned about my
   *subscriber* being tracked by an entity observing activity of the
   relying parties?

 - If i'm a subscriber, and i don't want to expose my users (the relying
   parties) to additional risks of tracking and surveillance, what
   should i request from my certificate issuer?  At what cost?  If i
   have such a certificate, are there ways I can operate my service to
   reduce risks to my users?

 - If i'm a relying party, and i want to minimize my tracking, how
   should i handle certificates with these logotypes in them?  At what
   cost?

 - As an implementer of client software used by the relying party, what
   affordances should i make in my implementation to defend the user's
   privacy?

 - How do these four different perspectives interact?

(or, you could approach this the way a security analysis is typically
done: put yourself in the shoes of the tracker/surveillor and see how
you would deploy this to maximum tracking effect, against the wishes of
the subscriber or the relying party)

It's ok to not have all the answers to all of these questions, but the
document needs to acknowledge that they're relevant, and either describe
some simple, widely-applicable mitigations, call for further research,
or point to existing already-documented strategies that can reduce the
risks to privacy.

> by the application or the network.

I think you're saying the privacy implications of those additional
layers are themselves not well understood.  I don't think i'd argue with
you about that.

That's why a draft that tries to clarify the mechanisms for including
media in certificates (potentially by multiple layers of indirection)
should include a privacy considerations section that attempts describe
or point to the potential known risks at least, even if it can't
describe all possible mitigations.

>>     field, and it might accept the HTTP header as ground truth.

This point didn't seem to get a response.  can you comment on it?  Did i
misunderstand the draft?

> alternative URIs to obtain exactly the same item"

the text is confusing as written because:

- there are multiple layers of plurals involved (do direct and indirect
  addresses need to both point to the exact same item?  what about the
  layers between the LogotypeReference and the LogotypeDetails?), and

- "exactly the same item" is unclear.

Does "exactly the same item" mean that the contents of the HTTP
responses should be byte-identical?  or that their *headers* are also
byte-identical?  what if the URL points to a resource that has different
body content based on the Accept: or Accept-Language: (or Accept-*?)
headers in the HTTP request?

Some of the metadata variants described here seem to be recapitulation
of (or hints that can be used to populate?) the http content negotiation
mechanisms.  Being clearer about how those things interact (or don't
interact) would be useful.  If the answer is "we don't trust HTTP
content negotiation to work right, so we're giving you all this data up
front and we recommend that servers host this data in distinct urls
without using content-negotiation for selection" that belongs in the
draft.

Also, i note that the ASN.1 for refStructURI contains this comment:

                    -- Places to get the same LogotypeData
                    -- image or audio object

But the ASN.1 for LogotypeURL has no such comment.  why?

just to be clear, we have this nested set of SEQUENCEs in the data
structure (i'm using "*" to mean "contains more than one of")

  LogotypeExtn
   * LogotypeData (assuming "direct")
    * LogotypeImage (assuming image, not audio)
     * LogotypeDetails
      * LogotypeURL

And that's just one path through the ASN.1 maze to get to where the
multiple LogotypeURLs show up.

Are all the LogotypeURLs within a LogotypeData expected to point to the
same underlying data?  Or could there be multiple LogotypeImage objects
within a LogotypeData, where each image has distinct underlying data?

Assuming that the "exact same item" idea applies only to the final layer
of SEQUENCEs, clearer text would be something like:

   Within a single LogotypeDetails, every LogotypeURL MUST point to a
   bytewise-identical resource.

The categorization as i think i understand it is:

 - How the media relates to the certificate is governed by where the
   LogotypeInfo sits in the top-level LogotypeExtn, *or* (if it sits in
   otherLogos) by the logotypeType OID.

 - The LogotypeImage object can have multiple digital representations of
   the same conceptual piece of media, differentiated by the associated
   metadata (format, bitdepth, language, etc).

 - The LogotypeDetails can point to multiple ways to retreieve the same
   digital object.

what i still don't understand, after several re-reads of the draft, is
why the LogotypeData can have more than one image and more than one
audio element.  Or maybe LogotypeData offers multiple distinct digital
representations of the same object by enclosing a sequence of
LogotypeImage objects?  but then i don't understand why there are
multiple LogotypeDetails objects within a LogotypeImage object.

Maybe the draft itself could offer a succinct explanation of why each of
these layers is present?

> RFCs that used to be a spin-off RFC (6170) that not is merged into this

It's pretty weird that the document is titled with the word "logotypes",
and it has a terminology section, and yet there is no direct
acknowlegement of the word "image" or "audio" or even "media" until §3.
It appears to offer a generic mechanism to embed media resources in
X.509 certificates, which happens (by historical accident) to be named
"logotype".

If i didn't already know what i was looking at, it would be very hard to
make sense of the draft.  I'm not saying to drop the term "logotype"
entirely, but at least give the document a title like:

   Internet X.509 Public Key Infrastructure: Media ("Logotypes") in X.509 Certificates

And explain the historical accident in the introduction and/or in the
terminology section.

The reason i raised the logo vs. non-logo use is that logo-specific use
at least offers users that fetch a given logo an anonmity set of all
certificates using the same logo
(e.g. "https://www.visa.com/favicon.ico").

But non-logo media are likely to uniquely identify a particular
subscriber.  For example, "Certificate Image" is basically guaranteed to
differ between certificates.

Consequently, any network fetch for a resource that corresponds to the
subscriber risks identifying the subscriber.

TLS 1.3 only recently got finished protecting the server's certificate
in the TLS handshake's encryption layer, so that a network observer
can't see the offered endpoint identity.

If this draft expects the client to make a separate network fetch for a
given resource, potentially over http(!) then it risks undoing that
metadata minimization work.  Even if the resource is fetched over https,
if the size of the request/response pair for the resource is unique to
the host in question, then a network observer can guess with high
confidence the identity of the service being visited.

Furthermore, if the cert-specific media is reused across certificates
over time, then it can produce a long-lived data trail, capable of
linking otherwise unlinkable identities.

> I would suggest application/octet-stream and DER encoding

Shouldn't this document register a specific MIME type?  I understand
that some webservers are slow to be able to announce new MIME types, and
it's possible that this thing will get served as
application/octet-stream by those servers, so maybe we don't want a
client to reject an application/octet-stream necessarily. But this is
why we have MIME type registration, right?

How about application/logotypedata since that's the (downcased) name of
the ASN.1 structure that it is supposed to contain?  I think there are
people in this WG who know how to navigate the media type registration
process and can help with that.

> should be said, then we should say that.

My preferred guidance here would be related to the guidance i asked for
in point (f), about what to do if the metadata in the logoType extension
doesn't match the metadata in the logotype extension (mediaType,
LogotypeImageInfo, LogotypeAudioInfo, etc) doesn't ultimately match the
retreived resource.  the only place where guidance is currently provided
for a metadata mismatch is when the x and y (width and height) don't
match, as described in §4.2.

Conservative/defensive parsing, rejection of non-compliant or mismatched
formats (at both the cert issuer initially, and by the relying party in
the field) keeps the attack surface significantly smaller.

So in the course of writing this message, i re-read the document again,
and found several more concerns.  If you have an issue tracker, these
would be easier to ensure that they get fixed (and to make sure i'm not
repeating myself); if you have the source for this in some reasonable
revision-controlled repository, i could maybe even offer you fixes
directly for some of them.  But as it stands, i'll just continue from
where i left off:

n) There seems to be a mismatch between the ASN.1 and the text about
   whether an image must be present.  The text says yes:

      Each logotype present in a certificate MUST be represented by at least one image data object.

   but the ASN.1 seems to say that audio-only is OK:

    LogotypeData ::= SEQUENCE {
       image           SEQUENCE OF LogotypeImage OPTIONAL,
       audio           [1] SEQUENCE OF LogotypeAudio OPTIONAL }
          -- At least one of the OPTIONAL components MUST be present
          ( WITH COMPONENTS { ..., image PRESENT } |
            WITH COMPONENTS { ..., audio PRESENT } )

o) It would be great if each example were supplied within an simple
   X.509v3 certificate represented in PEM form, in addition to whatever
   dumpasn1 data and commentary the draft provides.  This would make the
   draft something actionable, which implementers could confirm works
   with their tooling (or doesn't).

   I recommend using the sample certificate authorities in
   draft-ietf-lamps-samples to create the sample certificates.

p) It would be great to see more examples/test vectors, including:

    - examples that exercise the audio functionality

    - examples where any given SEQUENCE in the twisty maze of SEQUENCEs
      has more than one element

    - examples of all Logotypes and "Other logotype type OIDs" defined
      in the draft

   If there isn't enough space (?) to include these examples in an
   appendix, then at least point to a place where these things will
   reliably exist so that an implementer can confirm the rough consensus
   with their own running code.

q) §3 ("Logotype Data") says: "If a logotype of a certain type (as
   defined in Section 1.1)" but section 1.1 is "Certificate-based
   Identification".  Maybe it means "Section 2" or some subpart of
   section 4.1?  I recommend including these references in the
   underlying source by symbolic identifier, so that when sections get
   renamed, the output matches automatically.

   The security considerations section also references section 1.1 when
   it appears to be talking about either section 2 or section 4.1.

r) https://www.ietf.org/archive/id/draft-ietf-lamps-rfc3709bis-01.html#section-4.4.3 says:

     When a certificate image logotype appears in the otherLogos, it
     MUST be identified by the id-logo-background object identifier.

   I think this is meant to be:

     When a certificate image logotype appears in the otherLogos, it
     MUST be identified by the id-logo-certImage object identifier.

   (that is, the OID name appears to have been copy/pasted from the
   §4.4.2)

s) the ASN.1 for refStructURI contains this comment:

                    -- Places to get the same LogotypeData
                    -- image or audio object

   is it really "image or audio"? or is it "image and/or audio" or is it
   just a LogotypeData object, since that object itself might refer to
   multiple different image or audio objects?

t)  "4.3. Embedded Images" says:

      If the logotype image is provided through direct addressing, then
      the image MAY be stored within the logotype certificate extension
      using the "data" scheme [RFC2397]. The syntax of the "data" URI
      scheme defined is included here for convenience:

   The implication here seems to be that if the LogotypeData object
   included by reference ("indirect addressing") then the LogotypeURI
   within that LogotypeData *can't* use the "data" URI.  If this is
   right, it means that indirect addressing will actually incur two
   distinct network lookups if the cache is empty, resulting in both
   latency and privacy losses.

   Why not allow the LogotypeURI contained with remotely-fetched
   LogotypeData to use a data: URI?

   It seems possible that this text was introduced in confusion over the
   multiple layers of indirection that are possible in this draft: i can
   understand why there's no point in sending a data: URI in a
   LogotypeReference, because you might as well just send a LogotypeData
   directly.

u) §4.4.3 says:

     Applications providing a Graphical User Interface (GUI) to the
     certificate user MAY present a certificate image according to this
     standard in any given application interface, as the only visual
     representation of a certificate.

   I'm assuming here that "certificate user" may be either the
   subscriber or a relying party.  I think this text is problematic for
   a relying party.

   As a relying party, the application has to have some level of
   knowledge about how it will *act* on the cert (the draft calls this
   "automated certificate path validation").  The draft makes it very
   clear that the images here have no bearing on the functional aspect
   of the certificate.

   I might trust a given CA (or its intermediate CAs) to validate the
   functional parts of a certificate mechanically (via ACME, for
   example; i can rely on a CA to say "we know this cert belongs to
   foo.example because we executed ACME challenge X").  That validates
   the functional parts, which are what my tooling relies on.  But i
   have *no idea* how any of my "trusted" root CAs (or their
   intermediaries) are going to produce or vet these images. Indeed,
   since the spec says that the images won't be used in path validation,
   the CAs might deliberately not vet them much, because there are no
   CA/B Forum Baseline Requirements about them (are there?)

   But when i ask my tooling to render information about a peer's
   certificate, the most salient features that i'm looking for are the
   verified, functional elements, not just the branding.

   Consider a certificate with a subjectAltName of foo.example, but an
   embedded certificate image that prominently displays the VISA logo
   and say "foo.example" in 8 point font near the bottom right.  If the
   operator of foo.example knows that Alice has a Visa credit card and
   will use this mechanism to confirm the identity of whatever site she
   visits, this strikes me as a clear phishing risk.  the operator can
   just make, say, https://visa.foo.example mimic the visa webpage and
   when the user clicks on the site info button in their browser to try
   to understand what's going on, there's the visa logo, with no other
   info!

   So I can't tell whether the cited paragraph is acknowledging that some
   implementations will fail to give the user visible detail about the
   functional mechanics of a certificate, or if it is actually
   encouraging implementations to hide their functional interpretation
   of the cert.

   If the cited paragraph is just an acknowledgement that some
   implementations will be dangerously insecure, I think we should (a)
   offer a more explicit lamentation, and (b) add a sentence that
   indicates that an implementation that can only offer this visual
   representation MUST at least offer a certificate export mechanism
   (coupled with an export of any related cached LogotypeData or media
   objects that were retrieved over the network), so that an interested
   user can debug the underlying certificate with different tooling.
   This is more of a "MUST (BUT WE KNOW YOU WON'T)" from RFC 6919§1 but
   hey it's better than an idle lamentation.  Even better would be to
   drop this MAY entirely, and convert it to a MUST NOT.

v) "5. Type of Certificates" says:

     logotypes MUST NOT be part of certification path validation or any
     type of automated processing.

   but this seems to be in conflict with requirements like "The
   background image MUST allow black text to be clearly read when placed
   on top of the background image." which would presumably be enforced
   by the certificate issuer via automated processing.

   Perhaps this is supposed to mean "any type of automated processing by
   the relying party" or "any type of automated processing during
   certificate validation"?

w) section 4.1 says:

     Avoid the use of otherLogos whenever possible.

   Is this a guidance for the subscriber, the issuer, the relying party,
   or future specifiers?  As a relying party, it's easy to avoid the use
   of otherLogos: just ignore them.  For the issuer, it's also easy to
   avoid their use, by refusing a certificate signing request that asks
   for one.  Both of these seem possible, but if the issuer and the
   relying party both act on this guidance, then there's no point in the
   subscriber even asking for one.  And that's possible too.  If any of
   those are taken seriously, then we might as well not specify
   otherLogos here.  But we do, so maybe it's saying to future document
   writers "please don't abuse the otherLogos mechanism by defining more
   logotypeType OIDs?  The way to defend against that is to ask IANA for
   a registry and ask for some kind of expert review before adding
   entries, but the draft doesn't do that either.  I don't know who
   should act on this guidance, or how they should behave differently
   having read it.

x) section 4.1 says:

    The LogotypeReference and LogotypeDetails structures explicitly
    identify one or more one-way hash functions employed to authenticate
    referenced image or audio objects. CAs MUST include a hash value for
    each referenced object, calculated on the whole object. CAs SHOULD
    include a hash value that computed with the one-way hash function
    associated with the certificate signature, and CAs MAY include other
    hash values. Clients MUST compute a one-way hash value using one of
    the identified functions, and clients MUST discard the logotype data
    if the computed hash value does not match the hash value in the
    certificate extension.

  This paragraph is doing too much work at once and mixing up (or
  forgetting about) what it's talking about.  LogotypeReference doesn't
  refer to "image or audio objects" -- it refers to a LogotypeData
  object.  But of course LogotypeDetails *does* refer to image or audio
  objects, but not to LogotypeData objects.  Likewise, the last sentence
  seems to imply that hash mismatch should trigger rejection only for
  LogotypeReferences ("discard the logotype data") but not for
  LogotypeDetails.

  Functionally, it also seems to imply that an object should be rejected
  when any hash doesn't match, but verification terminates successfully
  when any hash tried does match.  The implication here is that when
  multiple hashes are offered, and some of them are miscalculated, the
  rejection or acceptance will depend on the order in which the client
  tries the hashes.  the outcome would be more stable if the requirement
  was either "try all hashes you have an implementation for, accept if
  one of them matches" or "try all hashes you have an implementation
  for, reject if one of them doesn't match".  Then the outcome for a set
  of mismatched hashes will only vary based on which hashes are
  implemented, not on the implementation's choice of ordering.

y) section 6 ("Use in Clients") says:

     The logotype is to be displayed in conjunction with other identity
     information contained in the certificate. The logotype is not a
     replacement for this identity information.

   but section 4.4.3 ("Certificate Image Logotype") says:

     Applications providing a Graphical User Interface (GUI) to the
     certificate user MAY present a certificate image according to this
     standard in any given application interface, as the only visual
     representation of a certificate.

   These seem to be in direct contradiction to one another.

z) section 3 "logotype data" says:

     Compliant applications MUST NOT display more than one of the image
     objects and MUST NOT play more than one of the audio object for any
     logotype type at the same time.

     A client MAY simultaneously display multiple logotypes of different
     logotype types. For example, it may display one subject
     organization logotype while also displaying a community logotype,
     but it MUST NOT display multiple image variants of the same
     community logotype.

   but section 4.4.1 ("loyalty logotype") says "The logotype extension
   MAY contain more than one Loyalty logotype." and section 4.1 also
   says:

      If more than one Community logotype is present, they MUST be
      placed in order of preferred appearance. Some clients MAY choose
      to display a subset of the present community logos; therefore the
      placement within the sequence aids the client selection. The most
      preferred logotype MUST be first in the sequence, and the least
      preferred logotype MUST be last in the sequence.

   This is pretty unclear.  It sounds like multiple logotypes of the same
   type can be displayed, but also only one logotype of any given type
   can be displayed.

zz) section 4.4.2 says

    "The logotype extension MUST NOT contain more than one certificate
    background logotype."

   But section 4.4.3 doesn't offer any such constraint for the
   "Certificate Image" logotype.  Surely it should have the same
   constraint?

   While we're looking at it, does "logotype" in the cited sentence
   refer to a LogotypeDetails, a LogotypeData, a LogotypeImage, a
   LogotypeReference, some combination, or something else?

zzz) The draft should have distinct subsections for each logotype type,
     as well as for each otherType OID.  This will make it easier to
     refer to things in the future.

OK, i'm past out of letters, so i'll stop now.  Sorry for the volume of
this message.  I think this draft still needs a lot of work,
unfortunately.

I appreciate your working on it.

   --dkg

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 30 Mar 2022 13:46:51 +0200

Daniel,

Thank you for your great effort. I realize that you have spent quite
some time with this document review.

You even provide more information than I have the capability to handle
and fully understand right now. I have to go back and get to the details
later.

At this point after reading most of it on a shallow level, I just want
to do some quick remarks:

1) This is not a new design:

This is not a new standard we are designing. If I was designing this
extension today, my approach would be much more pragmatic and I would
simplify this quite a bit. But that is not a luxury we have. The purpose
of this update is to merge 2 existing RFC:s and basically get rid of
mandatory use of SHA-1. That's it.

Therefore, even how much I can agree on structural issues on the design,
we have to stick with it, or alternatively stop this update and let the
old RFC:s keep living instead.

2) Privacy concerns

On the privacy issues, I don't say that we should add some well thought
out sentences in a privacy considerations section. I personally do not
feel qualified enough to do it. I would welcome a few sentences that
would do the job that we could include in this draft.

3) Mime type for LogotypeData

I see no advantages of registering a mime type for this. As the expected
structure of the referenced data is known, and must be validated anyway
both i terms of content and structure, I'm not helped by learning what
mime type the server provides in HTML. I will simply extract the bytes
of the data, validate it against the hash and then attempt to parse it
as DER encoded LogotypeData.

Clients should disregard any mime type declarations and should not fail
because this header is not set as expected.

4) The rest.

I feel bad that I don't provide detailed responses to all the effort you
put into this, but I have to save that to later. Better to provide a
quick response than no response. But if any of my comments would change
the way you feel about things you just posted, it would make it easier
to respond to them.

Thanks

/Stefan

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 30 Mar 2022 15:20:36 -0400

> old RFC:s keep living instead.

Thanks for this clarification of the constraints.  I understand them,
and i'm not asking to actually change the structure of the wire format
objects.

I very much appreciate the move from SHA-1 to the digest algorithm used
in the signature -- that strikes me as the right approach.  But it also
occurs to me that i don't know whether all possible future signature
X.509 certificates will even have a "one-way hash function associated
with the certificate signature" -- maybe the draft can describe an
algorithmic way to identify the one-way hash algorithm in question?  I
mean, i know that a Certificate's signatureAlgorithm field
AlgorithmIdentifier OID of sha256WithRSAEncryption (1 2 840 113549 1 1
11) maps to id-sha256 (2 16 840 1 101 3 4 2 1).  But i don't know for
certain that all possible Certificate.signatureAlgorithm
AlgorithmIdentifiers have a well-defined hash.

Is there a straightforward mapping from the
Certificate.signatureAlgorithm AlgorithmIdentifier to
HashAlgAndValue.hashAlg AlgorithmIdentifier?

More work is needed here for a variety of different reasons that don't
touch the bits on the wire:

The document is internally-contradictory at several points; the text is
frequently unclear; the title and introduction don't offer a
straightforward description of what is provided; there are at least two
serious security considerations (the phishing attack that i outlined;
the risks of large attack surface of polymorphic image or audio
renderers) that are not discussed; there are multiple privacy
considerations that are not discussed; the examples are not easy to use
to confirm interoperability.

An update represents the opportunity to resolve *all* of these issues
without affecting the bits on the wire at all.  The point of these
specfications is to provide clarity for implementers so that we get a
robust, secure, interoperable ecosystem, right?

> would do the job that we could include in this draft.

I don't think that a few sentences are sufficient to address the privacy
considerations raised by these mechanisms in today's network
environment.  Some text and some framing will need to change at the very
least.

If it turns out that a clearer understanding of the privacy concerns
happens to also spur ideas for a backward-compatible extension of the
wire format to make it cheaper/easier to embed the media directly, that
would be an elegant outcome but i won't hold my breath on that.

> because this header is not set as expected.

In this case, i agree with you -- the client can probably ignore the
server's offered media type, or at least accept an
application/octet-stream media type.

But if the server says "this is an image/png" when you're expecting a
DER-encoded LogotypeData, shouldn't a defensively-programmed system
reject the HTTP response?

That doesn't mean that we shouldn't register a media type for this
specific format, though.  Media type registration is a mutual aid sort
of situation.  For example, there may be implemetnations of other
protocols that expect some other data types, and they themselves might
do ugly things if they receive a DER-encoded LogotypeData instead.

By defining and encouraging an explicit label of what sort of data the
HTTP server is emitting, we can help isolate these protocols from each
other.

Is there a specific objection to registering the media type?  As far as
i can tell, media type registrations have no cost, and this looks to me
like a very well-defined binary format, with a clear reference that the
media type registration can point to.  what would be the downside?

> the way you feel about things you just posted, it would make it easier

I understand, and i don't expect repsonses or fixes to each point all at
once-- there are a lot of issues that need fixing, unfortunately, and
it's easy for some to get lost in this back-and-forth format, despite my
trying to give each distinct issue a separate identifier.

Anyway, i appreciate your giving a prompt response, and i'm game to help
work through the details if you're interested in my help.

If you want to make collaboration easier, i'll reiterate my
recommendation for revision control of the document's markdown source
and an issue tracker.

I set up https://gitlab.com/dkg/lamps-rfc3709bis and populated the repo
with the markdown source from the first three drafts as an example of
how that kind of collaboration could work if you're interested.  Pushes
to the main branch there will automatically update a putative "editor's
copy" at https://dkg.gitlab.io/lamps-rfc3709bis/ after a few minutes.

If you want to use this repo, please let me know what your gitlab handle
is and i'll add you as an owner to that group.  I can then work on
transferring the points i raised into specific issues, which we can then
try to fix.

If you have a different way that you'd prefer to keep track of
outstanding issues and work through their fixes, let me know and i can
try to populate it with the concerns that i've found.

All the best,

    --dkg