Re: [lamps] Benjamin Kaduk's Discuss on draft-ietf-lamps-cms-hash-sig-09: (with DISCUSS and COMMENT)

[Russ Housley <[e-mail]>]

Ben:

Dropping the resolved parts ...

>>> ----------------------------------------------------------------------
>>> DISCUSS:
>>> ----------------------------------------------------------------------
>>> 
>>> Two fairly minor points that should be easy to resolve, but seem to be
>>> worth some time:
>>> 
>>> 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.
>> 
>> I suggest:
>> 
>>   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.
> 
> This is for the Section 3 text?  I think that works for me, thanks.

Yes, this text goes in Section 3.

[snip]

>>> ----------------------------------------------------------------------
>>> COMMENT:
>>> ----------------------------------------------------------------------
>>> 

[snip]

>>> Section 4
>>> 
>>> 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.
>> 
>> That is what the "it MUST NOT contain other values" does.  RFC 5280 define the keyUsage bits as:
>> 
>>      KeyUsage ::= 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) }
> 
> 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 ::= { id-kp 1 }
   -- TLS WWW server authentication
   -- Key usage bits that may be consistent: digitalSignature,
   -- keyEncipherment or keyAgreement

   id-kp-clientAuth             OBJECT IDENTIFIER ::= { id-kp 2 }
   -- TLS WWW client authentication
   -- Key usage bits that may be consistent: digitalSignature
   -- and/or keyAgreement

   id-kp-codeSigning             OBJECT IDENTIFIER ::= { id-kp 3 }
   -- Signing of downloadable executable code
   -- Key usage bits that may be consistent: digitalSignature

   id-kp-emailProtection         OBJECT IDENTIFIER ::= { 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