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

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 <X>, 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").