Re: [media-types] [IANA #1272257] application/vnd.ipfs.ipns-record registration request

[Alexey Melnikov <[e-mail]>]

Hi Amanda,

On 18/05/2023 18:54, Amanda Baber via RT wrote:
> Hi Alexey,
>
> Sending a reminder for this revision from May 11th.

Yes, the updated Security Considerations looks good to me.

Best Regards,

Alexey

> thanks,
> Amanda
>
> On Thu May 11 18:36:37 2023, amanda.baber wrote:
>> Hi Alexey,
>>
>> Does this revision work?
>>
>> ===
>>
>> Security considerations:
>>
>> The media type inherits the security considerations from
>> application/octet-stream,
>> contains no executable code, offers no data confidentiality,
>> but provides integrity protection through a signature digest:
>> <https://specs.ipfs.tech/ipns/ipns-record/#record-verification>
>> In the IPFS/IPNS contexts, it is mandatory to verify the integrity
>> based on the expected signature digest before acting
>> on any content-addressed data linked from the record.
>>
>> ===
>>
>> thanks,
>> Amanda
>>
>> On Thu May 11 12:57:32 2023, [e-mail] wrote:
>>> Hi Amanda,
>>>
>>> On 09/05/2023 20:31, Amanda Baber via RT wrote:
>>>> Hi Alexey,
>>>>
>>>> Can you review this request by May 23rd?
>>>>
>>>> I'm passing this one to you because you reviewed this applicant's
>>>> four application/vnd.ipld.* requests last year.
>>> This is fine to register. One small question/suggestion below:
>>>> thanks,
>>>> Amanda
>>>>
>>>> =====
>>>>
>>>> Name: Marcin Rataj
>>>>
>>>> Email: [e-mail]
>>>>
>>>> Media type name: application
>>>>
>>>> Media subtype name: vnd.ipfs.ipns-record
>>>>
>>>> Required parameters: N/A
>>>>
>>>> Optional parameters: N/A
>>>>
>>>> Encoding considerations: binary
>>>>
>>>> Security considerations: The media type inherits the security
>>>> considerations for application/octet-stream,
>>>> contains no executable code.
>>> I think this registration can be improved by stating whether the
>>> format
>>> provides any means for integrity protection and/or data
>>> confidentiality.
>>>> When used in IPFS/IPNS context, it is strongly recommended
>>>> verifying
>>>> record integrity based on expected signature digest
>>>> <https://specs.ipfs.tech/ipns/ipns-record/#record-verification>.
>>>>
>>>> Interoperability considerations: N/A
>>>>
>>>> Published specification: <https://specs.ipfs.tech/ipns/ipns-
>>>> record/#record-serialization-format>
>>>>
>>>> Applications which use this media: IPFS <https://ipfs.tech> uses
>>>> signed IPNS records as means of introducing cryptographically-
>>>> verifiable mutable pointers to immutable data
>>>> <https://specs.ipfs.tech/ipns/ipns-record/>.
>>>>
>>>> IPNS allows addressing dynamic content in a decentralized network
>>>> with changing location and version. Signed IPNS records in IPFS
>>>> enable secure, tamper-proof content-addressable applications and
>>>> services with high resilience against censorship and data loss.
>>>>
>>>> Fragment identifier considerations: N/A
>>>>
>>>> Restrictions on usage: N/A
>>>>
>>>> Provisional registration? (standards tree only): No
>>>>
>>>> Additional information:
>>>>
>>>> 1. Deprecated alias names for this type: N/A
>>>> 2. Magic number(s): N/A
>>>> 3. File extension(s): ipns-record
>>>> 4. Macintosh file type code: N/A
>>>> 5. Object Identifiers: N/A
>>>>
>>>> General Comments:
>>>>
>>>> Person to contact for further information:
>>>>
>>>> 1. Name: Marcin Rataj
>>>> 2. Email: [e-mail]
>>>>
>>>> Intended usage: COMMON
>>>>
>>>> IPNS records can be exchanged using a variety of transport
>>>> mechanisms, including P2P, HTTP, or even sneakernet.
>>>>
>>>> Author/Change controller: Protocol Labs
>>>> <https://protocol.ai>
>>>> <[e-mail]>