ATIS/SIP Forum IP-NNI Task Force

 View Only

  • 1.  [External] : ALIII Certs

    Posted 3 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 an hour 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 54 minutes 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 20 minutes 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


Related Content