Subject: Re: [lamps] Call for Adoption of draft-housley-lamps-cms-update-alg-id-protect

From: Tim Hollebeek <[email-masked]>
Date: Tue, 14 Jan 2020 22:06:07 +0000

Reminder: This call for adoption closes soon.

-Tim

From: Spasm <[email-masked]> On Behalf Of Tim Hollebeek
Sent: Saturday, December 21, 2019 12:29 AM
To: SPASM <[email-masked]>
Subject: [lamps] Call for Adoption of
draft-housley-lamps-cms-update-alg-id-protect

Please indicate whether you support adoption of Call for Adoption of
draft-housley-lamps-cms-update-alg-id-protect by the LAMPS WG by January
17th.

-Tim

---

From: Michael Richardson <[email-masked]>
Date: Wed, 15 Jan 2020 09:34:34 -0500

I have read draft-housley-lamps-cms-update-alg-id-protect, and as I
understand it, it simply removes a degree of freedom to select non-identical
message digest algorithms.  Where there were two choices, they are now
constrained to be the same choice.
The signal for one of the choices was already protected in a
signature, while the other was not.
(RFC8366 and BRSKI makes use of 5652 format vouchers, so this matters to me.
I am unaware of any ability to choose different algorithms, nor would I want to)

I support adopting this document.
I am not fond of "patch" documents, but it seems too soon to consider
RFC5652bis.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Tim Hollebeek <[email-masked]>
Date: Tue, 21 Jan 2020 10:40:07 +0000

There appears to be widespread support for adoption of this draft and no
opposition.  Furthermore, several members are willing to review the
document.  I'll update the status as adopted.

-Tim

From: Tim Hollebeek 
Sent: Friday, December 20, 2019 4:29 PM
To: SPASM <[email-masked]>
Subject: Call for Adoption of draft-housley-lamps-cms-update-alg-id-protect

-Tim

---

From: Russ Housley <[email-masked]>
Date: Sun, 26 Jan 2020 13:15:22 -0500

I got some private email suggesting a different approach to the Timestamp compatibility section.  The concern is that a TSA could be using SHA-384 with <any signature algorithm> but the original content signer could be using SHA-256 and <any signature algorithm>.

This would lead to a timestamp something like:
 
> {
>   contentType id-signedData,
>   content (SignedData){
>     …
>     encapContentInfo {
>       contentType id-ct-TSTInfo,
>       content (DER(TSTInfo)){
>         …
>         messageImprint {
>           hashAlgorithm { algorithm id-sha256 }
>           hashedMessage …
>         }
>         …
>       })
>     }
>     …
>     signerInfos {
>       {
>         …
>         digestAlgorithm { algorithm id-sha384 }
>         …
>         signatureAlgorithm { algorithm ecdsa-with-SHA384 }
>         …
>       }
>     }
>   }
> }

If it’s no longer allowed, the concern is that a lot of timestamps that are valid today will become invalidate.

The person that highlighted this concern offered alternative text:

>    In the context of a timestamp token [RFC3161], the value of
>    TimeStampToken.content MUST use same digest algorithm to compute the
>    digest of the encapContentInfo eContent OCTET STRING and the
>    message-digest attribute for the TSA SignerInfo value. No requirement
>    is placed on a TSA to ensure that the TSA digest algorithm for the
>    token matches the digest algorithm identifier for the MessageImprint
>    value embedded within the TSTTokenInfo.

What do others think?

Russ