Re: [Secdispatch] draft-leggett-spkac: Signed Public Key and Challenge

[Dirk-Willem van Gulik <[e-mail]>]

On 10 Nov 2022, at 13:39, Graham Leggett <[e-mail]> wrote:
> On 10 Nov 2022, at 10:51, Roman Danyliw <[e-mail]> wrote:
> 
>> Thanks for bringing this work for consideration into the IETF.
>> 
>> Section 1.2 says:
>> 
>> The purpose of
>>  this RFC is to document the existing use of the protocol, address
>>  security implementation weaknesses in common implementations, and
>>  formalise the protocol into a standard.
>> 
>> Could you roughly annotate or explain which parts of the document are (a) documenting the "existing use of the protocol"; and (b) "addressing the security ... weaknesses."  Per (a), would implementations all agree on the definition of terms/ASN.1 in Section 2 and 3, or are changes/improvements made here per goal (b)?  Is (b) primarily addressed by Section 6 where there is guidance on how to use SPKAC?
> 
> The a) above is worded badly, it means “how the protocol works right now in existing code”

Lets reword this perhaps as

The purpose of this RFC is to document 1) the existing, use of the protocol; as implemented by various webbrowsers and the serverside component. And 2) to formalise the protocol as historically known to be interoperable into a standard. Finally this document will also discuss some of the security shortcomings; such as its mandated use of MD5.

> All implementations agree on the definition of terms/ASN.1 (I am not aware of any that don’t, implementations of this code approach 30 years old and I would expect any interop problems to have been ironed out by now). No changes are proposed.

> This standard is very well contained when Netscape designed it, the title “signed public key and challenge” describes the whole thing, the combination of a public key and a challenge exist, and are signed, that’s it.
> 
> With a proper IETF definition, this message format can be used as a building block by other specs.
> 
> One thing I want to be careful of is drawing too much of the history into this spec. We’re defining the messaging format only at this point. Happy to receive guidance on whether we need more history or if this is good enough.


Correct - e’re defining the messaging format as * historically used & known to be highly interoperable between webbrowsers * only at this point.

Lets stay well away from modernising this :)

Dw.