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

[Mike Ounsworth <[e-mail]>]

Thanks John. I will change CompositeCiphertextValue to SEQUENCE SIZE (2..MAX) of *OCTET STRING*.

Uri, I think I mistakenly said that KEMRecipientInfo.kemct was BIT STRING. As Russ says, it is in fact OCTET STRING in draft-housley-lamps-cms-kemri-01.

My mistake, sorry for that.

---
Mike Ounsworth

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

Sorry,  my bad.  The current kemct structure in KEMRecipientInfo is an OCTET STRING.  Didn’t mean to imply it was a BIT STRING and open up old wounds…   ☹


However, this discussion is also good input for the Composite KEM draft, meaning we should probably use

    CompositeCiphertextValue ::= SEQUENCE SIZE (2..MAX) OF OCTET STRING

Cheers,

John Gray



From: Russ Housley <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, February 15, 2023 10:33 AM
To: Uri Blumenthal <[e-mail]<mailto:[e-mail]>>
Cc: John Gray <[e-mail]<mailto:[e-mail]>>; Carl Wallace <[e-mail]<mailto:[e-mail]>>; Mike Ounsworth <[e-mail]<mailto:[e-mail]>>; LAMPS <[e-mail]<mailto:[e-mail]>>; David Hook <[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

Uri:

The new KEMRecipientInfo does not use BIT STRING.

We are not going to create X.509v4 in order to get rid of the BIT STRINGs that are in that structure.  Adding a format transition to the PQC algorithm is the topic o the CWP mail list.  That is not a topic for this mail list.

Russ


On Feb 15, 2023, at 10:27 AM, Blumenthal, Uri - 0553 - MITLL <[e-mail]<mailto:[e-mail]>> wrote:

Why are we stuck on the archaic screwed-up misguided BIT STRING, when everything actually is OCTET STRING?

Reason for this comment: in my (extensive) experience of writing and dealing with parsers and codecs for different binary formats, BIT STRING often is conducive to implementation “issues” that negatively impact security.

<soap>IMHO, it was wrong to use BIT STRING then, it is crazy to keep using it now.</soap>
--
V/R,
Uri
There are two ways to design a system. One is to make it so simple there are obviously no deficiencies.
The other is to make it so complex there are no obvious deficiencies.
                                                                                                                                     -  C. A. R. Hoare

On 2/15/23, 09:48, "Spasm on behalf of John Gray" <[e-mail]<mailto:[e-mail]> on behalf of John.Gray=[e-mail]<mailto:John.Gray=[e-mail]>> wrote:

    Thanks for the input!

    I think I now understand why it is useful:   if there is a structure associated with the KEM Ciphertext (other than it just being a BIT STRING), then the VALUE would offer the compiler information about the structure of the block of data (as Mike pointed out).

    In the case of our composite KEM draft (which is currently being updated), there is structure associated with the BIT STRING(s) (though it is a very simple structure):

    CompositeCiphertextValue ::= SEQUENCE SIZE (2..MAX) OF BIT STRING

    Adding the VALUE in the information object would give the additional information to tell the compiler how to deal with the structure.     When it is not needed, then it just doesn't need to be picked up in concrete implementations.


     Cheers,

    John Gray


    -----Original Message-----
    From: Carl Wallace <[e-mail]<mailto:[e-mail]>>
    Sent: Wednesday, February 15, 2023 7:39 AM
    To: Mike Ounsworth <Mike.Ounsworth=[e-mail]<mailto:Mike.Ounsworth=[e-mail]>>; 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

    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]> <mailto:[e-mail]> on behalf of Mike.Ounsworth=[e-mail]<mailto: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]> <mailto:[e-mail]>> On Behalf Of Mike Ounsworth
    Sent: Tuesday, February 14, 2023 11:16 AM
    To: Russ Housley <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]>>
    Cc: LAMPS <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]>>; David Hook <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]>>; John Gray <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]>>; Tomofumi Okubo <[e-mail]<mailto:[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]> <mailto:[e-mail]>>
    Sent: Tuesday, February 14, 2023 11:09 AM
    To: Mike Ounsworth <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]>>
    Cc: LAMPS <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]>>; David Hook <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]>>; John Gray <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]>>; Tomofumi Okubo <[e-mail]<mailto:[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: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]> <mailto:[e-mail]>>
    > On Behalf Of Russ Housley
    > Sent: Friday, February 10, 2023 12:12 PM
    > To: LAMPS <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]>>
    > Cc: John Gray <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]>>;
    > Tomofumi Okubo <[e-mail]<mailto:[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]> <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-hou<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-hou>
    >> sley-lamps-cms-kemri-01.txt__;!!FJ-Y8qCqXTj2!Z6xOlleSK2awHbBdxvC6YayX
    >> GJTAhpNavKSgHUYOIQzsQ1wkChsUTEy4vdv34qVFPnoNMGPMJkuiGzGm_nkkV4LQImBN$
    >> <https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-ho<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-ho>
    >> usley-lamps-cms-kemri-01.txt__;!!FJ-Y8qCqXTj2!Z6xOlleSK2awHbBdxvC6Yay
    >> XGJTAhpNavKSgHUYOIQzsQ1wkChsUTEy4vdv34qVFPnoNMGPMJkuiGzGm_nkkV4LQImBN
   >> $>
    >> Status:
    >> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ho<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ho>
    >> usley-lamps-cms-kemri/__;!!FJ-Y8qCqXTj2!Z6xOlleSK2awHbBdxvC6YayXGJTAh
    >> pNavKSgHUYOIQzsQ1wkChsUTEy4vdv34qVFPnoNMGPMJkuiGzGm_nkkV3ltVJj5$
    >> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-h<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-h>
    >> ousley-lamps-cms-kemri/__;!!FJ-Y8qCqXTj2!Z6xOlleSK2awHbBdxvC6YayXGJTA
    >> hpNavKSgHUYOIQzsQ1wkChsUTEy4vdv34qVFPnoNMGPMJkuiGzGm_nkkV3ltVJj5$>
    >> Html:
    >> https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-hou<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-hou>
    >> sley-lamps-cms-kemri-01.html__;!!FJ-Y8qCqXTj2!Z6xOlleSK2awHbBdxvC6Yay
    >> XGJTAhpNavKSgHUYOIQzsQ1wkChsUTEy4vdv34qVFPnoNMGPMJkuiGzGm_nkkVxo37jj9
    >> $
    >> <https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-ho<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-ho>
    >> usley-lamps-cms-kemri-01.html__;!!FJ-Y8qCqXTj2!Z6xOlleSK2awHbBdxvC6Ya
    >> yXGJTAhpNavKSgHUYOIQzsQ1wkChsUTEy4vdv34qVFPnoNMGPMJkuiGzGm_nkkVxo37jj
    >> 9$>
    >> Htmlized:
    >> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/dra<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/dra>
    >> ft-housley-lamps-cms-kemri__;!!FJ-Y8qCqXTj2!Z6xOlleSK2awHbBdxvC6YayXG
    >> JTAhpNavKSgHUYOIQzsQ1wkChsUTEy4vdv34qVFPnoNMGPMJkuiGzGm_nkkV-zTEbyf$
    >> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/dr<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/dr>
    >> aft-housley-lamps-cms-kemri__;!!FJ-Y8qCqXTj2!Z6xOlleSK2awHbBdxvC6YayX
    >> GJTAhpNavKSgHUYOIQzsQ1wkChsUTEy4vdv34qVFPnoNMGPMJkuiGzGm_nkkV-zTEbyf$
    >> >
    >> Diff:
    >> https://urldefense.com/v3/__https://author-tools.ietf.org/iddiff?url2<https://urldefense.com/v3/__https:/author-tools.ietf.org/iddiff?url2>
    >> =draft-housley-lamps-cms-kemri-01__;!!FJ-Y8qCqXTj2!Z6xOlleSK2awHbBdxv
    >> C6YayXGJTAhpNavKSgHUYOIQzsQ1wkChsUTEy4vdv34qVFPnoNMGPMJkuiGzGm_nkkV86
    >> eScLM$
    >> <https://urldefense.com/v3/__https://author-tools.ietf.org/iddiff?url<https://urldefense.com/v3/__https:/author-tools.ietf.org/iddiff?url>
    >> 2=draft-housley-lamps-cms-kemri-01__;!!FJ-Y8qCqXTj2!Z6xOlleSK2awHbBdx
    >> vC6YayXGJTAhpNavKSgHUYOIQzsQ1wkChsUTEy4vdv34qVFPnoNMGPMJkuiGzGm_nkkV8
    >> 6eScLM$>
    >>
    >> 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]> <mailto:[e-mail]>
    > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spas<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spas>
    > <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spa<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spa>
    > s>
    > 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]<mailto:[e-mail]> <mailto:[e-mail]>
    > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spas<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spas>
    > <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spa<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spa>
    > s>
    > m__;!!FJ-Y8qCqXTj2!czYUmWLEiQK9pa6Hm9U26Zo94lTEIDdU20UgwdNTwwLbBoFC4hf
    > M1QOX-yonT6eP8VriKkQf_Dg6P03mRfyjvQ$


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


    _______________________________________________
    Spasm mailing list
    [e-mail]<mailto:[e-mail]> <mailto:[e-mail]>
    https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spasm__;!!FJ-Y8qCqXTj2!ZXNeGJSamE-8ZBpnRqofM-2AlZfbytN0tDXLPDqOXXTqIvl7RTweJGmzB3WHL7H3w-RKviLI3bqzl3wbxToK6g$<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spasm__;!!FJ-Y8qCqXTj2!ZXNeGJSamE-8ZBpnRqofM-2AlZfbytN0tDXLPDqOXXTqIvl7RTweJGmzB3WHL7H3w-RKviLI3bqzl3wbxToK6g$>  <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spasm__;!!FJ-Y8qCqXTj2!ZXNeGJSamE-8ZBpnRqofM-2AlZfbytN0tDXLPDqOXXTqIvl7RTweJGmzB3WHL7H3w-RKviLI3bqzl3wbxToK6g$<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spasm__;!!FJ-Y8qCqXTj2!ZXNeGJSamE-8ZBpnRqofM-2AlZfbytN0tDXLPDqOXXTqIvl7RTweJGmzB3WHL7H3w-RKviLI3bqzl3wbxToK6g$> >




    _______________________________________________
    Spasm mailing list
    [e-mail]<mailto:[e-mail]>
    https://www.ietf.org/mailman/listinfo/spasm