> > Whereas in this case, the proposal seems to be to make them another key > type that is not a COSE_Key, and that is specific to HPKE. > > The gist of the argument that Ajitomi and Ilari are making seems to be: > > The epk in HPKE does not need to be a standard format, because the > standard format uses too many bytes, and includes extraneous information. > > If I got the argument wrong, please correct me. >
Yes, that's right. > the standard format ... includes extraneous information. More precisely, the standard format includes ONLY extraneous information (except for the key itself). kty <= determined by the recipient public key. crv <= determined by the recipient public key. // common parameters from https://www.iana.org/assignments/jose/jose.xhtml#web-key-parameters use <= now we are obviously doing key derivation. key_ops <= now we are obviously doing key derivation. alg <= determined by the recipient public key (if needed). kid <= not necessary for ephemeral keys. x5u <= not necessary for ephemeral keys. x5c <= not necessary for ephemeral keys. x5t <= not necessary for ephemeral keys. x5t#S256 <= not necessary for ephemeral keys. To begin with, I think an ephemeral public key should not be expressed with JWK/COSE_Key. There is another important perspective. See the COSE-HPKE pseudo code as follows (please forgive any inaccuracies). ``` # A sender calls the function as follows: # cipher_text = cose_encypt(recipient_public_key, "secret_message", alg=0x1234(="HPKE")); def *cose_encrypt*(public_key: COSEKey, plain_text: bytes, ?alg: uint16) -> bytes: # s-0: recognizes COSE-HPKE with alg (and public_key). # >>> COSE-HPKE process # s-1: determines a specific HPKE cipher suite which consists of KEM, KDF and AEAD. hpke_cipher_suite = determine_hpke_cipher_suite(public_key, ?alg, ?sender_preference); # s-2: coverts COSEKey-typed public key to raw key. raw_public_key = public_key.to_bytes(); # s-3: calls HPKE seal function which returns a cipher text and an encapsulated key. cipher_text, *enc* = *hpke_seal*(hpke_cipher_suite, raw_public_key, plain_text, ?aad); # s-4: build HPKE sender information that should be informed to the recipient. # *** We are all discussing only this step. *** sender_info = build_sender_info(hpke_cipher_suite, *enc*); # s-5: builds a cose message and returns it. encrypted_cose_msg = build_cose_msg(public_key.kid, alg, sender_info, cipher_text); return encrypted_cose_msg; # A recipient calls the function as follows: # plain_text = cose_encypt(recipient_private_keys, encrypted_cose_msg); def *cose_decrypt*(private_keys: Array[COSEKey], encrypted_cose_msg: bytes) -> bytes: # r-0: gets alg from the encrypted_cose_msg and recognizes COSE-HPKE with alg. alg = get_alg(encrypted_cose_msg); # >>> COSE-HPKE process # r-1: parses the encrypted_cose_msg # and extracts information required for HPKE decryption. kid, sender_info, cipher_text = parse_cose_msg(encrypted_cose_msg); # r-2: parses sender_info. hpke_cipher_suite, *enc* = parse_sender_info(sender_info); # r-3: determines a specific private key # and validates that the key can be used for HPKE decryption. private_key = private_keys.get(kid); # r-4: coverts COSEKey-typed private key to raw key. raw_private_key = private_key.to_bytes(); # r-5: calls HPKE open function which returns decrypted plain text. plain_text = *hpke_open*(hpke_cipher_suite, raw_private_key, *enc*, cipher_text, ?aad); return plain_text; ``` As shown above, the enc is generated and consumed internally (in the COSE-HPKE process).It does not emerge on the COSE interface. While the recipient's public key and private keys need to be expressed with COSE_Key, there is no need to express enc with COSE_Key. I believe that the dedicated data structure for HPKE sender information(consists of enc and a selected HPKE cipher suite) should be introduced so that the COSE-HPKE process can be implemented as simply, effectively and securely as possible. Regards, Daisuke 2022年9月6日(火) 22:42 Orie Steele <[email protected]>: > I think one point of confusion may be that in JOSE, ephemeral public keys > are JWKs... for example: > > "jwe": { > "protected": "eyJlbmMiOiJYQzIwUCJ9", > "recipients": [ > { > "header": { > "kid": "did:example:123#key-0", > "alg": "ECDH-ES+A256KW", > "epk": { > "kty": "OKP", > "crv": "X25519", > "x": "17sQFStg7ORPTq20OtU_MOzdzOU9iJAbqMP4cYVmUR0" > }, > "apu": "17sQFStg7ORPTq20OtU_MOzdzOU9iJAbqMP4cYVmUR0", > "apv": > "ZGlkOmtleTp6Nk1rdENpMjlpQXdVaVZEYWV3U1N0SFZXNXFoQnhaVEdYQkZYTTlZRDlSaXNiRm4jejZMU240V3E1WEU0RmdKOGp5S3NzMWtMNUdxd3NuN2dWZ3NLcE5FUEdITWVDeFFx" > }, > "encrypted_key": > "mtKsC05glLghX4s6LGva3Nr9A_l9SYVdQviB81HJRoiAfi0HfhkvnQ" > } > ], > "iv": "IpYeFb6utO2J_Ii8R50d-O9ppiEOQZN2", > "ciphertext": "ewKbg3EJ6Pm4dH1tGdXGkJO5rTiMbn-tnfDGSvyvdQHD7HeE9g", > "tag": "QYakakAfhHJ0KRXM47_uRQ" > } > > Whereas in this case, the proposal seems to be to make them another key > type that is not a COSE_Key, and that is specific to HPKE. > > The gist of the argument that Ajitomi and Ilari are making seems to be: > > The epk in HPKE does not need to be a standard format, because the > standard format uses too many bytes, and includes extraneous information. > > If I got the argument wrong, please correct me. > > Regards, > > OS > > > On Mon, Sep 5, 2022 at 6:35 AM AJITOMI Daisuke <[email protected]> wrote: > >> Hi Michael, >> >> >>> Now what I understand is that HPKE (some HPKEs?) do not produce a series >>> of >>> octets that can just be called a key. Is that correct? >> >> >> No, it isn't. The HPKE encryption process produces an encapsulated key >> (an ephemeral public key) as a series of octets. >> >> Regards, >> Daisuke >> >> 2022年9月4日(日) 17:33 Michael Richardson <[email protected]>: >> >>> >>> Hi, permit me to ask some really dumb questions, which may reveal >>> where the understanding gap is :-) >>> >>> Orie Steele <[email protected]> wrote: >>> > Thanks for this email, responses inline: >>> >>> > On Sat, Sep 3, 2022 at 9:43 AM AJITOMI Daisuke <[email protected]> >>> >>> >> 1) There is no guarantee that enc can be mapped to COSE_Key in the >>> >> future, so if a new HPKE cipher suite is specified, it cannot be >>> used >>> >> on COSE immediately. Whenever a new cipher suite is added to >>> HPKE, it >>> >> is necessary to develop a mapping specification for COSE_Key >>> >> (including alg/crv value registration to IANA) and implement an >>> >> additional enc->COSE_Key conversion process in existing many COSE >>> >> libraries. As a library implementer (I'm also a COSE/CWT >>> implementer >>> >> https://github.com/dajiaji/python-cwt ...), I cannot overlook >>> this... >>> >> >>> >>> os> I agree, this is a major problem.. but it's not limited to COSE, >>> it's >>> os> also a concern for JOSE... and PGP.... and SSH... >>> >>> I've been watching from the sidelines. I haven't really understood the >>> problem. >>> HPKE is a organ grinder with a handle that I turn, and I haven't really >>> had time/interest to look inside. >>> >>> Now what I understand is that HPKE (some HPKEs?) do not produce a series >>> of >>> octets that can just be called a key. Is that correct? >>> >>> Why isn't this a CFRG problem to go and define a clear mapping, so that >>> everyone can just use the same thing? Is it the case that one part of >>> the >>> IRTF/IETF is producing metric bolts, whole the other part is requiring >>> imperial gauge ones? >>> >>> > 1. Keys should be used for one purpose, and under one algorithm. >>> >>> > implicit 4. From 3, don't attempt to "infer" `alg`... require >>> it... for >>> > example, P-256 can be used for signatures and encryptions, when >>> `alg` >>> > and `use` are absent, inference is ambiguous without sufficient >>> > context. >>> >>> I guess I would say that the COSE Protocol designer must >>> >>> > There are 2 registries that will need to be updated in order for >>> your >>> > new "alg" to be understood. >>> >>> > - https://www.iana.org/assignments/jose/jose.xhtml - >>> > https://www.iana.org/assignments/cose/cose.xhtml >>> >>> > I interpret this as an answer to your question... There __is__ a >>> > guarantee that `enc` can be mapped to `COSE_Key` in the future, but >>> > only for `enc` and `COSE_Key` that have been properly registered, >>> and >>> > not before that, can they be safely used with COSE. >>> >>> Reasonable to me. >>> >>> I have found that some young academics think that every algorithm in an >>> IANA >>> Registry must be acceptable as valid, because ... IANA... in the same way >>> that some people think a CA signing a certificate authorizes the >>> possessor of the >>> key to do stuff. >>> >>> > I'm struggling to visualize how this would actually work based on >>> the >>> > text in this email, and your example. >>> >>> > As a developer, I'm expecting something like this: >>> >>> > standard_ciphertext = encrypt ( standard_msg, standard_public_key, >>> ?alg >>> > ) ... where either standard_public_key contains `alg` or it is >>> required >>> >>> Me too. >>> >>> >>> -- >>> Michael Richardson <[email protected]>, Sandelman Software Works >>> -= IPv6 IoT consulting =- >>> >>> >>> >>> _______________________________________________ >>> COSE mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/cose >>> >> > > -- > *ORIE STEELE* > Chief Technical Officer > www.transmute.industries > > <https://www.transmute.industries> >
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
