Subject: Re: [lamps] Clarifications for ECC SPKI (aka RFC 5480)

From: Tadahiko Ito <[email-masked]>
Date: Tue, 9 Jul 2019 01:47:28 +0900

Hi Michael

>>So, would this mean not doing ECIES?
We are just clarifying, so we do not describe about ECIES.

However, We do not block the chance for the ECIES come in.
that is why we describe  as  "id-ecPublicKey as algorithm of
AlgorithmIdentifier {{!RFC2986}} in SubjectPublicKeyInfo".

#ECIES also need information for KDF and optional metadata, so above
description would not be applicable (not enough) for ECIES.

therefore, even if you want to publish document for ECIES, this document
would not block that.

Regards Tadahiko Ito

> From: Michael Richardson <[email-masked]>
> To: Sean Turner <[email-masked]>
> Cc: LAMPS WG <[email-masked]>
> Bcc:
> Date: Sun, 07 Jul 2019 18:22:38 -0400
> Subject: Re: [lamps] Clarifications for ECC SPKI (aka RFC 5480)
>
> Sean Turner <[email-masked]> wrote:
>     > Back in March I asked how the keyEncipherment and dataEncipherment
> bits should be interpreted:
>     >
> https://mailarchive.ietf.org/arch/msg/spasm/b38SFOeko1OT2uN4n52YxAy2B0Y
>
>     > Tadahiko Ito and I have spun a draft that updates 5480 to clarify RFC
>     > 5480’s stance on these two bits.  In short (and this draft is very
>     > short), this draft aims to prohibit the use of these two bits with
>     > id-ecPublicKey as well as id-ecDH and id-ecMQV.  Please let us know
>     > what you think.
>
> So, would this mean not doing ECIES?
>
> --
> Michael Richardson <[email-masked]>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
>
>
>