Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <20190916020426.GI22210@kduck.mit.edu>
Date: Mon, 16 Sep 2019 12:33:34 -0400
Cc: IESG <iesg@ietf.org>, LAMPS WG <spasm@ietf.org>,
 Tim Hollebeek <tim.hollebeek@digicert.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <A1AC7C18-1B53-40A3-930C-BCF24BD74E41@vigilsec.com>
References: <156840184931.31866.4936814444231419124.idtracker@ietfa.amsl.com>
 <BC18F590-8080-435A-AA06-88E180FB4E25@vigilsec.com>
 <20190916020426.GI22210@kduck.mit.edu>
To: Ben Kaduk <kaduk@mit.edu>
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/A6yAgr5EptGcm4Qcf_X4TS05VlI>
Subject: Re: [lamps] Benjamin Kaduk's Discuss on
 draft-ietf-lamps-cms-hash-sig-09: (with DISCUSS and COMMENT)
Precedence: list

Ben:

Dropping the resolved parts ...

>>> =
----------------------------------------------------------------------
>>> DISCUSS:
>>> =
----------------------------------------------------------------------
>>>=20
>>> Two fairly minor points that should be easy to resolve, but seem to =
be
>>> worth some time:
>>>=20
>>> I think we need to be a bit more clear about what exactly the =
contents
>>> of the signature OCTET STRING are.  Section 3 has a fairly abstract =
note
>>> about including enough information to be self-describing (within the
>>> HSS/LMS variants), and Section 5 does better with "the single HSS
>>> signature value resulting from the signing operation as specified in
>>> [HASHSIG]", but it doesn't seem too burdensome to say something like
>>> "the string returned from Algorithm 3 in [RFC8554]" or even refer =
back
>>> to the description language at the end of Section 2 and avoid any
>>> confusion.
>>=20
>> I suggest:
>>=20
>>   The signature value is a large OCTET STRING as described in Section =
2
>>   of this document.  The signature format is designed for easy =
parsing.
>>   The HSS, LMS, and LMOTS component of the signature value each =
format
>>   include a counter and a type code that indirectly providing all of
>>   the information that is needed to parse the value during signature
>>   validation.
>=20
> This is for the Section 3 text?  I think that works for me, thanks.

Yes, this text goes in Section 3.

[snip]

>>> =
----------------------------------------------------------------------
>>> COMMENT:
>>> =
----------------------------------------------------------------------
>>>=20

[snip]

>>> Section 4
>>>=20
>>> It feels a little surprising to make explicit requirements on the
>>> keyUsage contents but not say anything about extendedKeyUsage.  =
Having a
>>> static whitelist of EKU OIDs is not reasonable, of course, and the
>>> PUBLIC-KEY class from RFC 5912 only covers regular keyUsage, but =
some
>>> advice about "encipherment methods are not going to make sense" =
might
>>> still be appropriate.
>>=20
>> That is what the "it MUST NOT contain other values" does.  RFC 5280 =
define the keyUsage bits as:
>>=20
>>      KeyUsage ::=3D BIT STRING {
>>           digitalSignature        (0),
>>           nonRepudiation          (1), -- recent editions of X.509 =
have
>>                                -- renamed this bit to =
contentCommitment
>>           keyEncipherment         (2),
>>           dataEncipherment        (3),
>>           keyAgreement            (4),
>>           keyCertSign             (5),
>>           cRLSign                 (6),
>>           encipherOnly            (7),
>>           decipherOnly            (8) }
>=20
> That's true, but does not seem relevant to extendedKeyUsage (unless =
you are
> saying that restrictions on keyUsage somehow supersede usage of
> extendedKeyUsage?) -- I understand what we are saying about keyUsage, =
and
> wonder if we can say anything useful about extendedKeyUsage in an =
analogous
> fashion.

Because extendedKeyUsage is an object identifier, more are defined all =
the time, and they usually say something about protocol context.  These =
are defined in RFC 5280:

   id-kp-serverAuth             OBJECT IDENTIFIER ::=3D { id-kp 1 }
   -- TLS WWW server authentication
   -- Key usage bits that may be consistent: digitalSignature,
   -- keyEncipherment or keyAgreement

   id-kp-clientAuth             OBJECT IDENTIFIER ::=3D { id-kp 2 }
   -- TLS WWW client authentication
   -- Key usage bits that may be consistent: digitalSignature
   -- and/or keyAgreement

   id-kp-codeSigning             OBJECT IDENTIFIER ::=3D { id-kp 3 }
   -- Signing of downloadable executable code
   -- Key usage bits that may be consistent: digitalSignature

   id-kp-emailProtection         OBJECT IDENTIFIER ::=3D { id-kp 4 }
   -- Email protection
   -- Key usage bits that may be consistent: digitalSignature,
   -- nonRepudiation, and/or (keyEncipherment or keyAgreement)

So, for algorithms (without any protocol context) we only say anything =
about keyUsage.  You can see this in RFC 3279, Section 2.3..

Russ=