Toerless Eckert <[email protected]> wrote:
    > The need to diligently document support for CRL/OCSP was done on
    > behalf of securiy reviews. It is not meant to be a recommendation.
    > There is mentioning of short-lived certificates in a few places in the
    > doc.

I didn't see an RFC8739 reference.  Oh. It's I-D.ietf-acme-star.
Your section 6.1.5.4 suggests CRLs are unnecessary when the lifetime is on
the order of hours,  while RFC8739 is less specific about what is short.
I think that a certificate lifetime on the order of a week would probably be
workable.

But, I think think we should get implementation experience.

    >> I think that CRLs are not useful, and we should not use them.

    > I think we agree.

Good.

    >> 6.1.3 is clear that OCSP/CRLs may not be available when connecting!
    >>
    >> I think that use of STAR (https://datatracker.ietf.org/doc/rfc8739/ )
    >> Short-Term, Automatically Renewed is the best recommendation!

    > In general yes, but the STAR use cases typically do not take into
    > account  connectivity problems that are longer than the lifetime of
    > a cert, whereas for the ACP this might be a problem.

yes, but the solution is to find a Join Proxy, reach out to the Registrar and
renew the certificate using the LDevID one has.
STAR even went into some detail about how one could renew expired
certificates, I think. (I recall a discussion, but I'd have to check the
document again)

    >> If we have to do OCSP (via https://datatracker.ietf.org/doc/rfc4806/ )
    >> then we nodes can download their staple and provide it when connecting.
    >> New nodes can get this using the Join Proxy.
    >>
    >> Perhaps this needs to be in a new document at this point.

    > Yepp.  I think to remember that MaxP was thinking of suggesting to
    > talk about dealing with expired certs for our cases in i think LAMPS too
    > but longer ago...

yes, the document wound up in ACME, and I think they did a good job, although
it is proscriptive for ACME only, while our end-client interface is assumed
to be EST.

--
Michael Richardson <[email protected]>, Sandelman Software Works
 -= IPv6 IoT consulting =-



Attachment: signature.asc
Description: PGP signature

_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima

Reply via email to