Re: [TLS] Creating CSR for encryption-only cert?

[Peter Gutmann]

Brockhaus, Hendrik  writes:

>During the last LAMPS interim call, I mentioned this topic as well. It was
>decided to add support for KEM keys in RFC4210bis. Sean said, that he is
>working on a draft on PoP for KEM keys.

Uhh... CMP has supported KEM keys since day one.  And signing keys, and key
agreement keys, and door keys, and numeric keypad keys, C-minor-scale keys,
wall plaster keys, and yu-shiang whole fish as well because why not?

Peter.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [lamps] Q: Creating CSR for encryption-only cert?

[Martin Thomson]

The integrity of TLS doesn't depend on the key holder presenting proof of 
possession toward the issuing CA.  Perhaps we could define an extension that 
produced an empty signature, so that it could be used for any algorithm without 
these complications...

On Wed, Oct 5, 2022, at 03:05, Russ Housley wrote:
> Uri:
>
> You cannot do it with PKCS#10.  That is why CRMF (RFC 4211) was 
> created.  RFC 2875 and RFC 6955 talk about the proof-of-possession 
> (PoP) of 2875 Diffie-Hellman keys.  A similar PoP specification will be 
> needed for Kyber, and some folks agreed to write the -00 version before 
> IETF 115 (nudge).
>
> Russ
>
>
>> On Oct 4, 2022, at 11:05 AM, Blumenthal, Uri - 0553 - MITLL 
>>  wrote:
>> 
>> TL;DR
>> Need to create a CSR for a key pair whose algorithm does not allow signing 
>> (either because it’s something like Kyber, or because restriction enforced 
>> by HSM). How to do it?
>> 
>> Longer version:
>> 
>> There are several use cases that require certifying long-term asymmetric 
>> keys that are only capable of encryption/decryption – but not 
>> signing/verification. That could be either because the algorithm itself does 
>> not do signing, or because the private key is generated and kept in a secure 
>> hardware that enforces usage restriction. 
>> 
>> One example of a protocol that needs this is KEMTLS - which I hope is 
>> accepted, either as-is, or with simplification.
>> 
>> CSR is supposed to be signed by the corresponding private key to prove 
>> possession. Obviously, it cannot be done with a key such as described above. 
>> How is this problem addressed in the real world?  With AuthKEM and KEMTLS, 
>> how would these protocols get their certificates?
>> 
>> A short discussion of this issue on the OpenSSL mailing list brought up 
>> Certificate Management Protocol (CMP) and CRMF format. Is that where we're 
>> heading? Are the "big CAs" on board with it?
>> 
>> Thanks!
>> -- 
>> V/R,
>> Uri
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [lamps] Q: Creating CSR for encryption-only cert?

[Russ Housley]

Uri:

You cannot do it with PKCS#10.  That is why CRMF (RFC 4211) was created.  RFC 
2875 and RFC 6955 talk about the proof-of-possession (PoP) of 2875 
Diffie-Hellman keys.  A similar PoP specification will be needed for Kyber, and 
some folks agreed to write the -00 version before IETF 115 (nudge).

Russ


> On Oct 4, 2022, at 11:05 AM, Blumenthal, Uri - 0553 - MITLL  
> wrote:
> 
> TL;DR
> Need to create a CSR for a key pair whose algorithm does not allow signing 
> (either because it’s something like Kyber, or because restriction enforced by 
> HSM). How to do it?
> 
> Longer version:
> 
> There are several use cases that require certifying long-term asymmetric keys 
> that are only capable of encryption/decryption – but not 
> signing/verification. That could be either because the algorithm itself does 
> not do signing, or because the private key is generated and kept in a secure 
> hardware that enforces usage restriction. 
> 
> One example of a protocol that needs this is KEMTLS - which I hope is 
> accepted, either as-is, or with simplification.
> 
> CSR is supposed to be signed by the corresponding private key to prove 
> possession. Obviously, it cannot be done with a key such as described above. 
> How is this problem addressed in the real world?  With AuthKEM and KEMTLS, 
> how would these protocols get their certificates?
> 
> A short discussion of this issue on the OpenSSL mailing list brought up 
> Certificate Management Protocol (CMP) and CRMF format. Is that where we're 
> heading? Are the "big CAs" on board with it?
> 
> Thanks!
> -- 
> V/R,
> Uri

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Creating CSR for encryption-only cert?

[Brockhaus, Hendrik]

> Von: Spasm  Im Auftrag von Mike Ounsworth
> 
> Hi Uri,
> 
> > Need to create a CSR for a key pair whose algorithm does not allow signing
> 
> Summary:
> Yes: CMP, EST-with-full-CMC.
> No: Lightweight CMP, EST. ACME should also be here since it requires a CSR.

[HB] As soon as CRMF supports PoP for KEM keys, it can easily be supported 
together with the Lightweight CMP Profile.

Hendrik

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Creating CSR for encryption-only cert?

[Brockhaus, Hendrik]

During the last LAMPS interim call, I mentioned this topic as well. It was 
decided to add support for KEM keys in RFC4210bis.
Sean said, that he is working on a draft on PoP for KEM keys.

Hendrik

> Von: Spasm  Im Auftrag von Blumenthal, Uri - 0553 -
> MITLL
> 
> TL;DR
> Need to create a CSR for a key pair whose algorithm does not allow signing
> (either because it’s something like Kyber, or because restriction enforced by
> HSM). How to do it?
> 
> Longer version:
> 
> There are several use cases that require certifying long-term asymmetric keys
> that are only capable of encryption/decryption – but not signing/verification.
> That could be either because the algorithm itself does not do signing, or 
> because
> the private key is generated and kept in a secure hardware that enforces usage
> restriction.
> 
> One example of a protocol that needs this is KEMTLS - which I hope is 
> accepted,
> either as-is, or with simplification.
> 
> CSR is supposed to be signed by the corresponding private key to prove
> possession. Obviously, it cannot be done with a key such as described above.
> How is this problem addressed in the real world?  With AuthKEM and KEMTLS,
> how would these protocols get their certificates?
> 
> A short discussion of this issue on the OpenSSL mailing list brought up 
> Certificate
> Management Protocol (CMP) and CRMF format. Is that where we're heading?
> Are the "big CAs" on board with it?
> 
> Thanks!
> --
> V/R,
> Uri
> 
> 

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Creating CSR for encryption-only cert?

[Mike Ounsworth]

Hi Uri,

> Need to create a CSR for a key pair whose algorithm does not allow signing

I believe you don't.
I believe that CSR (aka PKCS#10, aka RFC 2986) requires a *signature*.

A couple of years ago I attempted to summarize the state of IETF cert 
enrollment protocols for non-signing keys: see slides 27-28 of my Jan 2021 
LAMPS presentation:
https://datatracker.ietf.org/doc/slides-interim-2021-lamps-01-sessa-position-presentation-by-mike-ounsworth/

Summary:
Yes: CMP, EST-with-full-CMC.
No: Lightweight CMP, EST. ACME should also be here since it requires a CSR.



Shameless plug: I recently did some work with Güneysu, Hodges, Land, Stebila, 
Zaverucha developing a ZKP-based "verifiable generation" KEM PoP mechanism for 
FrodoKEM and Kyber.
https://eprint.iacr.org/2022/703

---
Mike Ounsworth

-Original Message-
From: Spasm  On Behalf Of Blumenthal, Uri - 0553 - MITLL
Sent: October 4, 2022 10:06 AM
To: sp...@ietf.org; tls@ietf.org
Subject: [EXTERNAL] [lamps] Q: Creating CSR for encryption-only cert?

WARNING: This email originated outside of Entrust.
DO NOT CLICK links or attachments unless you trust the sender and know the 
content is safe.

__
TL;DR
Need to create a CSR for a key pair whose algorithm does not allow signing 
(either because it’s something like Kyber, or because restriction enforced by 
HSM). How to do it?

Longer version:

There are several use cases that require certifying long-term asymmetric keys 
that are only capable of encryption/decryption – but not signing/verification. 
That could be either because the algorithm itself does not do signing, or 
because the private key is generated and kept in a secure hardware that 
enforces usage restriction.

One example of a protocol that needs this is KEMTLS - which I hope is accepted, 
either as-is, or with simplification.

CSR is supposed to be signed by the corresponding private key to prove 
possession. Obviously, it cannot be done with a key such as described above. 
How is this problem addressed in the real world?  With AuthKEM and KEMTLS, how 
would these protocols get their certificates?

A short discussion of this issue on the OpenSSL mailing list brought up 
Certificate Management Protocol (CMP) and CRMF format. Is that where we're 
heading? Are the "big CAs" on board with it?

Thanks!
--
V/R,
Uri



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.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Securely disabling ECH

[Salz, Rich]

I do not understand your question.  Let me start with a picture.

Client <-> TLS terminating <-> Desired Origin
Concretely for an example:
Browser <-> a CDN <-> origin for 
www.example.com

The key phrase is the middle entity is a TLS terminating one.  (As opposed to a 
conventional firewall or similar that just forwards packets, which is why I say 
“middle entity” rather than “middle box”

In order to connect to the CDN, it must have a certificate for 
www.example.com and DNS must have sent the browser to 
the CDN.  If not, the browser will fail the connection.

In order to avoid confusion with their own IT structure, it is common for the 
“Example, Com” entity to actually have a different name for their origin 
website, call it origin.example.com

So, can you rephrase your question perhaps?

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Q: Creating CSR for encryption-only cert?

[Blumenthal, Uri - 0553 - MITLL]

TL;DR
Need to create a CSR for a key pair whose algorithm does not allow signing 
(either because it’s something like Kyber, or because restriction enforced by 
HSM). How to do it?

Longer version:

There are several use cases that require certifying long-term asymmetric keys 
that are only capable of encryption/decryption – but not signing/verification. 
That could be either because the algorithm itself does not do signing, or 
because the private key is generated and kept in a secure hardware that 
enforces usage restriction. 

One example of a protocol that needs this is KEMTLS - which I hope is accepted, 
either as-is, or with simplification.

CSR is supposed to be signed by the corresponding private key to prove 
possession. Obviously, it cannot be done with a key such as described above. 
How is this problem addressed in the real world?  With AuthKEM and KEMTLS, how 
would these protocols get their certificates?

A short discussion of this issue on the OpenSSL mailing list brought up 
Certificate Management Protocol (CMP) and CRMF format. Is that where we're 
heading? Are the "big CAs" on board with it?

Thanks!
-- 
V/R,
Uri
 




smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] OCSP and browsers

[Tim Hollebeek]

Also, the amount of work necessary to make Certificate Transparency work with 
three day certificates is probably not worth the effort.

It's not that you can't do it ... the easiest way is to break the 1-1 
correspondence between SCTs and certificates, and make allowances for issuing a 
series of certificates that are identical except for serial numbers and dates, 
and can all reasonably share the same CT entry.  But that's a non-trivial 
redesign.

Blowing up CT logs by a factor of 100 is also possible but less desirable.

I was a huge fan of the extremely short-lived cert idea, but I think it's time 
may have passed.  The compressed CRL stuff that browsers are already 
contemplating and deploying is a better path forward.

-Tim

From: TLS  On Behalf Of Salz, Rich
Sent: Sunday, October 2, 2022 9:14 AM
To: Phillip Hallam-Baker 
Cc: tls@ietf.org
Subject: Re: [TLS] OCSP and browsers


> Now we have ACME, why not move to 3 day certs issued daily and avoid the need 
> for revocation entirely?



Not all CA's in use on the WebPKI support ACME.  Automating a single-host to 
renew every 48 hours (have to allow for faults and retries) is okay, as long as 
you are confident your site will not be done during the "get new cert" window.  
As you scale up to millions of sites and/or thousands of locations, it's much 
less simple.



But I'm still looking for an answer about what browsers and OCSP see as their 
future.


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls