Re: [lamps] Deb Cooley's No Objection on draft-ietf-lamps-rfc5019bis-08: (with COMMENT)

That is the text.  I agree the proposed fix is enough.

Thank you,
Deb

On Thu, Apr 18, 2024 at 11:21 AM Russ Housley <housley@vigilsec.com> wrote:

> Deb:
>
> The ASN.1 is in RFC 6960:
>
>         ResponderID ::= CHOICE {
>            byName              [1] Name,
>            byKey               [2] KeyHash }
>
> Is this the text?
> ~~~
>    Clients MUST be able to identify OCSP responder certificates using
>    the byKey field and SHOULD be able to identify OCSP responder
>    certificates using the byName field of the ResponseData.ResponderID
>    choices.
>
>    Older responders which provide backward compatibility with [RFC5019]
>    MAY use the byName field to represent the ResponderID, but should
>    transition to using the byKey field as soon as practical.
>
>    Newer responders that conform to this profile MUST use the byKey
>    field to represent the ResponderID to reduce the size of the
>    response.
> ~~~
>
> If so, a reference to [RFC6960] after "ResponseData.ResponderID choices"
> is probably enough.
>
> Russ
>
>
> > On Apr 18, 2024, at 7:24 AM, Deb Cooley via Datatracker <
> noreply@ietf.org> wrote:
> >
> > Deb Cooley has entered the following ballot position for
> > draft-ietf-lamps-rfc5019bis-08: No Objection
> >
> > 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-rfc5019bis/
> >
> >
> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > I have only one comment:
> >
> > Section 3.2.2, Appendix A:  The two terms 'byName' and 'byKey' are used
> without
> > being defined (note: this is true in RFC 5019 too).  There are numerous
> 'Name'
> > fields in the ASN.1, but no 'Key' fields.  My suggestion is to define
> these
> > terms by pointing to the appropriate ASN.1 field.
> >
> > [note:  finally, I get to ballot on a document I understand.  LOL]
> >
> >
> >
> > _______________________________________________
> > Spasm mailing list
> > Spasm@ietf.org
> > https://www.ietf.org/mailman/listinfo/spasm
>
>