[lamps] Mohamed Boucadair's Discuss on draft-ietf-lamps-rfc7030-csrattrs-20: (with DISCUSS and COMMENT)

[Mohamed Boucadair via Datatracker <[e-mail]>]

Mohamed Boucadair has entered the following ballot position for
draft-ietf-lamps-rfc7030-csrattrs-20: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc7030-csrattrs/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Hi Michael, Owen, David, and Dan,

Thanks for the effort put into this specification.

I have an easy-to-fix DISCUSS and some few comments.

# DISCUSS

## Conflict between registered IANA value vs ASN Module

Section 7 has the following:

   *  One (TBD2) from the SMI Security for S/MIME Attributes
      (1.2.840.113549.1.9.16.2) registry for the Certification Request
      Information Template (id-aa-csrinfo) attribute; see Appendix A

while Appendix A has:

   id-aa-certificationRequestInfoTemplate OBJECT IDENTIFIER ::=
     { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
       smime(16) aa(2) csrinfo(TBD2)

Please check.

As I’m there, please fix the following:

OLD: IANA is asked to allocate two new Object Identifiers

NEW: IANA is asked to allocate three new Object Identifiers


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

# Incomplete citations

CURRENT:
   As a result of some implementation challenges, it came to light that
   this particular way of using the CSR attributes was not universally
   agreed upon, and it was suggested that it went contrary to section
   2.6.

   Section 2.6 says that the CSR attributes "can provide additional
   descriptive information that the EST server cannot access itself".
   This is extended to describe how the EST server can provide values
   that it demands to use.

Please explicit this is about section 2.6 of RFC 7030.

There other similar occurrences in the document that need to be fixed.

#

CURRENT:
   Also, section 4.5.2 is extended to clarify the use of the existing
   ASN.1 syntax [X.680][X.690].  This covers all uses and is fully
   backward compatible with existing use.

* s/ section 4.5.2/section 4.5.2 of [RFC7030]

* Why X.690 is not listed as normative as X.680?

* “all uses”: how can claim this?

# mixing spec vs. use example in Section 3.2

CURRENT:
   With this understanding, the needs of [RFC8994] and [RFC8995] are
   satisfied with no change to the bits on the wire.

Do we need to have this here?

# Section 3.3

CURRENT:
   *  The 'subject' field has been made OPTIONAL.  It MUST be present if
      the server places any requirements on the RDNs of the subject
      name;

Can we cite an example of requirement on RDNs?

# Legacy

CURRENT:
   Legacy servers MAY continue to use the [RFC7030]-style unstructured
   list of attribute/value pairs, and MAY also include the template
   style described in {#csrtemplate}.

Does the second MAY apply for a “legacy” server?

(nit) please fix the md reference. There are other similar broken citation in the doc.

# Consider moving section with examples to an appendix.

Cheers,
Med