search

lamps-wg / draft-composite-kem

IETF draft specifying PQC composite KEM algorithms for use in X.509 and CMS
Other
6 stars 3 forks source link

Clarifications on ASN.1 representations #69

Closed codespree closed 2 months ago

codespree commented 2 months ago

So, the composite private key is a sequence of two OneAsymmetricKey structures. What are the OID values for the privateKeyAlgorithm fields of the two OneAsymmetricKey structures? Are we to assume the OID values are the same as the OID values of the component KEM algorithms - i.e:

For elliptic curve component KEM:
```
KemType::P256 => "1.2.840.10045.3.1.7".to_string(),
KemType::P384 => "1.3.132.0.34".to_string(),
// RFC 8410
KemType::X25519 => "1.3.101.110".to_string(),
KemType::X448 => "1.3.101.110".to_string(),
// RFC 5639
KemType::BrainpoolP256r1 => "1.3.36.3.3.2.8.1.7".to_string(),
KemType::BrainpoolP384r1 => "1.3.36.3.3.2.8.1.11".to_string(),
```

For RSA component KEM:
```
KemType::RsaOAEP2048 => "1.2.840.113549.1.1.7".to_string(),
KemType::RsaOAEP3072 => "1.2.840.113549.1.1.7".to_string(),
KemType::RsaOAEP4096 => "1.2.840.113549.1.1.7".to_string(),
```

For ML-KEM component KEM:
```
KemType::MlKem512 => "2.16.840.1.101.3.4.4.1".to_string(),
KemType::MlKem768 => "2.16.840.1.101.3.4.4.2".to_string(),
KemType::MlKem1024 => "2.16.840.1.101.3.4.4.3".to_string(),
```
codespree commented 2 months ago

@ounsworth @dconnolly @danvangeest @opencrypto I am new to the community. I have implemented the Editor's draft version in Rust: https://github.com/codespree/quantcrypt

Would appreciate a review. If you think there could be more people who can get involved in contributing to the repo or testing, I would welcome it.

All the KEM algorithms mentioned in the draft are implemented.

Test bytes of expected input would be good so that we can track if the implementations are correct.

PiotrPopis commented 2 months ago

Section 3.3 [composite-kem] should be as follows: Use cases that require an inter-operable encoding for composite private keys, such as when private keys are carried in PKCS #12 [RFC7292], CMP [RFC4210] or CRMF [RFC4211] MUST use the following structure.

CompositeKEMPrivateKey ::= SEQUENCE SIZE (2) OF OCTET STRING

Each element of this sequence is a private key, and this sequence is contained in the privateKey field of the OneAsymmetricKey structure [RFC5958].

The order of the component keys is the same as the order defined in Section 3.2 for the components of CompositeKEMPublicKey.

When a CompositeKEMPrivateKey is conveyed inside a OneAsymmetricKey structure (version 1 of which is also known as PrivateKeyInfo) [RFC5958], the privateKeyAlgorithm field SHALL be set to the corresponding composite algorithm identifier defined according to Section 5 (the parameters field MUST be absent), the privateKey field SHALL contain the CompositeKEMPrivateKey, and the publicKey field MUST NOT be present. Associated public key material MAY be present in the OneAsymmetricKey structure containing CompositeKEMPrivateKey and in that case version is 2.

In some use-cases the private keys that comprise a composite key may not be represented in a single structure or even be contained in a single cryptographic module; for example if one component is within the FIPS boundary of a cryptographic module and the other is not; see Appendix C.1 for more discussion. The establishment of correspondence between public keys in a CompositeKEMPublicKey and private keys not represented in a single composite structure is beyond the scope of this document.

I especially draw your attention to the sentence that does not change: The order of the component keys is the same as the order defined in Section 3.2 for the components of CompositeKEMPublicKey. This sentence indicates that we could have one OID for the composite algorithm, hence one OneAsymmetricKey sequence with two private keys (two sequences in the privateKey field) is enough.

danvangeest commented 2 months ago

Hi @codespree,

There is an IETF hackathon repo with test artifacts: https://github.com/IETF-Hackathon/pqc-certificates. Composite KEMs aren't included yet, but I wouldn't be surprised if they are added.

In addition to the hackathon at every IETF meeting, every 4 months, which is free to attend in person or online, we also have a monthly online meeting. We can invite you to the next one, just give an email address to send the invitation to.

@ounsworth @dconnolly @danvangeest @opencrypto I am new to the community. I have implemented the Editor's draft version in Rust: https://github.com/codespree/quantcrypt

Would appreciate a review. If you think there could be more people who can get involved in contributing to the repo or testing, I would welcome it.

All the KEM algorithms mentioned in the draft are implemented.

Test bytes of expected input would be good so that we can track if the implementations are correct.

PiotrPopis commented 2 months ago

Hi

Thank you for the invitation. My email address: @.***

I only have concerns about the time zone differences for online meetings.😊

Regards – Piotr Popis

From: Daniel Van Geest @.> Sent: Tuesday, September 24, 2024 1:54 PM To: lamps-wg/draft-composite-kem @.> Cc: PiotrPopis @.>; Comment @.> Subject: Re: [lamps-wg/draft-composite-kem] Clarifications on ASN.1 representations (Issue #69)

Hi https://github.com/codespree @codespree,

There is an IETF hackathon repo with test artifacts: https://github.com/IETF-Hackathon/pqc-certificates https://github.com/IETF-Hackathon/pqc-certificates. Composite KEMs aren't included yet, but I wouldn't be surprised if they are added.

In addition to the hackathon at every IETF meeting, every 4 months, which is free to attend in person or online, we also have a monthly online meeting. We can invite you to the next one, just give an email address to send the invitation to.

https://github.com/ounsworth @ounsworth https://github.com/dconnolly @dconnolly https://github.com/danvangeest @danvangeest https://github.com/opencrypto @opencrypto I am new to the community. I have implemented the Editor's draft version in Rust: https://github.com/codespree/quantcrypt https://github.com/codespree/quantcrypt

Would appreciate a review. If you think there could be more people who can get involved in contributing to the repo or testing, I would welcome it.

All the KEM algorithms mentioned in the draft are implemented.

Test bytes of expected input would be good so that we can track if the implementations are correct.

— Reply to this email directly, https://github.com/lamps-wg/draft-composite-kem/issues/69#issuecomment-2371049605 view it on GitHub, or https://github.com/notifications/unsubscribe-auth/BLIOPUVAJ6V77MURZKIAGVLZYFHFRAVCNFSM6AAAAABOSVU73OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNZRGA2DSNRQGU unsubscribe. You are receiving this because you commented.Message ID: @.***>

danvangeest commented 2 months ago

Hi Piotr,

You email address is blanked out in github, but I have found it from the LAMPS emails.

And for @codespree if you'd like an invite, you can find my email address in https://datatracker.ietf.org/doc/draft-ietf-lamps-x509-slhdsa/, just send me a note and we'll get you invited.

codespree commented 2 months ago

👍🏼 Using the examples from here makes it very clear. As long as this draft is following the specs in version 2 of that draft.

I have implemented it in this here:

Referring to the DSA draft from the KEM draft would be helpful.

So, the composite private key is a sequence of two OneAsymmetricKey structures. What are the OID values for the privateKeyAlgorithm fields of the two OneAsymmetricKey structures? Are we to assume the OID values are the same as the OID values of the component KEM algorithms - i.e:

For elliptic curve component KEM:
```
KemType::P256 => "1.2.840.10045.3.1.7".to_string(),
KemType::P384 => "1.3.132.0.34".to_string(),
// RFC 8410
KemType::X25519 => "1.3.101.110".to_string(),
KemType::X448 => "1.3.101.110".to_string(),
// RFC 5639
KemType::BrainpoolP256r1 => "1.3.36.3.3.2.8.1.7".to_string(),
KemType::BrainpoolP384r1 => "1.3.36.3.3.2.8.1.11".to_string(),
```

For RSA component KEM:
```
KemType::RsaOAEP2048 => "1.2.840.113549.1.1.7".to_string(),
KemType::RsaOAEP3072 => "1.2.840.113549.1.1.7".to_string(),
KemType::RsaOAEP4096 => "1.2.840.113549.1.1.7".to_string(),
```

For ML-KEM component KEM:
```
KemType::MlKem512 => "2.16.840.1.101.3.4.4.1".to_string(),
KemType::MlKem768 => "2.16.840.1.101.3.4.4.2".to_string(),
KemType::MlKem1024 => "2.16.840.1.101.3.4.4.3".to_string(),
```

👍🏼 Same as above

👍🏼 I understand this is pseudocode

Sample keys using RSA would be helpful

codespree commented 2 months ago

Thanks @danvangeest . I am closing this issue. Samples on RSA keys (with and without PSS) would be very helpful in wither of the two drafts.

carl-wallace commented 2 months ago

Hi @codespree,

There is an IETF hackathon repo with test artifacts: https://github.com/IETF-Hackathon/pqc-certificates. Composite KEMs aren't included yet, but I wouldn't be surprised if they are added.

In addition to the hackathon at every IETF meeting, every 4 months, which is free to attend in person or online, we also have a monthly online meeting. We can invite you to the next one, just give an email address to send the invitation to.

@ounsworth @dconnolly @danvangeest @opencrypto I am new to the community. I have implemented the Editor's draft version in Rust: https://github.com/codespree/quantcrypt Would appreciate a review. If you think there could be more people who can get involved in contributing to the repo or testing, I would welcome it. All the KEM algorithms mentioned in the draft are implemented. Test bytes of expected input would be good so that we can track if the implementations are correct.

I implemented composite KEM support a few months back but have not tested against any other implementation. The work is here: https://github.com/carl-wallace/kemri_toy/commits/composite.