Re: [lamps] I-D Action: draft-ietf-lamps-8410-ku-clarifications-00.txt

[Corey Bonnell <[e-mail]>]

Hi Sean,
That proposal sounds good to me.

Thanks,
Corey

-----Original Message-----
From: Sean Turner <[e-mail]> 
Sent: Friday, March 25, 2022 7:43 AM
To: Corey Bonnell <[e-mail]>
Cc: SPASM <[e-mail]>
Subject: Re: [lamps] I-D Action: draft-ietf-lamps-8410-ku-clarifications-00.txt

Corey,

How about make it align exactly with RFC3279 and add "or CRL issuer”:

If the keyUsage extension is present in an end-entity or CRL issuer certificate that indicates id-Ed25519 or id-Ed448 in SubjectPublicKeyInfo, then the keyUsage extension MUST include at least one of the following:

 nonRepudiation;
 digitalSignature; and
 cRLSign;

spt

PS: And so ends the concern about sending a -00 to the IESG :)

> On Mar 25, 2022, at 06:54, Corey Bonnell <[e-mail]> wrote:
> 
> Hi Sean,
> Section 3 says:
> 
> "If the keyUsage extension is present in an end-entity certificate 
> that indicates id-Ed25519 or id-Ed448 in SubjectPublicKeyInfo, then 
> the keyUsage extension MUST contain one or both of the following:
> 
>  nonRepudiation; and
>  digitalSignature;
> 
> the following MAY also be present:
> 
>  cRLSign;"
> 
> 
> In the case of CRL issuer certificates, it is acceptable to solely 
> include "cRLSign"; the NR/DS bits are not needed. I suggest rewording 
> this passage
> to:
> 
> "If the keyUsage extension is present in an end-entity certificate 
> that indicates id-Ed25519 or id-Ed448 in SubjectPublicKeyInfo, then 
> the keyUsage extension MUST include at least one of the following:
> 
>  nonRepudiation;
>  digitalSignature; and
>  cRLSign;"
> 
> Thanks,
> Corey
> 
> 
> -----Original Message-----
> From: Spasm <[e-mail]> On Behalf Of Sean Turner
> Sent: Friday, March 25, 2022 6:42 AM
> To: SPASM <[e-mail]>
> Subject: Re: [lamps] I-D Action:
> draft-ietf-lamps-8410-ku-clarifications-00.txt
> 
> Hi! This is the initial WG version. The only diff from the individual 
> -01 is the editorial correction noted on list:
> https://www.ietf.org/rfcdiff?url1=draft-mtis-lamps-8410-ku-clarificati
> ons&ur 
> l2=https://lamps-wg.github.io/8410-ku-clarifications/draft-ietf-lamps-
> 8410-k
> u-clarifications.txt
> 
> Cheers,
> spt
> 
>> On Mar 24, 2022, at 21:48, [e-mail] wrote:
>> 
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>> This draft is a work item of the Limited Additional Mechanisms for 
>> PKIX
> and SMIME WG of the IETF.
>> 
>>       Title           : Clarifications for Ed25519, Ed448, X25519, and
> X448 Algorithm Identifiers
>>       Authors         : Sean Turner
>>                         Simon Josefsson
>>                         Daniel McCarney
>>                         Tadahiko Ito
>> 	Filename        : draft-ietf-lamps-8410-ku-clarifications-00.txt
>> 	Pages           : 5
>> 	Date            : 2022-03-24
>> 
>> Abstract:
>>  This document updates RFC 8410 to clarify existing and specify  
>> missing semantics for key usage bits when used in certificates that  
>> support the Ed25519, Ed448, X25519, and X448 Elliptic Curve  
>> Cryptography algorithms.
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-lamps-8410-ku-clarificati
>> ons/
>> 
>> There is also an HTML version available at:
>> 
> https://www.ietf.org/archive/id/draft-ietf-lamps-8410-ku-clarification
> s-00.h
> tml
>> 
>> 
>> Internet-Drafts are also available by rsync at
> rsync.ietf.org::internet-drafts
>> 
>> 
>> _______________________________________________
>> Spasm mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/spasm
> 
> _______________________________________________
> Spasm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spasm