On Tue, 29 Jan 2019, Tero Kivinen wrote:
The problem is that to be really usuful we would need to include
similar text we already have in RFC8247 for example, i.e., explain
where ENCR_AES_CCM_8 is useful and why it is SHOULD for some
environments, but not SHOULD for others etc.
I explained bef
Paul Wouters writes:
>
> Recently we had a discussion about mapping IANA entries to a yang model,
> and the question came up whether we sould add a deprecated marker to the
> IKE/ESP registries for algorithms.
>
> I thought it was a good idea, but not everyone agreed.
>
> I just stumbled upon RF
On Tue, 18 Dec 2018, Yoav Nir wrote:
When I described the various SHOULD, MAY, MUST and their variants, I was
not suggesting of putting that into the IANA registry. The IANA registry
should only get "deprecated" or "obsolete". In my view (and I think the
RFCs view) deprecrated means "issues foun
> On 18 Dec 2018, at 17:19, Paul Wouters wrote:
>
> On Tue, 18 Dec 2018, paul.kon...@dell.com wrote:
>
>>> Well, I think it's a bit too complex for random implementer.
>>> I'd prefer to classify all algorithms as follows:
>>>
>>> 1. Secure, required for interoperability
>>> 2. Secure, not requ
Paul Wouters wrote:
>> I think we need an RFC to at least categorize the algorithms, unless
>> we want the IANA registry to have stuff like “SHOULD-“ and “MAY+:
> We only need to add the SHOULD NOT and MUST NOT's and possibly some
> MAY's that are deemed otherwise ancient and dep
On Tue, 18 Dec 2018, Valery Smyslov wrote:
I think it is a good idea to have some indication in IANA about the current
status of the algorithm,
similar to recent changes in the TLS registry (and in fact I initiated this
discussion in Bangkok).
Indeed. And I agreed and I was reminded of this
On Tue, 18 Dec 2018, paul.kon...@dell.com wrote:
Well, I think it's a bit too complex for random implementer.
I'd prefer to classify all algorithms as follows:
1. Secure, required for interoperability
2. Secure, not required for interoperability
3. Insecure (obsoleted)
Possibly some algorith
Hi Paul,
> > Well, I think it's a bit too complex for random implementer.
> > I'd prefer to classify all algorithms as follows:
> >
> > 1. Secure, required for interoperability
> > 2. Secure, not required for interoperability
> > 3. Insecure (obsoleted)
> >
> > Regards,
> > Valery.
>
> Possibly s
> On Dec 18, 2018, at 1:39 AM, Valery Smyslov wrote:
>
>
> [EXTERNAL EMAIL]
>
> Hi Paul,
>
> I think it is a good idea to have some indication in IANA about the current
> status of the algorithm,
> similar to recent changes in the TLS registry (and in fact I initiated this
> discussion in
Hi Paul,
I think it is a good idea to have some indication in IANA about the current
status of the algorithm,
similar to recent changes in the TLS registry (and in fact I initiated this
discussion in Bangkok).
> > I think we need an RFC to at least categorize the algorithms, unless we
> > want
On Tue, 18 Dec 2018, Yoav Nir wrote:
I think we need an RFC to at least categorize the algorithms, unless we want
the IANA registry to have stuff like “SHOULD-“ and “MAY+:
We only need to add the SHOULD NOT and MUST NOT's and possibly some
MAY's that are deemed otherwise ancient and deprecate
Hi, Paul
I think we need an RFC to at least categorize the algorithms, unless we want
the IANA registry to have stuff like “SHOULD-“ and “MAY+:
> On 18 Dec 2018, at 6:14, Paul Wouters wrote:
>
>
> Recently we had a discussion about mapping IANA entries to a yang model,
> and the question came
Recently we had a discussion about mapping IANA entries to a yang model,
and the question came up whether we sould add a deprecated marker to the
IKE/ESP registries for algorithms.
I thought it was a good idea, but not everyone agreed.
I just stumbled upon RFC 7696: Guidelines for Cryptographi
13 matches
Mail list logo
