Subject: Re: [lamps] RFC 3709

From: Corey Bonnell <[email-masked]>
Date: Mon, 3 Jan 2022 15:04:39 +0000

> But, as I said, I don't know enough about how 3709 is really used.

If the application that employs Logotypes that Russ mentioned in the initial
message of this conversation is the same one I have in mind, then Logotype
images
(specifically, SVGs as described in RFC 6170, section 5.2) in this
application are embedded directly in the
certificate using the data URI scheme (RFC 6170, section 4). There are no
external network connections required for certificate-consuming software to
fetch the image, and the signature over
the tbsCertificate structure provides integrity protection. Given this, the
selection of hash algorithm in the LogotypeDetails is not relevant to this
particular application.

Nonetheless, it would be useful to update the MTI algorithm to SHA-256 and
the MTI protocols in the event other applications do not use "data" URI
embedding.

Thanks,
Corey

-----Original Message-----
From: Spasm <[email-masked]> On Behalf Of Michael Richardson
Sent: Thursday, December 23, 2021 12:52 PM
To: Phillip Hallam-Baker <[email-masked]>
Cc: LAMPS WG <[email-masked]>; Rich Salz <[email-masked]>; Russ Housley
<[email-masked]>
Subject: Re: [lamps] RFC 3709

Phillip Hallam-Baker <[email-masked]> wrote:
    > Definitely not be enough for a 'MUST use HTTPS in the cert' but 'MUST
    > certainly support for resolution'. After all, it is unlikely anyone
using
    > the logotype extension doesn't have TLS in their stack.

Unfortunately, we don't have a URL scheme that says, "do some privacy", but
don't force authentication.  if we did, then I'd ask for that.

And while we might the *right* TLS stack (the one with TLS1.3...), we might
not have the right anchors.  But, as I said, I don't know enough about how
3709 is really used.

--
Michael Richardson <[email-masked]>, Sandelman Software Works  -=
IPv6 IoT consulting =-

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 6 Jan 2022 10:46:33 +0100

Hi,

I have some questions and suggestions:

When LogotypeData is included directly in the certificate, can you
confirm that the direct addressing method is used?

That is. Confirm that LogotypeInfo contains LogotypeData and not
LogotypeReference.

Given that direct addressing is used and LogotypeInfo contains
LogotypeData, then I fully support inclusion of the logotype image
directly by having logotypURI containing a data URI. 

I do not like to allow data URI as alternative for refStructURI in
LogotypeReference. In such cases implementers should use the direct
method instead.

Hash:

I support removing SHA-1, but I would prefer not to replace that with
mandatory SHA 256. Inclusion of hash includes the hash OID, so we don't
need to point out any particular hash for that reason. I would rather
replace this with RECOMMEND to use the same hash that was used to sign
the certificate. That would be the most logical and future proof
solution. This way you can always process this hash if you can verify
the certificate and the level of security will always match the
certificate signature.

File extension:

I would remove the recommendation to use any specific file extension for
LogotypeData referenced using refStructURI. The only thing you are
interested in is the hashed bytes and possibly the new LogotypeData
MimeType as Content-Type. Any header information carrying a file name or
file extension would be totally redundant to the certificate using
application in any case. I would suggest updating that text sying
something like this (using appropriate language):

"The resource located using the URI (refStructURI) MUST be available
using a HTTP GET request. The response MUST return the exact bytes that
are hashed by the refStructHash value and SHOULD contain a Content-Type
header indicating the LTD mimetype (se section x)."

I'm fine with all other suggestions.

/Stefan

Den 2022-01-03 kl. 16:04, skrev Corey Bonnell:
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm

---

From: Russ Housley <[email-masked]>
Date: Thu, 6 Jan 2022 13:46:03 -0500

> LogotypeReference. In such cases implementers should use the direct

My reading of RFC 6170 is that the data: scheme should be used with direct, not indirect.  It says:

   The certificate image otherLogos type defined in this specification
   and all logotype types defined in RFC 3709 [RFC3709] MAY be stored
   within the logotype extension using the "data" URL scheme defined in
   RFC 2397 [RFC2397] if the logotype image is provided through direct
   addressing, i.e., the image is referenced using the LogotypeDetails
   structure.

That seems consistent with your preference.

This raises a bigger question in my mind.  Should rfc3709bis cover both RFC 3709 and RFC 6170?  If so, the discussion of Embedded Images and Certificate Image Formats would be added to the document.

> the certificate and the level of security will always match the

I think this is a good idea.  Maybe something like:

   The LogotypeReference and LogotypeDetails structures explicitly
   identify one or more one-way hash functions employed to authenticate
   referenced data files.  CAs MUST include a hash value for each
   referenced file, calculated on the whole file.  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.

> header indicating the LTD mimetype (se section x)."

Errata ID 2325 call for the registration of a media type for the .LTD file extension.  So, the resolution of this errata is either registering a new media type (e.g., pkix-ltd) or the removal of the recommended file extension.

I have a mild preference for the registration, but Stefan is correct that the content of the file is fully specified.  RFC 3709 says:

   When using indirect addressing, the URI (refStructURI) pointing to
   the external data structure MUST point to a binary file containing
   the DER encoded data with the syntax LogotypeData.  The referenced
   file name SHOULD include a file extension of "LTD".

Russ

---

From: Corey Bonnell <[email-masked]>
Date: Fri, 7 Jan 2022 16:30:11 +0000

Hi Russ,
Comments inline.

This matches my understanding. I just checked and confirmed that the
certificates in this application are using the direct method, which is in
alignment
with this passage.

> This raises a bigger question in my mind.  Should rfc3709bis cover both
RFC 3709 and RFC 6170?  If so, the discussion of Embedded Images and
Certificate Image Formats would be added to the document.

Yes, I think that would be useful.

I think this looks good; the only comment I have is that I'm not entirely
sure if certificate-consuming applications are computing and matching the
hash of the logotype data if it's encoded as a data URI, as the certificate
signature itself provides integrity protection in this case. Perhaps relax
to a SHOULD or MAY in this case? I don't feel strongly either way.

Thanks,
Corey

-----Original Message-----
From: Russ Housley <[email-masked]> 
Sent: Thursday, January 6, 2022 1:46 PM
To: Stefan Santesson <[email-masked]>; Corey Bonnell
<[email-masked]>
Cc: Michael Richardson <[email-masked]>; Phillip Hallam-Baker
<[email-masked]>; LAMPS WG <[email-masked]>; Rich Salz
<[email-masked]>
Subject: Re: [lamps] RFC 3709

> LogotypeReference. In such cases implementers should use the direct 

My reading of RFC 6170 is that the data: scheme should be used with direct,
not indirect.  It says:

This raises a bigger question in my mind.  Should rfc3709bis cover both RFC
3709 and RFC 6170?  If so, the discussion of Embedded Images and Certificate
Image Formats would be added to the document.

> mandatory SHA 256. Inclusion of hash includes the hash OID, so we 
> don't need to point out any particular hash for that reason. I would 
> rather replace this with RECOMMEND to use the same hash that was used 
> to sign the certificate. That would be the most logical and future 
> proof solution. This way you can always process this hash if you can 
> verify the certificate and the level of security will always match the 
> certificate signature.

> File extension:
> 
> I would remove the recommendation to use any specific file extension 
> for LogotypeData referenced using refStructURI. The only thing you are 
> MimeType as Content-Type. Any header information carrying a file name 
> or file extension would be totally redundant to the certificate using 
> using a HTTP GET request. The response MUST return the exact bytes 
> that are hashed by the refStructHash value and SHOULD contain a 
> Content-Type header indicating the LTD mimetype (se section x)."

Errata ID 2325 call for the registration of a media type for the .LTD file
extension.  So, the resolution of this errata is either registering a new
media type (e.g., pkix-ltd) or the removal of the recommended file
extension.

I have a mild preference for the registration, but Stefan is correct that
the content of the file is fully specified.  RFC 3709 says:

Russ

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 10 Jan 2022 11:17:29 +0100

Corey,

The hash value is not optional in the ASN,1 module.

Besides that, I tend to prefer the simpler implementation logic and
would avoid logic like (must .. but not if ..) unless it really brings
substantial value.

I would also prefer to not talk about "file". We are talking about
binary data. Whether it is stored in a file or not is irrelevant. In
particular if it is embedded in a data URI. With the data URI scheme
there is no way to include file attributes (file name), just media type
and encoding.

/Stefan

---

From: Russ Housley <[email-masked]>
Date: Mon, 10 Jan 2022 18:12:52 -0500

RFC 3709 has JPEG and GIF as the mandatory-to-implement image formats.

RFC 6170 also specified PDF, SVG, and PNG, but just for the certificate image "other" logotype.

I do not think we want to make all five of these mandatory-to-implement.

What do other think?

Russ

> On Jan 7, 2022, at 11:30 AM, Corey Bonnell <Corey.Bonnell=[email-masked]> wrote:
> 
> Hi Russ,
> Comments inline.
>

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 11 Jan 2022 00:57:38 +0100

Russ,

That is a tough one. Mostly because I'm genuinely unsure what it would
mean to be compliant to this requirement in the context of this standard.

Are you compliant just if you pass the image on to the upper layer
application that produce some kind of UI, or do you have to render the
image to be compliant?

If I would say something I think I would stick to the pure image formats
that are supported by the HTML img tag in common browsers.

Common image formats supported in most browsers are APNG, GIF, ICO,
JPEG, PNG and SVG. Of these I think I would stick with GIF, JPEG, PNG
and SVG.

I would leave PDF out of this. The rationale for this is that the other
formats are pure formats of an image, while PDF is a document format
which is incredibly complex, and as such, is not supported in an HTML
img tag.

For SVG, you have to be careful, as it may contain links to external
content. Here you need some kind of additional writing which we did
provide in RFC 6170 if I recall it correctly.

/Stefan

---

From: Russ Housley <[email-masked]>
Date: Mon, 10 Jan 2022 22:32:26 -0500

Stefan:

Yes, there are some constrains in RFC 6170.  Also, RFC 3709 says that GIF cannot include animation.

I think that JPEG and GIF should remain; they are in RFC 3709.

I think that SVG should be included because that is what people are uing in practice.

Can we make PDF and PNG and any other image format MAY support?

Russ

> On Jan 10, 2022, at 6:57 PM, Stefan Santesson <[email-masked]> wrote:
> 
> Russ,
>

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 11 Jan 2022 16:28:10 +0100

The only thing I would change is to also make PNG mandatory.

According to W3Techs
(https://w3techs.com/technologies/overview/image_format) PNG is the most
common format on the web today, appearing in 80% of all web pages, This
is followed by JPG (74.5%) and SVG (41.9%) with GIF trailing at (20.9%).

Other than those, no format exceeds 3%, so I think those are the ones to
MUST support at this stage.

/Stefan

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 11 Jan 2022 15:42:59 +0000

On 1/10/22, 6:14 PM, "Russ Housley" <[email-masked]> wrote:
    RFC 3709 has JPEG and GIF as the mandatory-to-implement image formats.
    RFC 6170 also specified PDF, SVG, and PNG, but just for the certificate image "other" logotype.
    I do not think we want to make all five of these mandatory-to-implement.

I think someone should ask the browser folks and/or HTTP WG, for their views.

---

From: Ryan Sleevi <[email-masked]>
Date: Tue, 11 Jan 2022 11:08:30 -0500

> I think someone should ask the browser folks and/or HTTP WG, for their

I'm not aware of any discussions by browsers to support logotype; in
general, the view has been rather negative.

Certainly, from an "attack surface" viewpoint, it should be telling that
both SVG and PDF have their own discrete display paths in the web platform,
different from GIF, JPG, and PNG. In part, this is due to their significant
complexities resulting from being more than just a display format, but
having complex rendering engines with network connectivity, forms, a
document object model, self-referential data streams, etc. That said,
formats like PNG, JPG, and GIF are still treated by a number of browsers as
"lower-trust" - i.e. decoding is not performed within privileged processes,
and instead treated through sandboxes. This, I think, further speaks to why
it's unlikely to see display paths integrated, particularly in trusted UI
surfaces.

And this is ignoring the prevalence of newer image types, which are
preferred due to the greater balance of compression vs accuracy (e.g. the
WebP image format)

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Tue, 11 Jan 2022 16:14:41 +0000

I say PNG is used much more than SVG - so, perhaps, PNG - MUST, and SVG - MAY.

Ambivalent on PDF.
-- 
V/R,
Uri

On 1/10/22, 22:33, "Spasm on behalf of Russ Housley" <[email-masked] on behalf of [email-masked]> wrote:

    Stefan:

    Russ

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 11 Jan 2022 16:50:43 +0000

*   I'm not aware of any discussions by browsers to support logotype; in general, the view has been rather negative.

I am more interested in what image formats are most common on the web and the rest of your note is a good example of the kind of information I was seeking. Thanks.

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 11 Jan 2022 16:52:30 +0000

>    I say PNG is used much more than SVG - so, perhaps, PNG - MUST, and SVG - MAY.

I am okay with that.

>    Ambivalent on PDF.

Strong no on PDF.

---

From: Russ Housley <[email-masked]>
Date: Tue, 11 Jan 2022 11:57:30 -0500

SVG is the one that is actually being used.  It seems like the wrong path to push the folks that are actually implementing away.

Russ

> On Jan 11, 2022, at 11:14 AM, Blumenthal, Uri - 0553 - MITLL <[email-masked]> wrote:
>

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 11 Jan 2022 19:40:14 +0100

Russ, I agree.

For this purpose, SVG has several major advantages:

 1. Its scalable
 2. Relative small size
 3. Can easily be customizable with respect to embedded text to match
    information in the certificate.

So I would hate to drop SVG.

I'm aware of the reluctance from web browsers to display these images.
However display in the protected UI of web browsers is not the only use
case.

---

From: Corey Bonnell <[email-masked]>
Date: Wed, 12 Jan 2022 14:54:30 +0000

> SVG is the one that is actually being used.  It seems like the wrong path to push the folks that are actually implementing away.

I agree, SVG is the image type in use today so if we are to mandate a specific type, it should be SVG.

To provide a bit more context on the use of SVG,  the profile of the SVG Tiny 1.2 specification defined in https://datatracker.ietf.org/doc/html/draft-svg-tiny-ps-abrotman-01.html is used. I believe this specification largely matches the restrictions on the allowed SVG profile defined in RFC 6170, section 5.2 but provides a more rigorous definition of the profile along with a RNC schema for validation. We may want to consider referencing this document instead of explicitly listing out the restrictions on the SVG profile in section 5.2 for "script" elements, etc.

On a related point, section 5.2 of RFC 6170 defines the following requirement for SVG:
"The XML structure in the SVG file MUST use <LF> (linefeed 0x0A) as the end-of-line (EOL) character when calculating a hash over the SVG image."

My understanding is that is this is not a restriction on the encoding of SVGs (i.e., Windows line endings are allowed), but the XML data must be normalized using UNIX line endings when calculating the hash value. However, to simplify the implementation of certificate-consuming applications, perhaps it would be better to require normalization to UNIX line-endings for encoding as well. Concretely, change that passage to:

"The XML structure in the SVG file MUST use <LF> (linefeed 0x0A) as the end-of-line (EOL) character."

Thanks,
Corey

-----Original Message-----
From: Spasm <[email-masked]> On Behalf Of Russ Housley
Sent: Tuesday, January 11, 2022 11:58 AM
To: Uri Blumenthal <[email-masked]>
Cc: LAMPS WG <[email-masked]>
Subject: Re: [lamps] RFC 3709

Russ

>> That is a tough one. Mostly because I'm genuinely unsure what it 
>> would mean to be compliant to this requirement in the context of this standard.
>> 
>> application that produce some kind of UI, or do you have to render 
>> the image to be compliant?
>> 
>> If I would say something I think I would stick to the pure image 
>> formats that are supported by the HTML img tag in common browsers.
>> 
>> I would leave PDF out of this. The rationale for this is that the 
>> other formats are pure formats of an image, while PDF is a document 
>> format which is incredibly complex, and as such, is not supported in 
>> an HTML img tag.
>>

---

From: Russ Housley <[email-masked]>
Date: Wed, 12 Jan 2022 16:01:00 -0500

Corey:

Would the requirement of baseProfile="tiny-ps" be a problem?  I would not want a certificate that was issued in conformance with RFC 6170 to be rejected because it did not claim to conform to the tiny-ps profile.

Russ

> On Jan 12, 2022, at 9:54 AM, Corey Bonnell <Corey.Bonnell=[email-masked]> wrote:
>

---

From: Corey Bonnell <[email-masked]>
Date: Thu, 13 Jan 2022 19:53:26 +0000

Hi Russ,
> Would the requirement of baseProfile="tiny-ps" be a problem?  I would not want a certificate that was issued in conformance with RFC 6170 to be rejected because it did not claim to conform to the t…

For the certificates issued for this application, specifying the baseProfile attribute with "tiny-ps" as the value would not pose an issue. However, to your point, introducing this requirement (along with the use of UNIX line endings for encoding) may break backwards compatibility for other applications that encode SVGs in Logotypes. However, I'm unaware of any other implementations that embed SVGs in Logotypes, so I'm unsure if we need to consider retaining backwards compatibility to account for these unknown implementations.

If anyone is aware of other implementations, that would be very helpful to help make an informed decision here.

Thanks,
Corey

-----Original Message-----
From: Russ Housley <[email-masked]> 
Sent: Wednesday, January 12, 2022 4:01 PM
To: Corey Bonnell <[email-masked]>
Cc: LAMPS WG <[email-masked]>
Subject: Re: [lamps] RFC 3709

Corey:

Russ

>>> JPEG, PNG and SVG. Of these I think I would stick with GIF, JPEG, 
>>> PNG and SVG.
>>>