Re: [COSE] AD evaluation of draft-ietf-cose-x509-06

[Jim Schaad <[e-mail]>]

I just posted the new version.

As you suggested below, I have punted the MTI issue to see what we get as a response.  By default I think we just close our eyes and live with the current text.

Jim


-----Original Message-----
From: Barry Leiba <[e-mail]> 
Sent: Thursday, September 17, 2020 10:27 AM
To: Jim Schaad <[e-mail]>
Cc: [e-mail]; [e-mail]
Subject: Re: AD evaluation of draft-ietf-cose-x509-06

Hi, Jim.
Just leaving the items that aren't fully settled:

>>       For interoperability, applications which use this header parameter
>>       MUST support the hash algorithm 'SHA-256', but can use other hash
>>       algorithms.
>>
>> I appreciate the need for an MTI alg here, but what does it really 
>> mean for me to say that my temperature sensor “supports SHA-256”, but 
>> that everything it sends uses SHA-512?  How does that help 
>> interoperability?
>
> [JLS]  If you have not agreed with others that this is what you are 
> doing, then it does not help interoperability.  However, I am also 
> loathe to say that you MUST use this algorithm and only this 
> algorithm.  My expectation is that people are more likely to use
> SHA-256/64 rather than SHA-256 in this case as the shorter thumbprint 
> means less bytes on the wire.  I don't know what else could be said 
> here.

I'm not sure how to say it either, but I don't think what's there really addresses interoperability.  I think you understand what I'm getting at, yes?

Possibly it just doesn't make sense to have an MTI algorithm, and instead have text advising about interop issues with regard to the hash algo.

Maybe just put a "cref" note in about this issue, and let people who review it cogitate about it -- maybe we'll get some ideas.

>>       This will normally be the situation when self-signed certificates
>>       are used.
>>
>> I wonder whether some readers will misread this as saying that 
>> self-signed certs will normally be used here.  Maybe, “Self-signed 
>> certificates are more likely to appear in this parameter than in the 
>> others.” ?
>
> [JLS] No, this is what I really meant "In particular, self-signed 
> certificates MUST NOT be trusted without an out-of-band confirmation."

That text sounds useful, yes; thanks,

Barry