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

[Mike Ounsworth <[e-mail]>]

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]> On Behalf Of Mike Ounsworth
Sent: Tuesday, February 14, 2023 11:16 AM
To: Russ Housley <[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

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]>
Sent: Tuesday, February 14, 2023 11:09 AM
To: 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

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]> 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]> On Behalf Of Russ Housley
> Sent: Friday, February 10, 2023 12:12 PM
> To: LAMPS <[e-mail]>
> Cc: John Gray <[e-mail]>; Tomofumi Okubo 
> <[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] 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-housley-lamps-cms-kemri-01.txt__;!!FJ-Y8qCqXTj2!Z6xOlleSK2awHbBdxvC6YayXGJTAhpNavKSgHUYOIQzsQ1wkChsUTEy4vdv34qVFPnoNMGPMJkuiGzGm_nkkV4LQImBN$
>> Status:         https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-housley-lamps-cms-kemri/__;!!FJ-Y8qCqXTj2!Z6xOlleSK2awHbBdxvC6YayXGJTAhpNavKSgHUYOIQzsQ1wkChsUTEy4vdv34qVFPnoNMGPMJkuiGzGm_nkkV3ltVJj5$
>> Html:           https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-housley-lamps-cms-kemri-01.html__;!!FJ-Y8qCqXTj2!Z6xOlleSK2awHbBdxvC6YayXGJTAhpNavKSgHUYOIQzsQ1wkChsUTEy4vdv34qVFPnoNMGPMJkuiGzGm_nkkVxo37jj9$
>> Htmlized:       https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-housley-lamps-cms-kemri__;!!FJ-Y8qCqXTj2!Z6xOlleSK2awHbBdxvC6YayXGJTAhpNavKSgHUYOIQzsQ1wkChsUTEy4vdv34qVFPnoNMGPMJkuiGzGm_nkkV-zTEbyf$
>> Diff:           https://urldefense.com/v3/__https://author-tools.ietf.org/iddiff?url2=draft-housley-lamps-cms-kemri-01__;!!FJ-Y8qCqXTj2!Z6xOlleSK2awHbBdxvC6YayXGJTAhpNavKSgHUYOIQzsQ1wkChsUTEy4vdv34qVFPnoNMGPMJkuiGzGm_nkkV86eScLM$
>> 
>> 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]
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spas
> m__;!!FJ-Y8qCqXTj2!Z6xOlleSK2awHbBdxvC6YayXGJTAhpNavKSgHUYOIQzsQ1wkChs
> 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]
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spas
> m__;!!FJ-Y8qCqXTj2!czYUmWLEiQK9pa6Hm9U26Zo94lTEIDdU20UgwdNTwwLbBoFC4hfM1QOX-yonT6eP8VriKkQf_Dg6P03mRfyjvQ$

_______________________________________________
Spasm mailing list
[e-mail]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spasm__;!!FJ-Y8qCqXTj2!YpDreN_498TwUoqONiJNtyXMSQladp-yV8pjOlJ5EA96NeBxcSO4IXyfRQu-H4AhEi_SIk84_1N2uJE2WODO-OHEEfEJoZHtawLA2c1IOw$