Re: [lamps] [EXTERNAL] Re: New Version Notification for draft-housley-lamps-cms-kemri-01.txt

[Mike Ounsworth <[e-mail]>]

Perfect!

---
Mike Ounsworth

-----Original Message-----
From: Russ Housley <[e-mail]> 
Sent: Wednesday, February 15, 2023 9:02 AM
To: Carl Wallace <[e-mail]>; Mike Ounsworth <[e-mail]>
Cc: LAMPS <[e-mail]>; David Hook <[e-mail]>; John Gray <[e-mail]>; Tomofumi Okubo <[e-mail]>
Subject: Re: [lamps] [EXTERNAL] Re: New Version Notification for draft-housley-lamps-cms-kemri-01.txt

I think this is what you guys are proposing:

  --  KEM-ALGORITHM
  --
  --  Describes the basic properties of a KEM algorithm
  --
  -- Suggested prefixes for KEM algorithm objects is: kema-
  --
  --  &id - contains the OID identifying the KEM algorithm
  --  &Value - if present, contains a type definition for the kemct;
  --               if absent, implies that no ASN.1 encoding is
  --               performed on the kemct value
  --  &Params - if present, contains the type for the algorithm
  --               parameters; if absent, implies no parameters
  --  &paramPresence - parameter presence requirement
  --  &PublicKeySet - specifies which public keys are used with
  --               this algorithm
  --  &Ukm - if absent, type for user keying material
  --  &ukmPresence - specifies the requirements to define the UKM field
  --  &smimeCaps - contains the object describing how the S/MIME
  --               capabilities are presented.

  KEM-ALGORITHM ::= CLASS {
    &id             OBJECT IDENTIFIER UNIQUE,
    &Value          OPTIONAL,
    &Params         OPTIONAL,
    &paramPresence  ParamOptions DEFAULT absent,
    &PublicKeySet   PUBLIC-KEY OPTIONAL,
    &Ukm            OPTIONAL,
    &ukmPresence    ParamOptions DEFAULT absent,
    &smimeCaps      SMIME-CAPS OPTIONAL
  } WITH SYNTAX {
    IDENTIFIER &id
    [VALUE &Value]
    [PARAMS [TYPE &Params] ARE &paramPresence]
    [PUBLIC-KEYS &PublicKeySet]
    [UKM [TYPE &Ukm] ARE &ukmPresence]
    [SMIME-CAPS &smimeCaps]
  }

Russ

> On Feb 15, 2023, at 7:38 AM, Carl Wallace <[e-mail]> wrote:
> 
> Adding a Value field to the object class makes sense to me. As another example, RFC5912 includes a Value field in the SIGNATURE-ALGORITHM definition. The Value field is omitted for RSA instantiations but populated for DSA. This case is similar.
> 
> On 2/14/23, 2:55 PM, "Spasm on behalf of Mike Ounsworth" <[e-mail] <mailto:[e-mail]> on behalf of Mike.Ounsworth=[e-mail] <mailto:[e-mail]>> wrote:
> 
> 
> 2a)
> 
> 
> Here's what I believe is an equivalent example from existing RFCs
> 
> 
> RFC 5280
> 
> 
> SubjectPublicKeyInfo ::= SEQUENCE {
> algorithm AlgorithmIdentifier,
> subjectPublicKey BIT STRING }
> 
> 
> Ok, fine, so the sPK will be a BIT STRING on the wire,
> 
> 
> But RFC 5912 gives this information class:
> 
> 
> PUBLIC-KEY ::= CLASS {
> &id OBJECT IDENTIFIER UNIQUE,
> &KeyValue OPTIONAL,
> &Params OPTIONAL,
> &paramPresence ParamOptions DEFAULT absent, &keyUsage KeyUsage 
> OPTIONAL, &PrivateKey OPTIONAL
> 
> 
> with this example instantiation:
> 
> 
> -- pk-rsa-pss PUBLIC-KEY ::= {
> -- IDENTIFIER id-RSASSA-PSS
> -- KEY RSAPublicKey
> -- PARAMS TYPE RSASSA-PSS-params ARE optional
> -- CERT-KEY-USAGE { .... }
> -- }
> 
> 
> so if you happen to know that the `subjectPublicKey BIT STRING` will actually be a RSAPublicKey, then you can give that hint to the compiler via PUBLIC-KEY.KEY.
> 
> 
> 
> 
> I think the same should be true of the KEM-ALGORITHM; the kemct *IS* a BIT STRING, but if you happen to know what its internal structure is for a given instantiation, then you should be able to give that hint to the complier via the KEM-ALGORITHM class. I'm only 80% confident about this ASN.1-foo, so maybe I'm misunderstanding something?
> 
> 
> ---
> Mike Ounsworth
> 
> 
> -----Original Message-----
> From: Spasm <[e-mail] <mailto:[e-mail]>> 
> On Behalf Of Mike Ounsworth
> Sent: Tuesday, February 14, 2023 11:16 AM
> To: Russ Housley <[e-mail] <mailto:[e-mail]>>
> Cc: LAMPS <[e-mail] <mailto:[e-mail]>>; David Hook 
> <[e-mail] <mailto:[e-mail]>>; John Gray 
> <[e-mail] <mailto:[e-mail]>>; Tomofumi Okubo 
> <[e-mail] <mailto:[e-mail]>>
> Subject: Re: [lamps] [EXTERNAL] Re: New Version Notification for 
> draft-housley-lamps-cms-kemri-01.txt
> 
> 
> 1) Good.
> 2) Good.
> 
> 
> 2a) Not a necessarily a problem, but maybe an opportunity to use the information object class to give the ASN.1 parser more info about the structure that it can expect to find in the KEM value field? Like if we're defining a kema and we know that the kemct value will be the BIT STRING representation of a structured ASN.1 object, you'd think you could express that in the information object?
> 
> 
> ---
> Mike Ounsworth
> 
> 
> -----Original Message-----
> From: Russ Housley <[e-mail] 
> <mailto:[e-mail]>>
> Sent: Tuesday, February 14, 2023 11:09 AM
> To: Mike Ounsworth <[e-mail] 
> <mailto:[e-mail]>>
> Cc: LAMPS <[e-mail] <mailto:[e-mail]>>; David Hook 
> <[e-mail] <mailto:[e-mail]>>; John Gray 
> <[e-mail] <mailto:[e-mail]>>; Tomofumi Okubo 
> <[e-mail] <mailto:[e-mail]>>
> Subject: Re: [lamps] [EXTERNAL] Re: New Version Notification for 
> draft-housley-lamps-cms-kemri-01.txt
> 
> 
> Mike:
> 
> 
> 1) I chatted with David Hook, and asked him to review the I-D. He did. He was more happy with "kemct" than "ciphertext". It would be good to hear from others on this topic.
> 
> 
> 2a) Yes, I think that kema- is the right prefix.
> 
> 
> 2b) I do not see how this is different than putting RSAPublicKey into the SubjectPublicKey BIT STRING. Please explain.
> 
> 
> Russ
> 
> 
> 
> 
>> On Feb 13, 2023, at 11:53 AM, Mike Ounsworth <Mike.Ounsworth=[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> I support adoption.
>> 
>> 
>> Technical feedback:
>> 
>> 1) 'kemct' vs 'kemenc'
>> 
>> I know this is "just terminology", but @David Hook (BouncyCastle) made the point during our last hackathon that he's runt into real-world issues with people who insist on using a KEM ciphertext as a drop-in for an RSA ciphertext, so changing the language to "encapsulated value (enc)" would help.
>> 
>> I notice that "kemenc" would be in line with HPKE RFC 9810:
>> 
>>> def Encap(pkR):
>>> return shared_secret, enc
>> 
>>> def Decap(enc, skR):
>> 
>> 
>> 2) ASN.1 naming convention for KEM-ALGORITHMs?
>> 
>> For example in the Composite-KEM draft, we're gonna need to instantiate your KEM-ALGORITHM, for example:
>> 
>> kema-CompositeKEM KEM-ALGORITHM ::= { IDENTIFIER id-alg-composite-kem 
>> VALUE CompositeCiphertextValue PARAMS composite-kem-params 
>> PUBLIC-KEYS { pk-Composite } SMIME-CAPS { IDENTIFIED BY 
>> id-alg-composite } } }
>> 
>> 
>> Is "kema-" an appropriate prefix?
>> 
>> 2b) looking at my KEM-ALGORITHM vs yours; do you need a VALUE to indicate the type of the encapsulated value? In general it may not always be a BIT STRING as some may have ASN.1 structure (as in the case of composite).
>> ---
>> Mike Ounsworth
>> 
>> -----Original Message-----
>> From: Spasm <[e-mail] <mailto:[e-mail]>> 
>> On Behalf Of Russ Housley
>> Sent: Friday, February 10, 2023 12:12 PM
>> To: LAMPS <[e-mail] <mailto:[e-mail]>>
>> Cc: John Gray <[e-mail] <mailto:[e-mail]>>; 
>> Tomofumi Okubo <[e-mail] 
>> <mailto:[e-mail]>>
>> Subject: [EXTERNAL] Re: [lamps] New Version Notification for 
>> draft-housley-lamps-cms-kemri-01.txt
>> 
>> WARNING: This email originated outside of Entrust.
>> DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.
>> 
>> _____________________________________________________________________
>> _ The biggest change is in the ASN.1 module. Many other documents 
>> will need to IMPORT the KEM-ALGORITHM CLASS, so we put it in a separate module. Since we were making edits, we also fixed the things that were reported during the call for adoption, including one comment that was recieved in private email.
>> 
>> For the authors,
>> Russ
>> 
>> 
>>> On Feb 10, 2023, at 1:07 PM, [e-mail] <mailto:[e-mail]> wrote:
>>> 
>>> 
>>> A new version of I-D, draft-housley-lamps-cms-kemri-01.txt
>>> has been successfully submitted by Russ Housley and posted to the 
>>> IETF repository.
>>> 
>>> Name: draft-housley-lamps-cms-kemri
>>> Revision: 01
>>> Title: Using Key Encapsulation Mechanism (KEM) Algorithms in the 
>>> Cryptographic Message Syntax (CMS) Document date: 2023-02-10
>>> Group: Individual Submission
>>> Pages: 16
>>> URL: 
>>> https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-ho
>>> usley-lamps-cms-kemri-01.txt__;!!FJ-Y8qCqXTj2!Z6xOlleSK2awHbBdxvC6Ya
>>> yXGJTAhpNavKSgHUYOIQzsQ1wkChsUTEy4vdv34qVFPnoNMGPMJkuiGzGm_nkkV4LQIm
>>> BN$ 
>>> <https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-h
>>> ousley-lamps-cms-kemri-01.txt__;!!FJ-Y8qCqXTj2!Z6xOlleSK2awHbBdxvC6Y
>>> ayXGJTAhpNavKSgHUYOIQzsQ1wkChsUTEy4vdv34qVFPnoNMGPMJkuiGzGm_nkkV4LQI
>>> mBN$>
>>> Status: 
>>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-h
>>> ousley-lamps-cms-kemri/__;!!FJ-Y8qCqXTj2!Z6xOlleSK2awHbBdxvC6YayXGJT
>>> AhpNavKSgHUYOIQzsQ1wkChsUTEy4vdv34qVFPnoNMGPMJkuiGzGm_nkkV3ltVJj5$ 
>>> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-
>>> housley-lamps-cms-kemri/__;!!FJ-Y8qCqXTj2!Z6xOlleSK2awHbBdxvC6YayXGJ
>>> TAhpNavKSgHUYOIQzsQ1wkChsUTEy4vdv34qVFPnoNMGPMJkuiGzGm_nkkV3ltVJj5$>
>>> Html: 
>>> https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-ho
>>> usley-lamps-cms-kemri-01.html__;!!FJ-Y8qCqXTj2!Z6xOlleSK2awHbBdxvC6Y
>>> ayXGJTAhpNavKSgHUYOIQzsQ1wkChsUTEy4vdv34qVFPnoNMGPMJkuiGzGm_nkkVxo37
>>> jj9$ 
>>> <https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-h
>>> ousley-lamps-cms-kemri-01.html__;!!FJ-Y8qCqXTj2!Z6xOlleSK2awHbBdxvC6
>>> YayXGJTAhpNavKSgHUYOIQzsQ1wkChsUTEy4vdv34qVFPnoNMGPMJkuiGzGm_nkkVxo3
>>> 7jj9$>
>>> Htmlized: 
>>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/dr
>>> aft-housley-lamps-cms-kemri__;!!FJ-Y8qCqXTj2!Z6xOlleSK2awHbBdxvC6Yay
>>> XGJTAhpNavKSgHUYOIQzsQ1wkChsUTEy4vdv34qVFPnoNMGPMJkuiGzGm_nkkV-zTEby
>>> f$ 
>>> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/d
>>> raft-housley-lamps-cms-kemri__;!!FJ-Y8qCqXTj2!Z6xOlleSK2awHbBdxvC6Ya
>>> yXGJTAhpNavKSgHUYOIQzsQ1wkChsUTEy4vdv34qVFPnoNMGPMJkuiGzGm_nkkV-zTEb
>>> yf$>
>>> Diff: 
>>> https://urldefense.com/v3/__https://author-tools.ietf.org/iddiff?url
>>> 2=draft-housley-lamps-cms-kemri-01__;!!FJ-Y8qCqXTj2!Z6xOlleSK2awHbBd
>>> xvC6YayXGJTAhpNavKSgHUYOIQzsQ1wkChsUTEy4vdv34qVFPnoNMGPMJkuiGzGm_nkk
>>> V86eScLM$ 
>>> <https://urldefense.com/v3/__https://author-tools.ietf.org/iddiff?ur
>>> l2=draft-housley-lamps-cms-kemri-01__;!!FJ-Y8qCqXTj2!Z6xOlleSK2awHbB
>>> dxvC6YayXGJTAhpNavKSgHUYOIQzsQ1wkChsUTEy4vdv34qVFPnoNMGPMJkuiGzGm_nk
>>> kV86eScLM$>
>>> 
>>> Abstract:
>>> The Cryptographic Message Syntax (CMS) supports key transport and 
>>> key agreement algorithms. In recent years, cryptographers have been 
>>> specifying Key Encapsulation Mechanism (KEM) algorithms, including 
>>> quantum-secure KEM algorithms. This document defines conventions for 
>>> the use of KEM algorithms by the originator and recipients to 
>>> encrypt CMS content.
>>> 
>>> 
>>> 
>>> 
>>> The IETF Secretariat
>>> 
>>> 
>> 
>> _______________________________________________
>> Spasm mailing list
>> [e-mail] <mailto:[e-mail]> 
>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spa
>> s 
>> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/sp
>> as> 
>> m__;!!FJ-Y8qCqXTj2!Z6xOlleSK2awHbBdxvC6YayXGJTAhpNavKSgHUYOIQzsQ1wkCh
>> s UTEy4vdv34qVFPnoNMGPMJkuiGzGm_nkkV-_K9bBa$
>> Any email and files/attachments transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.
>> 
>> _______________________________________________
>> Spasm mailing list
>> [e-mail] <mailto:[e-mail]> 
>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spa
>> s 
>> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/sp
>> as> 
>> m__;!!FJ-Y8qCqXTj2!czYUmWLEiQK9pa6Hm9U26Zo94lTEIDdU20UgwdNTwwLbBoFC4h
>> fM1QOX-yonT6eP8VriKkQf_Dg6P03mRfyjvQ$
> 
> 
> _______________________________________________
> Spasm mailing list
> [e-mail] <mailto:[e-mail]> 
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spas
> m__;!!FJ-Y8qCqXTj2!YpDreN_498TwUoqONiJNtyXMSQladp-yV8pjOlJ5EA96NeBxcSO
> 4IXyfRQu-H4AhEi_SIk84_1N2uJE2WODO-OHEEfEJoZHtawLA2c1IOw$ 
> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spa
> sm__;!!FJ-Y8qCqXTj2!YpDreN_498TwUoqONiJNtyXMSQladp-yV8pjOlJ5EA96NeBxcS
> O4IXyfRQu-H4AhEi_SIk84_1N2uJE2WODO-OHEEfEJoZHtawLA2c1IOw$>
> 
> 
> _______________________________________________
> Spasm mailing list
> [e-mail] <mailto:[e-mail]> 
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spas
> m__;!!FJ-Y8qCqXTj2!dM_qftfQ7LRczIQdn8r7nC8d3R_PXK5aw-SNjOFF2Zgk3bRBM42
> ryQbamutmc_mqJeiaB226OdgG1v_vuXUeWg$  
> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spa
> sm__;!!FJ-Y8qCqXTj2!dM_qftfQ7LRczIQdn8r7nC8d3R_PXK5aw-SNjOFF2Zgk3bRBM4
> 2ryQbamutmc_mqJeiaB226OdgG1v_vuXUeWg$ >
> 
> 
> 
>