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

[Graham Leggett <[e-mail]>]

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”.

The “security weaknesses” are covered in section 6 yes, and are the mandated use of MD5 in both protocols that depended on SPKAC (keygen in HTML5), and the hard coded use of MD5 in implementations (OpenSSL was an example, this has subsequently been fixed in https://github.com/openssl/openssl/pull/11260).

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.

Regards,
Graham
—