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

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

On 2022-03-30 00:17, Daniel Kahn Gillmor wrote:
> Hi Stefan--
>
> Thanks for your followup!  comments inline.
>
> On Mon 2022-03-28 22:38:29 +0200, Stefan Santesson wrote:
>> 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.
> 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.
>
>> Obviously things becomes much easier if all data is embedded, but this
>> 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.
>
>> 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.
> 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.
>
>>>  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.
> This point didn't seem to get a response.  can you comment on it?  Did i
> misunderstand the draft?
>
>>> 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).
>> The text says: "Both direct and indirect addressing accommodate
>> 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?
>
>>>  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.
>> 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.
> 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.
>
>>>  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?
>> 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
> 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.
>
>>>  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.
>> I don't feel qualified to answer this one. If there is something 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
>
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm