⚠️ 该 EIP 不建议普遍使用或实施，因为它可能会发生变化。

EIP-5437: Security Contact Interface

An interface for security notice using asymmetric encryption

作者	Zainan Zhou
讨论-To	https://ethereum-magicians.org/t/erc-interface-for-security-contract/10303
状态	Draft
类型	Standards Track
分类	ERC
创建日期	2022-08-09
依赖	165
英文版	https://eips.ethereum.org/EIPS/eip-5437

摘要

An interface for security notice using asymmetric encryption. The interface exposes a asymmetric encryption key and a destination of delivery.

动机

Currently there is no consistent way to specify an official channel for security researchers to report security issues to smart contract maintainers.

规范

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.

interface IEIP5437 {

    /// REQUIRED
    function getSecurityContact(uint8 type, bytes memory data) public view
    returns (
        uint8 type,
        bytes memory publicKey,
        bytes memory extraData
    );

    /// OPTIONAL
    // TODO consider remove if not needed before finalized
    function setSecurityContact(
        uint8 type,
        bytes memory publicKey,
        bytes memory extraData) public;
    event SecurityContactChanged(uint8 type, bytes memory publicKeyForEncryption, bytes memory extraData);

    /// OPTIONAL
    function securityNotify(uint8 type, bytes memory data) public payable;
    /// OPTIONAL
    event OnSecurityNotification(uint8 type, bytes memory sourceData, uint256 value);

    /// OPTIONAL
    // TODO consider to make it a separate EIP
    function bountyPolicy(uint256 id) public view returns(string, bytes memory extraData);
}

Compliant interfaces MUST implement the getSecurityContact method.

type is a one byte data with valid range of [0x10, 0x7f]. The ranges of [0x00, 0x0f] and [0x80, 0xff] are reserved for future extension.

The type indicates the format of the publicKey and extraData in the following way

| | Type | Encryption scheme | extraData | | | —- | —————– | ———————————————– | | | 0x10 | GnuPG - RSA/3072 | Email address(es) encoded in format of RFC 2822 | ————————————————————————————————

A new version of this table can be proposed by future EIPs by specifying a new type number.

The publicKey returned from getSecurityContact MUST follow the encryption scheme specified in the table above.

The following is an example of a publicKey using RSA/3072 generated via GnuPG in an RFC 20 ASCII-encoding of the public key string:

IF setSecurityContact is implemented and a call to it has succeeded in setting a new security contact, an event SecurityContactChanged MUST be emitted with the identical passed-in-parameters of setSecurityContact
It’s also RECOMMENDED that an on-chain security notify method securityNotify to implemented to receive security notice onchain. If it’s implemented and a call has succeeded, it MUST emit an OnSecurityNotification with identical pass-in-parameter data.
Compliant interfaces MUST implement EIP-165.
It’s recommended to set a bounty policy via bountyPolicy method. The id = 0 is preserved for a full overview, while other digits are used for different individual bounty policies. The returned string will be URI to content of bounty policies. No particular format of bounty policy is specified.

基本原理

For simplicity, this EIP specifies a simple GPG scheme with a given encryption scheme and uses email addresses as a contact method. It’s possible that future EIPs will specify new encryption schemes or delivery methods.
This EIP adds an optional method, setSecurityContact, to set the security contact, because it might change due to circumstances such as the expiration of the cryptographic keys.
This EIP explicitly marks securityNotify as payable, in order to allow implementers to set a staking amount to report a security vulnerability.
This EIP allows for future expansion by adding the bountyPolicy the extraData fields. Additional values of these fields may be added in future EIPs.

向后兼容性

Currently, existing solutions such as OpenZeppelin use plaintext in source code

/// @custom:security-contact some-user@some-domain.com

It’s recommend that new versions of smart contracts adopt this EIP in addition to the legacy @custom:security-contact approach.

Security Considerations

Implementors should properly follow security practices required by the encryption scheme to ensure the security of the chosen communication channel. Some best practices are as follows:

Keep security contact information up-to-date;
Rotate encryption keys in the period recommended by best practice;
Regularly monitor the channel to receive notices in a timely manner.

版权声明

参考文献

Please cite this document as:

Zainan Zhou, "EIP-5437: Security Contact Interface [DRAFT]," Ethereum Improvement Proposals, no. 5437, August 2022. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-5437.

EIP-5437: Security Contact Interface Source