Re: [auth48] AUTH48: RFC-to-be 9399 <draft-ietf-lamps-rfc3709bis-10> for your review

[Russ Housley <[e-mail]>]

Dear RFC Editor:

Thanks for the editorial improvements.

> 1) <!-- [rfced] Please insert any keywords (beyond those that appear in the
> title) for use on https://www.rfc-editor.org/search. -->

The keywords for RFC 3709 and this RFC should be the same.

> 2) <!-- [rfced] FYI - While we understand RFCs 3709 and 6170 were published with
> the some of the text we are questioning below, the questions are aimed at
> making the text as correct as possible. We have tried to indicate when
> such text appeared in RFCs 3709 and 6170. Please review carefully.
> -->

Thanks for the heads up.  No response needed.

> 3) <!-- [rfced] May we update "rather" to "instead" and include a semicolon? Note
> that this text appears in RFC 3709.
> 
> Original:
>   Very few consumers
>   actually read all terms and conditions they agree to in accepting a
>   service, rather they commonly act on trust derived from previous
>   experience and recognition.
>   ...
>   If the client is unable to support a provided logotype, the
>   client MUST NOT report an error, rather the client MUST behave as
>   though no logotype extension was included in the certificate.
> 
> Perhaps:
>   Very few consumers
>   actually read all terms and conditions they agree to in accepting a
>   service; instead, they commonly act on trust derived from previous
>   experience and recognition.
>   ...
>   If the client is unable to support a provided logotype, the
>   client MUST NOT report an error; instead, the client MUST behave as
>   though no logotype extension was included in the certificate.
> -->

I am fine with this change.

> 4) <!-- [rfced] We updated this sentence as shown below (i.e., updated
> "LogoTypeData" to "LogotypeData" to match usage in the rest of the
> document, added "the" before "referenced LogoTypeData", and removed "the"
> before "HTTP" and "HTTP with TLS). Please let us know any objections.
> 
> Original:
>   Clients MUST
>   support retrieval of referenced LogoTypeData with the HTTP [RFC9110]
>   and the HTTP with TLS [RFC8446], or subsequent versions of these
>   protocols.
> 
> Updated:
>   Clients MUST
>   support retrieval of the referenced LogotypeData with HTTP [RFC9110],
>   HTTP with TLS [RFC8446], or subsequent versions of these
>   protocols.
> -->

Thanks for catching this mistake.  "LogotypeData" is correct.

> 5) <!-- [rfced] We are having difficulty parsing this sentence, specifically "or
> claims its issuer and community logotypes". Please review and let us know
> how to update. Note that this sentence appeared in RFC 3709.
> 
> Original:
>   The policies and practices
>   employed by the issuer to check subject organization logotypes or
>   claims its issuer and community logotypes is outside the scope of
>   this document.
> 
> Perhaps:
>   The policies and practices
>   employed by the issuer that check subject organization logotypes or
>   claims about its issuer and community logotypes are outside the scope of
>   this document.
> -->

Thanks.  Your wording is much more clear.

> 6) <!--[rfced] We see "logotype" but not "logotype type" in Section 1.1. Please
> review and let us know if updates are needed.
> 
> In addition, please review the use of "logotype type" throughout the document
> (this phrase was also used in RFC 3709). Is this correct, or can just
> "logotype" be used?

No.  There are three standard logotype types: community, issuer organization, and subject organization, and there is a mechanism to define other logotype types.  This is covered in Section 2.
> 
> 
> Original:
>   "Logotype type" is
>   defined in Section 1.1, and it refers to the type of entity or
>   affiliation represented by the logotype, not the of binary format of
>   the image or audio.
> -->

I do not think that any changes are needed.

> 7) <!-- [rfced] Please review "name resolution traffic associated fetching". How
> may we update for clarity?
> 
> Original:
>   In addition, the use of an encrypted DNS mechanism, such as DoT
>   [RFC7858] or DoH [RFC9230], hides the name resolution traffic
>   associated fetching remote logotype objects from third parties.
> -->

Suggestion:

   In addition, the use of an encrypted DNS mechanism, such as DoT
   [RFC7858] or DoH [RFC9230], hides the name resolution traffic,
   which is usually a first step in fetching remote logotype objects.

> 8) <!-- [rfced] Questions about IANA Considerations
> 
> a) IANA assigned "id-mod-logotype-2022" (107) in the "SMI Security for PKIX
> Module Identifier" per the following:
> 
> Original (IANA Considerations):
>   For the new ASN.1 Module in Appendix A.2, IANA is requested to assign
>   an object identifier (OID) for the module identifier.  The OID for
>   the module should be allocated in the "SMI Security for PKIX Module
>   Identifier" registry (1.3.6.1.5.5.7.0).
> 
> Link to registry:
> https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.0
> 
> However, the ASN.1 module in Appendix A.2 uses "id-mod-logotype", which is
> already listed in the registry as value 22. We updated the module in Appendix
> A.2 to use "id-mod-logotype-2022(107)". Please review carefully and let us
> know if this is incorrect.
> 
> Original (Appendix A.2):
>   <CODE BEGINS>
>   LogotypeCertExtn
>     { iso(1) identified-organization(3) dod(6) internet(1)
>       security(5) mechanisms(5) pkix(7) id-mod(0)
>       id-mod-logotype(TBD) }
> 
> Updated:
>   <CODE BEGINS>
>   LogotypeCertExtn
>     { iso(1) identified-organization(3) dod(6) internet(1)
>       security(5) mechanisms(5) pkix(7) id-mod(0)
>       id-mod-logotype-2022(107) }

Even better:

   <CODE BEGINS>
   LogotypeCertExtn-2022
     { iso(1) identified-organization(3) dod(6) internet(1)
       security(5) mechanisms(5) pkix(7) id-mod(0)
       id-mod-logotype-2022(107) }

> b) FYI: We updated the <artwork> block in the IANA Considerations section to
> be three separate tables.
> -->

This looks fine to me.

> 9) <!--[rfced] [SVGT] has been updated by a new version (see
> https://www.w3.org/TR/2008/REC-SVGTiny12-20081222/). Should this
> reference be updated to point to the newest version?
> 
> Note that text in the document references Sections 14.1.4 and 15.2 of [SVGT];
> these section references seem to be correct for the new version.
> 
> Original:
>   [SVGT]     World Wide Web Consortium, "Scalable Vector Graphics (SVG)
>              Tiny 1.2 Specification", W3C PR-SVGTiny12-20081117, 17
>              November 2008,
>              <https://www.w3.org/TR/2008/PR-SVGTiny12-20081117>.
> -->	      

Using the newer version seems fine to me.  I'll let my co-authors raise the alarm if they know otherwise.

> 10) <!-- [rfced] XML formatting
> 
> a) We have updated <artwork> to <sourcecode> in the appendices and in
> Sections 4.1, 4.3, 4.4.1, 4.4.2, and 4.4.3 (we left <artwork> in
> Section 7). Please let us know if the "type" attribute should be set for
> these sourcecode elements. If the current list of preferred values for
> "type" (https://www.rfc-editor.org/materials/sourcecode-types.txt) does
> not contain an applicable type, then feel free to suggest a new one.
> Also, it is acceptable to leave the "type" attribute not set. 

This seems fine to me.
Section 4.1: the type is ASN.1
Section 4.3: the type is ABNF
Section 4.4: the type is ASN.1
Section:4.4.2: the type is ASN.1
Section 4.4.3: the type is ASN.1

> b) Please review whether any of the notes in this document
> should be in the <aside> element. It is defined as "a container for 
> content that is semantically less important or tangential to the 
> content that surrounds it" (https://authors.ietf.org/en/rfcxml-vocabulary#aside).

I think that the NOTE text at the end of Section 4.3 and the NOTE after Table 1 could be marked as <aside>.

> c) FYI - We used a bulleted list in the Acknowledgments section. We wanted to
> avoid multiple Acknowledgements sections since the section is not
> numbered. Note that this list format was also used in RFC 8504.
> -->	

This seems fine to me.

> 11) <!--[rfced] Terminology
> 
> a) If no objections, we will update instances of "MIME type" and "MIME media
> type" to "media type". The "Media Types" registry
> (https://www.iana.org/assignments/media-types/) notes:
> 
>   [RFC2046] specifies that Media Types (formerly known as MIME types) and Media
>   Subtypes will be assigned and listed by the IANA.

Yes, please use "media type" throughout the document.

> b) Should "CA" be expanded as "certificate authority" or "certification
> authority"?

Please use "Certification Authority".  This is the term used in RFC 5280.

> c) We note inconsistencies in the terms below throughout the text.
> Should these be uniform? If so, please let us know which form is
> preferred.
> 
> certificate issuer vs. Certificate Issuer
>   Note: This term is lowercase is RFC 3709 and capitalized in RFC 6170. Also note
>         that we will apply the decision here to "Certificate Context" and "Certificate
>         Subject" as these are used in similar contexts.

Lower case is fine.

> end entity certificate vs. end-entity certificate
>   Note: Both forms were used in RFC 3709. The open form is used in RFC 5280,
>         but the hyphenated form is more common in the RFC Series.

Please align with RFC 5280; use "end entity".

> Logotype certificate extension vs. logotype certificate extension vs. logotype extension

Please use "logotype certificate extension"

> d) For consistency, we used lowercase for the names of logotypes as most
> instances in the document were lowercase:
> 
> loyalty logotype
> certificate image logotype
>   Note: We also used lowercase in context of "certificate image object identifier".
> community logotype
> issuer organization logotype
> subject organization logotype
> issuer logotype 
> subject logotype
> 
> Also, are "issuer logotype" and "subject logotype" correct? Or should these be
> updated to "issuer organization logotype" and "subject organization logotype",
> respectively?

This seems fine to me.

> e) Should "issuer" here be updated to "issuer organization"? Or is the current
> correct?
> 
> Original:
>   Implementations that simultaneously display multiple logotype types
>   (subject organization, issuer, community, or other), MUST ensure that
>   there is no ambiguity as to the binding between the image and the
>   type of logotype that the image represents.
> -->

Yes.  The three standard logotype types are: community, issuer organization, and subject organization.

> 12) <!-- [rfced] Please review the "Inclusive Language" portion of the online
> Style Guide
> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let
> us know if any changes are needed.
> 
> For example, please consider whether "black" should be updated.
> 
> In addition, please review the usage of pronouns indicating gender (e.g.,
> "his", "her", "she"), and let us know if you would like to use gender-neutral
> text (e.g., "its", "their") instead.  Below is the only instance we see in the
> document. May we change "his" to "their"?
> 
> Original:
>   This situation is comparable to a person selecting a suitable plastic
>   card from his wallet.  
> -->

Suggestion:

   This situation is comparable to a person selecting a suitable plastic
   card from their wallet.

Russ