Subject: [lamps] Call for adoption of draft-nir-saag-star

From: Tim Hollebeek <[email-masked]>
Date: Sat, 14 Jul 2018 16:01:05 +0000

The recently approved LAMPS WG Charter adds this work item:

3. Specify the use of short-lived X.509 certificates for which no revocation
information is made available by the Certification Authority.

Short-lived certificates have a lifespan that is shorter than the time
needed to detect, report, and distribute revocation information.  As a
result, revoking short-lived certificates is unnecessary and pointless.

It has been suggested that the WG adopt draft-nir-saag-star as the starting
point for this work.  Please voice your support or concerns on the list.

---

From: Melinda Shore <[email-masked]>
Date: Sat, 14 Jul 2018 12:22:53 -0400

On 7/14/18 12:01 PM, Tim Hollebeek wrote:
> It has been suggested that the WG adopt draft-nir-saag-star as the
> starting point for this work.  Please voice your support or concerns on
> the list.

I've read it and think it's a good place to start.

Melinda

-- 
Software longa, hardware brevis

PGP key fingerprint  4F68 2D93 2A17 96F8 20F2
                     34C0 DFB8 9172 9A76 DB8F

---

From: Ryan Sleevi <[email-masked]>
Date: Sun, 15 Jul 2018 09:39:48 +0900

On Sun, Jul 15, 2018 at 1:01 AM Tim Hollebeek <[email-masked]>
wrote:

> 3. Specify the use of short-lived X.509 certificates for which no
> revocation information is made available by the Certification Authority.
>
>
>
> starting point for this work.  Please voice your support or concerns on the
> list.
>
>
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm

I have read it, and as expressed during the charter discussion, do not
support it as a place to start in its current form.

The problem statement that it seems to address is still ill-defined, and
it’s explanations for certain design choices are still contradictory and
inconsistent. As such, it’s technical proposals lack merit for the problem
or cohesion as a solution, and more work should be done to clearly
articulate the problem and solution space prior to adoption.

> <https://www.ietf.org/mailman/listinfo/spasm>
>

---

From: "Dr. Pala" <[email-masked]>
Date: Tue, 17 Jul 2018 08:40:00 -0600

Hi all,

I have expressed my concerns about this work in the past and I agree
with the conclusion from Ryan. Therefore I do not support its adoption
as well in its current form.

Cheers,
Max

On 7/14/18 6:39 PM, Ryan Sleevi wrote:
> [...]
> The problem statement that it seems to address is still ill-defined,
> and it’s explanations for certain design choices are still
> contradictory and inconsistent. As such, it’s technical proposals lack
> merit for the problem or cohesion as a solution, and more work should
> be done to clearly articulate the problem and solution space prior to
> adoption.
>  
>

-- 
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo

---

From: Daniel Migault <[email-masked]>
Date: Tue, 17 Jul 2018 12:00:27 -0400

I see the draft as a good placeholder for the discussion to happen. I
support its adoption.

Yours,
Daniel

On Tue, Jul 17, 2018 at 10:40 AM, Dr. Pala <[email-masked]> wrote:

> Hi all,
>
> I have expressed my concerns about this work in the past and I agree with
> the conclusion from Ryan. Therefore I do not support its adoption as well
> in its current form.
>
> Cheers,
> Max
>

---

From: Russ Housley <[email-masked]>
Date: Fri, 27 Jul 2018 13:48:50 -0400

This document was discussed at IETF 102 in Montreal.  the DRAFT minutes say:

'"""
A WG call for adoption is underway.  This document is about Short-Term
Auto-Renewed (STAR) certificates.  There is no revocation information
for these certificates, and the short validity period of makes this
acceptable.  The automatic issuance of replacement certificates
overcomes the operational challenges of short-term certificates.
Two use cases are driving this work: IPsec VPNs and software-defined
storage.  These certificate might not be suitable for the Web PKI.

Many people in the room felt that an extension for that tells the
relying party that no revocation information is available is needed.
The authors feel that such an extension should be defined in another
document; this document should remain a BCP.

Some people felt that these certificates should point to an empty CRL
and a similar OCSP responder so that anyone looking for revocation
information would not get a failure.

Some people felt that the WG should not adopt this document until
it addresses thes two topics.
"""

My conclusion from this discussion is that an update to the Internet-Draft is needed for the LAMPS WG to consider adoption.  Please speak now id you come to a different conclusion.

Russ

> On Jul 14, 2018, at 12:01 PM, Tim Hollebeek <[email-masked]> wrote:
> 
>  
> 3. Specify the use of short-lived X.509 certificates for which no revocation information is made available by the Certification Authority.
>  
> Short-lived certificates have a lifespan that is shorter than the time needed to detect, report, and distribute revocation information.  As a result, revoking short-lived certificates is unnecessary and pointless.
>  
> It has been suggested that the WG adopt draft-nir-saag-star as the starting point for this work.  Please voice your support or concerns on the list.
>

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 30 Jul 2018 02:19:32 +0200

> document; this document should remain a BCP.

Separating normative from informational text is always a WGs style
option. Guidance from the WG chairs would be useful.

Personally (not speaking for the co-authors), i am a fan
of indicating in a certificate how/where to renew it. After all,
certificates allow to include CRL, which helps a lot for discovery,
so why not have the same for renewal URL. And figuring out how
to indicate that the semantic is STAR. For example, you may have
a STAR certificate, sign an offline data item, and when it arrives,
the STAR certificate has expired - but the recipient may still go
to the renewal URL and query if there is a current certificate 
(for the same identity) and leverage that as additional information
if the originator is "still" to be trusted.

> information would not get a failure.

I don't quite remember who raised this point and expicitly for
what reason, the minutes don't say. Maybe whoever raised the point
could chime in.

If you already have useable CRL/OCSP, this option seems like a useful
simplification, but it does not address the most lightweight instance
of STAR where you do NOT want to set up (unnecessarily) any CRL/OCSP
infra. Maybe whoever raised the issue would be fine if the solution
space would be framed this way ?

Cheers
    Toerless

---

From: "Dr. Pala" <[email-masked]>
Date: Mon, 30 Jul 2018 11:43:46 -0600

Hi Russ, all,

On 7/27/18 11:48 AM, Russ Housley wrote:
> My conclusion from this discussion is that an update to the
> Internet-Draft is needed for the LAMPS WG to consider adoption.
>  Please speak now id you come to a different conclusion.
>
> Russ
>
>
I share the same view - I think that your conclusion correctly captures
the room's sentiment - I think that was clear from the humming about
that and the overall comments / discussion.

Cheers,
Max

-- 
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo