ATIS/SIP Forum IP-NNI Task Force

 View Only

  • 1.  [External] : ALIII Certs

    Posted 5 hours ago
    Hello Chris,

    > No, I am proposing we decouple Domain Validation checks from the certificate management. If you make it a requirement of certificate management, then that essentially forces only the ACME implementation, which as we've discussed is very challenging for non-HTTP use cases.

    We are talking about using domain validated certificates in ALIII. As the name implies, these certificates require the domain to be validated as part of issuance. So, in order to automate certificate issuance (part of certificate management); domain validation must be automated. So if this standard is going to describe a mechanism for certificate management, must it not also describe a mechanism for domain validation?


    > De-coupling it allows for more flexibility in both the Domain Validation and certificate management mechanisms that can be used.

    > Bear in mind, most Public CA's already enforce Domain Validation checks even for certificates that are manually issued, see the below screenshot from Sectigo

    Which of the domain validation mechanisms Sectigo supports would solve the challenges you described?

    • DNS CNAME - How do the challenges you described about dns-01 not apply to this?
    • DNS TXT - How do the challenges you described about dns-01 not apply to this?
    • Email - How would this be automated?
    • HTTP(s) - How do the challenges you described about http-01 not apply to this?
    • Persistent Validation - I expect this domain validation mechanism would solve your concerns. It is worth noting that this is supported by ACME: https://www.ietf.org/archive/id/draft-ietf-acme-dns-persist-01.html

    For dns-01, your concern was that there is not a widely used and standards-based mechanism for DNS updates, so implementations have to use proprietary APIs. I agree with this concern. But your solution to this problem appears to be to make the entire domain validation mechanism proprietary. How does that help?


    > So my proposal would be to specify the requirement for Domain Validation checks between PA and CA, but not make them part of the certificate management automation mechanism itself.

    Can you please elaborate? What would the PA's role in domain validation be? What about the service provider, are you saying they wouldn't be involved in domain validation? How specifically are you proposing that domain validation be performed?


    Sincerely,
    Alec Fenichel
    Chief Technology Officer



  • 2.  RE: [External] : ALIII Certs

    Posted 3 hours ago
    I agree with Alec's points, but have a slightly different but complimentary argument.  

    We should not change the model we chose with SHAKEN certs to include illustrative examples with ACME and continue with the Authority Token model using SPC tokens.  

    But importantly and to the larger sentiment (i think), DO NOT say ACME or any one API is the only option a CA must implement.  

    Every CA can and does provide one or many certificate issuance API interfaces.  In the deployed SHAKEN world there is many that have proprietary APIs that are in use, but many also implement ACME as their primary interface.  This works fine and is more of a vendor decision criteria vs an interoperability issue.

    So, I'm not sure why this is much of an argument in the first place.  

    To be clear, I would like to support the definition of an ACME profile that is defined and would volunteer to help to define if needed, I think there is already work on this, but if others want to contribute and support the definition of other API profiles in the specs I have no issues with that either. Point being, there is really no reason to restrict or say there is only one allowed, exactly parallel what we do for SHAKEN certificates.  Certificate interfaces are part of the commercial offerings of the CA, not a standards decision.  

    -Chris





  • 3.  RE: [External] : ALIII Certs

    Posted 2 hours ago

    Hi Chris,

    So I'm not proposing we change anything on the SHAKEN side, as ACME is the best choice there (because SHAKEN is over HTTP). I'm specifically talking about any interface where SIP is used.

    @Alec - What I mean by decoupling, is simply that instead of mandating that the domain validation checks be performed automatically as part of the certificate management process (which would leave ACME as the only option), we require that domain validation be a mandatory process for issuance, but separately from the act of automating the certificate management. This would allow other certificate management protocols that actually work with SIP to be used (eg. CMPv2, SCEP, EST) while ensuring that the CA does not allow for the issuance of any certificate that has not already had it's domain validated.

    In the Sectigo example, the 3 top options (DNS CNAME, DNS TXT and Email) could all be used to provide domain ownership 'out of band' from the actual certificate management request.

    In an ideal world, the IETF would add support for Domain Validation of SIP endpoints in to ACME (even adjusting TLS-ALPN01 to allow for use on port 5061 would be enough), but this has yet to be submitted.

    N.B. I means AVSP not PA in the previous email.

    Regards,

    Chris


    Original Message


  • 4.  RE: [External] : ALIII Certs

    Posted 2 hours ago
    I am also not talking about changing anything on the SHAKEN side, but what I am arguing is that we should keep the same model on the ALIIIs side in terms of an authority token or SPC token and how it's governed and validated.

    But I am a bit concerned at what you are suggesting.  Are you saying that all ALIII SIP solutions MUST only support certain CA interfaces going forward?  Why limit it for ALIII or for SIP in general?  That makes zero sense, it's not a call level network interoperability issue we are discussing here.  

    Not saying an IETF spec wouldn't help and agree its useful to support a widely adopted SIP over TLS profile.  But it's not part of the SIP itself, purely a certificate interface.

    -Chris



    Original Message


  • 5.  RE: [External] : ALIII Certs

    Posted an hour ago
    Chris,

    So, how would an IETF RFC affect the timeline?

    Martin C Dolly

    AT&T

    Expert Member of Technical Staff

    Government & Services Standards

    +1 609 903 3360




    Original Message


  • 6.  RE: [External] : ALIII Certs

    Posted an hour ago
    There is two things.  

    1. A SIP over TLS profile document that documents how to use ACME for TLS in SIP.  I think this is mostly informational (in my opinion and can just happen in IPNNI) because ACME and SIP over TLS stand independently and this is mostly an operational configuration, not an interoperability problem, but its not a bad thing to have an IETF reviewed draft as well as always, but i don't think it would be a blocker for progress in IPNNI.
    2. An Authority Token profile for TLS certificates.  If we can agree on the existing specified dns-01 mechanism, then I think no additional IETF work is needed.  ACME already supports a challenge with dns-01 and we already have TNAuthList authority token challenge.  So, all we (IPNNI) says is that you need to do both challenges to issue a certificate.  No new normative specs needed in IETF.

    -Chris



    Original Message


  • 7.  RE: [External] : ALIII Certs

    Posted 43 minutes ago
    I agree with Chris W.

    The web world is moving to 10-day reuse of domain validation: https://cabforum.org/working-groups/server/baseline-requirements/requirements/#421-performing-identification-and-authentication-functions. I don't think IP-NNI should try to second guess this expert opinion.

    The web world is also moving to a maximum of 47-day certificates: https://cabforum.org/working-groups/server/baseline-requirements/requirements/#632-certificate-operational-periods-and-key-pair-usage-periods. The web world is allowing certificates without a CRL if the lifetime is 7 days or less: https://cabforum.org/working-groups/server/baseline-requirements/requirements/#4911-reasons-for-revoking-a-subscriber-certificate. I don't think IP-NNI should try to second guess this expert opinion. However, we actually have more to consider than the web world did. Just like in the web world, we need these certificates for authenticating servers over the internet. But we also need these certificates for authenticating clients as members of the ecosystem. So we may need to consider shorter lifetimes than the web world.

    If we are planning on using short lived certificates, then we need automation. Here are some blogs from web CAs saying just that:


    Digicert said: "As of March 15, 2029, the maximum lifetime for a TLS certificate will be 47 days, but the maximum period during which domain validation information may be reused is only 10 days. Manual revalidation will still technically be possible, but doing so would be a recipe for failure and outages." (emphasis my own)

    Secitgo said: "Automation is now imperative to business continuity, security, and crypto agility."

    Digicert was even explicit in their blog explaining that this automation is needed for domain validation.

    There is an existing standard for automated certificate issuance and domain validation: ACME. So far, the complaints about ACME have been that the automated domain validation described in ACME are hard for an SBC to do. But what is the proposed mechanism for automated domain validation that is easy for an SBC to do?

    And what is the issue with draft-ietf-acme-dns-persist-01?

    Sincerely,
    Alec Fenichel
    Chief Technology Officer




    Original Message


  • 8.  RE: [External] : ALIII Certs

    Posted an hour ago
    Hello Chris T.,

    > So I'm not proposing we change anything on the SHAKEN side, as ACME is the best choice there (because SHAKEN is over HTTP). I'm specifically talking about any interface where SIP is used.

    How is SHAKEN over HTTP?

    > @Alec - What I mean by decoupling, is simply that instead of mandating that the domain validation checks be performed automatically as part of the certificate management process (which would leave ACME as the only option), we require that domain validation be a mandatory process for issuance, but separately from the act of automating the certificate management. This would allow other certificate management protocols that actually work with SIP to be used (eg. CMPv2, SCEP, EST) while ensuring that the CA does not allow for the issuance of any certificate that has not already had it's domain validated.

    I think it is worth repeating that I am not suggesting that we mandate ACME.

    But how does CMPv2 work for SIP when ACME does not? The issues you have described with ACME have nothing to do with ACME; they are about domain validation. You would still need to perform domain validation if you used CMPv2.

    > In the Sectigo example, the 3 top options (DNS CNAME, DNS TXT and Email) could all be used to provide domain ownership 'out of band' from the actual certificate management request.

    Again, how does this solve any of the concerns you described? Whether it is "in-band" or "out-of-band", these domain validation mechanisms must still be re-performed to renew a certificate (note that there is a period of time where the domain validation can be reused, typically the certificate lifetime, so if you requested 2 certificates with the same domains around the same time then you might only need to perform domain validation once).

    How would you perform the DNS changes needed for Sectigos DNS CNAME or DNS TXT validation mechanisms? Whatever the answer, why can't you use the same mechanism for ACME dns-01?

    > In an ideal world, the IETF would add support for Domain Validation of SIP endpoints in to ACME (even adjusting TLS-ALPN01 to allow for use on port 5061 would be enough), but this has yet to be submitted.

    What is the issue with dns-persist-01?

    Sincerely,
    Alec Fenichel
    Chief Technology Officer




    Original Message


Related Content