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

[Alanna Paloma <[e-mail]>]

Hi Russ,

Thank you for your reply. We have updated the files accordingly. Please note that there are 2 queries that have not yet been addressed:

1) 
>> Also, are "issuer logotype" and "subject logotype" correct? Or should these be
>> updated to "issuer organization logotype" and "subject organization logotype",
>> respectively?

2)
>> 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.


The files have been posted here (please refresh):
 https://www.rfc-editor.org/authors/rfc9399.xml
 https://www.rfc-editor.org/authors/rfc9399.txt
 https://www.rfc-editor.org/authors/rfc9399.html
 https://www.rfc-editor.org/authors/rfc9399.pdf

The relevant diff files have been posted here:
 https://www.rfc-editor.org/authors/rfc9399-diff.html (comprehensive diff)
 https://www.rfc-editor.org/authors/rfc9399-auth48diff.html (AUTH48 changes)

Please review the document carefully and contact us with any further updates you may have.  Note that we do not make changes once a document is published as an RFC.

We will await approvals from each party listed on the AUTH48 status page below prior to moving this document forward in the publication process.

For the AUTH48 status of this document, please see:
 https://www.rfc-editor.org/auth48/rfc9399

Thank you,
RFC Editor/ap

> On Apr 7, 2023, at 12:40 PM, Russ Housley <[e-mail]> wrote:
> 
> 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
>