Re: [lamps] Murray Kucherawy's No Objection on draft-ietf-lamps-lightweight-cmp-profile-18: (with COMMENT)

["Brockhaus, Hendrik" <[e-mail]>]

Murray

Last week the co-authors and I managed to align on how to address your
comments. Please see our proposal for an updated version of the draft below.
I hope these generic changes sufficiently addresses your comment
sufficiently. Changing the entire document instead, will be a mayor effort.

@Roman, I hope these changes are appropriate after IESG review. If you have
any concerns, please let me know.

Hendrik

> Von: Spasm <[e-mail]> Im Auftrag von Brockhaus, Hendrik
> 
> Murray
> 
> Thank you for your review and for your comments.
> I will need to discuss your generic comment on the usage of SHOULD with the
> co-authors and will come back to you with a response.
> Maybe the scope of the document must be explained a bit more. This profile on
> the one hand intends to reduce the flexibility of CMP to the generic needs of
> automated certificate management of machine end entities. On the other hand,
> it is still a framework that is supposed to be further profiled by those having a
> specific use case or scenario in mind, for example like by 3GPP/ETSI or UNISIG.
> Therefore, there is still some freedom to serve the needs of the final target
> environment.
> 
> Hendrik
> 
> > Von: Murray Kucherawy via Datatracker <[e-mail]>
> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > Section 1.7 uses a SHOULD NOT before that expression is defined in Section 1.9.

[HB] I will move former Section 1.9 to position 1.2.
Doing this I will also switch the order of Sections 1.5 and 1.6.

> >
> > The bulk of the SHOULDs in this document would benefit from review and possible
> > tuning.  SHOULD presents a choice for the implementer; it would be helpful to
> > include with that choice some guidance about when one might legitimately
> > deviate from what's stated.  If SHOULD is being used as "you really oughta do
> > this, but you don't really have to and things will interoperate just fine", it
> > doesn't deserve SHOULD; if what you mean is "yes you have to do this from now
> > on, but we're retaining backward compatibility here" then it should say that
> > explicitly.  In other cases, I wonder if you don't really mean MUST.
> >
> > For instance, in 3.1, you have this:
> >
> >     -- SHOULD contain a name representing the originator of the
> >     --   message; otherwise, the NULL-DN (a zero-length
> >     --   SEQUENCE OF RelativeDistinguishedNames) MUST be used
> >
> > Looks great; I have no wiggle room.  Then you have this:
> >
> >     -- SHOULD be the subject of the CMP protection certificate, i.e.,
> >     --   the certificate corresponding to the private key used to
> >     --   sign the message
> >
> > Well, what if I don't do that?  Does anything break?  Can I just put whatever
> > in there and everything still works?  If nothing breaks, why isn't this "MAY"
> > or something that doesn't use a BCP 14 keyword?  If something breaks, why
> > isn't
> > this a MUST?
> >
> > In 3.4:
> >
> > "Each EE SHOULD know its own identity to fill the sender field."
> >
> > What happens if I don't?  And what interoperability aspect fails if I don't
> > know my own identity?  Should this be better expressed as "Each EE SHOULD
> > fill
> > the sender field with its own identity?"  Why isn't that a MUST?
> >
> > The two SHOULDs at the bottom of 3.5 seem suspect too.  Since you're giving
> > me
> > a choice, I'm within specifications to consider the input valid if all of those
> > tests fail.  Is that what's intended?
> >
> > I'm not going to get into any of them past the bottom of Section 3, but
> > hopefully you can see what I'm getting at.  I would typically DISCUSS this
> > pattern, but since I'm so late to the party, I'll leave it to Roman to decide
> > how much this observation weighs on the strength of the document.
> >

[HB] Regarding the usage of "SHOULD" I will add two paragraphs.

To former Section 1.9 / new Section 1.2:
OLD
1.9.  Convention and Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

   The key word "PROHIBITED" is to be interpreted to mean that the
   respective ASN.1 field SHALL NOT be present or used.

NEW
1.2.  Conventions and Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

   The key word "PROHIBITED" is to be interpreted to mean that the
   respective ASN.1 field SHALL NOT be present or used.

   The key words "SHOULD", "SHOULD NOT", "RECOMMENDED", and "NOT
   RECOMMENDED" are used to provide guidance in case further reduction of
   choices are required.  They are also used to indicate specific options where
   interoperability to existing CMP profiles is affected or where there is room for
   further tailoring to more concrete application areas, which may be described in
   separate documents.

Additionally, I will add a paragraph to former Section 1.7 / new Section 1.8:
OLD
1.7.  Scope of this Document

   To minimize ambiguity and complexity through needless variety, this
   document specifies exhaustive requirements for generating PKI
   management messages on the sender side.  On the other hand, it gives
   only minimal requirements on checks by the receiving side and how to
   handle error cases.

NEW
1.8.  Scope of this Document

   This profile on the one hand intends to reduce the flexibility of CMP to
    the generic needs of automated certificate management of machine
   end entities.  On the other hand, it offers a variety of PKI management
   operations and options relevant for industrial use cases.  Therefore, it is
   still a framework that supports further profiling by those addressing a
   specific use case or scenario, e.g., 3GPP/ETSI or UNISIG.  As stated in
   Section 1.2, the key words "SHOULD", "SHOULD NOT",
   "RECOMMENDED", and "NOT RECOMMENDED" are also used where
   there is room for further tailoring of this profile. This still enables
   stricter profiling to the needs of concrete application areas.  Such
   profiling may change a "SHOULD" to a "MUST" or to a "MAY".

   To minimize ambiguity and complexity through needless variety, this
   document specifies exhaustive requirements for generating PKI
   management messages on the sender side.  On the other hand, it gives
   only minimal requirements on checks by the receiving side and how to
   handle error cases.