IETF conflict review for draft-deremin-rfc4491-bis
conflict-review-deremin-rfc4491-bis-00

The following approval message was sent
From: The IESG
To: Adrian Farrel ,
    draft-deremin-rfc4491-bis@ietf.org,
    rfc-ise@rfc-editor.org
Cc: IETF-Announce ,
    The IESG ,
    iana@iana.org
Subject: Results of IETF-conflict review for draft-deremin-rfc4491-bis-10

The IESG has completed a review of draft-deremin-rfc4491-bis-10 consistent
with RFC5742.

The IESG has no problem with the publication of 'Using GOST R 34.10-2012 and
GOST R 34.11-2012 algorithms with the Internet X.509 Public Key
Infrastructure'  as an Informational RFC.

The IESG has concluded that this work is related to IETF work done in WG
LAMPS, but this relationship does not prevent publishing.

The IESG would also like the Independent Submissions Editor to review the
comments in the datatracker related to this document and determine whether or
not they merit incorporation into the document. Comments may exist in both
the ballot and the history log.

The IESG review is documented at:
https://datatracker.ietf.org/doc/conflict-review-deremin-rfc4491-bis/

A URL of the reviewed Internet Draft is:
https://datatracker.ietf.org/doc/draft-deremin-rfc4491-bis/

The process for such documents is described at
https://www.rfc-editor.org/indsubs.html

Thank you,

The IESG Secretary

[Ballot comment]
This note constitutes a ballot position on the IESG conflict review
response for draft-deremin-rfc4491-bis-10.  RFC 5742 requires
the IESG to review documents submitted to the RFC Editor by the IRTF and
ISE, and to produce one of a fixed set of conflict-review responses.  The
response I have selected is visible in the datatracker page for this
conflict review.  In this case, the response is number 2, "the IESG has
concluded thatthis work is related to IETF work done in WG , but this
relationship does not prevent publishing."  However, that response is not
final until approved by the IESG as a whole, and other IESG members will
likely produce ballot comments on this conflict-review as well.  Since the
primary purpose of this IESG balloting activity is to agree on the
conflict-review response, I will include remarks in the "IESG" section below
that are directed at the other IESG members and attempt to lay out any other
potentially relevant factors that might influence the IESG's decision (even
if they do not directly support the conclusion that I reached).  Please note
that in preparing the IESG conflict-review response, I am tasked only with
determining whether IETF process is being followed, and am not tasked with
assessing the quality or content of the document in other ways.  However,
because I had to read the draft in question in order to decide what
conflict-review response to propose, I also include (under the "COMMENT"
heading) some remarks about the document itself; these comments are directed
at the authors and ISE, but have no formal standing.  They are safe to
ignore, and whether/how to act (or not act) on them is a matter for the ISE
and authors to determine; I will only participate in further discussion if
explicitly asked to do so.

IESG

Section 2 says that the presented signature format (as a byte string) is
"directly usable in CMS [RFC5652], where such values are represented as
octet strings."  This seems basically true, with the primary SignerInfo
structure including a SignatureValue that is defined as OCTET STRING.  A BIT
STRING signature field does appear in the ExtendedCertificate certificate
choice, but that form is marked as obsolete.  The BIT STRING signature also
appears in the AttributeCertificateV1 structure, which is not exactly a core
part of CMS, but does not seem to be marked as obsolete, either.

COMMENT

Section 8

If this was an IETF document, we would want some discussion in the security
considerations about the privacy impact of including some of the
distinguished name additions from §5.1 in the resulting certificate, most
notably the ITNs.  I have no knowledge of how common it is to publicly
distribute such values in Russia, though, so maybe none are needed here.
The software/tool identifiers in §5.3 and 5.4 also have potential to
indicate when a buggy/vulnerable implementation is in use by the
corresponding certificate holder.

Appendices

[Note that I did not closely review the ASN.1 modules or test vectors, since
it is not necessary to do so for the purposes of the conflict-review
evaluation.]

NITS

Section 4.2

  When either of these identifiers appears as algorithm field in
  SubjectPublicKeyInfo.algorithm.algorithm field, parameters field MUST
  have the following structure:

s/parameters field/the parameters field/

Section 4.4

  If the key is going to be used for key agreement, flag keyAgreement
  MUST be present in KeyUsage extension with encipherOnly and
  decipherOnly flags being optional.  However flags encipherOnly and
  decipherOnly flags MUST NOT be present simultaneously.

Only one "flags" in the last sentence (and maybe add a "the").