Salz, Rich <[email protected]> wrote:
      > Yaron and I cannot attend and will be remote.  We have volunteers to
      > act as chairs for us (on CC).  Looking at the list below, it seems
      > reasonable to cancel our session.  PLEASE POST IF YOU DISAGREE.  Of
      > course "they" may decide to cancel anyway, but please post your
      > opinion here.

Hi, if you are going to cancel (I would prefer NOT to), then please schedule
    a virtual interim for early April to replace it.

    > draft-ietf-acme-authority-token-04, ACME Challenges Using an Authority 
Token -and-
    > draft-ietf-acme-authority-token-tnauthlist-05,  TNAuthList profile of 
ACME Authority Token
    > Any update from the authors?  Is this ready for WGLC?
    > This has never had much in-person discussion, and the domain expertise is 
in STIR

I have read this document when it came up in STIR, and I don't think that
here is much to say about this.  Is there feedback from implementers? I don't
think that this needs face time to advance.

    > draft-ietf-acme-client-00, ACME End User Client and Code Signing 
Certificates
    > Any updates?  This was recently adopted by the WG.

no idea.

    > draft-ietf-acme-integrations-00, ACME Integrations
    > Michael Richardson can present.

I was given some slides (wasn't I Owen? Or did you just say that you'd send
some), and the major item was to clarify the changes that were made based
comments.   I think that there isn't much to say.   I have running code that
integrates ACME with a BRSKI Registrar.

    > draft-friel-acme-subdomains-02
    > Michael Richardson can present; this is a topic for WG adoption

At first, I think that we thought that this work required no standard action,
because it was within the server's policy to do this or not.
However, the client may not know the server's policy, and so section 5 adds
the basedomain and implicitSubdomainAuthorization boolean.  If it comes back
false (or missing), then the client knows it has to perform authorizations for
every request (which is what my code above does).

I think that the WG previously expressed interest in adopting it, pending
some changes, and those changes are made.  It may not need actual WG time,
except that having it on a schedule sometimes gets a document read :-)

    > draft-ietf-acme-email-smime-06, Extensions to Automatic Certificate
    > Management Environment for end user S/MIME certificates
    > Any updates?  Ready for WGLC?

    > draft-ietf-acme-star-delegation-03, An ACME Profile for Generating 
Delegated STAR Certificates
    > Yaron just pushed a new update.  Does this need F2F time?  The main
    > document (draft-ietf-acme-star-11,  Support for Short-Term,
    > Automatically-Renewed (STAR) Certificates in Automated Certificate
    > Management Environment (ACME) is already in IESG review and probably
    > wants this one to be in the same bundle.)

I think both are ready to be adopted.

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

Attachment: signature.asc
Description: PGP signature

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

Reply via email to