Re: [Acme] Practical concerns of draft-ietf-acme-ari

[Q Misell <[e-mail]>]

> RFC5280 permits CAs to populate
AuthorityKeyIdentifier.{authorityCertIssuer,authorityCertSerialNumber}
instead of AuthorityKeyIdentifier.keyIdentifier.

Do we instead use a structure containing the full AKI (as encoded in the
certificate) and the serial number? This would seem to me to allow unique
identification, without having the issuer certificate to hand.
------------------------------

Any statements contained in this email are personal to the author and are
not necessarily the statements of the company unless specifically stated.
AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace,
Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company
registered in Wales under № 12417574
<https://find-and-update.company-information.service.gov.uk/company/12417574>,
LEI 875500FXNCJPAPF3PD10. ICO register №: ZA782876
<https://ico.org.uk/ESDWebPages/Entry/ZA782876>. UK VAT №: GB378323867. EU
VAT №: EU372013983. Turkish VAT №: 0861333524. South Korean VAT №:
522-80-03080. AS207960 Ewrop OÜ, having a registered office at Lääne-Viru
maakond, Tapa vald, Porkuni küla, Lossi tn 1, 46001, trading as Glauca
Digital, is a company registered in Estonia under № 16755226. Estonian VAT
№: EE102625532. Glauca Digital and the Glauca logo are registered
trademarks in the UK, under № UK00003718474 and № UK00003718468,
respectively.


On Wed, 26 Jul 2023 at 08:56, Rob Stradling <rob=
[e-mail]> wrote:

> > > For reasons I outlined in
> https://mailarchive.ietf.org/arch/msg/acme/aoiW7X3lPYoQ6X8hhRGEvG3HDmo/,
> I have a strong preference for sticking with CertID and an equally strong
> preference against a 'return to the "url in the Order object" '.
> >
> > Returning to that message, the main impression I get is that you want
> ARI to be implementable outside of an ACME server, so you can implement it
> in OCSP responder infrastructure.
>
> Hi Aaron.  Yes, that's my goal.
>
> > This makes sense, but raises two questions in my mind:
> > 1) How do you intend to achieve this goal now that ARI includes POST
> protocols which by definition must be aware of ACME user accounts?
>
> The "renewalInfo" resource in each of our ACME server directory objects
> will point to our ACME server web frontend, which will handle POST requests
> directly (using our ACME server backend, which is part of our CA system)
> but will either proxy or HTTP-redirect GET requests to our OCSP
> infrastructure.  I'm expecting the "heavy-polling nature of ARI" (as you
> phrased it) to only affect GET requests, so I think we should be fine with
> splitting the traffic in this manner.
>
> FWIW, our intent is that our OCSP infrastructure will also respond to ARI
> GET requests for certificates issued via non-ACME mechanisms.  I realise
> this is out of scope for draft-ietf-acme-ari and the ACME WG, but I feel
> that it makes sense to do it.  The GET request part of ARI is not tied to
> the ACME protocol, and the goals expressed in
> https://www.ietf.org/archive/id/draft-ietf-acme-ari-01.html#section-1 are
> not unique to the ACME protocol.
>
> > 2) This desire doesn't seem tied to the CertID structure itself, just to
> the idea of independently-constructable ARI request URLs. Would you be okay
> with a different structure, as long as it is still externally constructable?
>
> Yes, I'm OK with that in principle.
>
> I have a strong preference for basing ARI requests on certificate serial
> numbers rather than thumbprints: selfishly, our OCSP infrastructure is
> already geared up to handle serial number lookups; but also, it's harder
> for a client to mangle a serial number than a thumbprint (e.g., consider
> non-canonical encodings of the copy of the signature parameters that isn't
> covered by a certificate's signature).
>
> To unambiguously identify the issuer, I suppose CABForum BR-compliant CAs
> could maybe live with ARI using the certificate's
> AuthorityKeyIdentifier.keyIdentifier field (as others have proposed already
> on this thread), because the BRs forbid CAs from populating the
> AuthorityKeyIdentifier.{authorityCertIssuer,authorityCertSerialNumber}
> fields.  However, we're defining ARI in the context of IETF, not CABForum;
> and in the IETF context, RFC5280 permits CAs to
> populate AuthorityKeyIdentifier.{authorityCertIssuer,authorityCertSerialNumber}
> instead of AuthorityKeyIdentifier.keyIdentifier.  ACME has already seen
> adoption beyond the initial WebPKI use case, so I think we should expect
> ARI to need to support non-WebPKI use cases too.
>
> Is it required that a CA's Subject DN must be globally unique?  No.
>
> Is it required that a CA's SubjectPublicKeyInfo must be globally unique?
> Again, no.
>
> If two CAs have different Subject DNs but share the same
> SubjectPublicKeyInfo, should we consider them to be the same CA or
> different CAs?
>
> OCSP would answer "different CAs", judging by the definition of the CertID
> structure.  FWIW, crt.sh takes the "different CAs" view too...and BTW this
> isn't just a theoretical question: crt.sh knows of >160
> SubjectPublicKeyInfos that are each associated with >1 Subject DN (see
> [1]).  One example: https://crt.sh/?caid=65461 and
> https://crt.sh/?caid=65479.
>
> Considering all of these edge and corner cases in the context of ARI...I
> can't help but wonder if CertID might actually be the least worst tool for
> the job.
>
> Is it really a problem if the ARI protocol requires the ARI client to
> possess a copy of the issuer certificate?
> Are there realistic scenarios in which an ARI client would not be able to
> locate a copy of the issuer certificate?
>
>
> [1] psql -h crt.sh -p 5432 -U guest -d certwatch -c "select count(*),
> min(name), max(name) from ca group by public_key having count(*) > 1 and
> min(name) != max(name) order by count(*);"
>
> ------------------------------
> *From:* Acme <[e-mail]> on behalf of Aaron Gable <aaron=
> [e-mail]>
> *Sent:* 20 July 2023 16:38
> *To:* Ilari Liusvaara <[e-mail]>
> *Cc:* [e-mail] <[e-mail]>
> *Subject:* Re: [Acme] Practical concerns of draft-ietf-acme-ari
>
>
> CAUTION: This email originated from outside of the organization. Do not
> click links or open attachments unless you recognize the sender and know
> the content is safe.
>
> On Wed, Jul 19, 2023 at 11:16 PM Ilari Liusvaara <[e-mail]>
> wrote:
>
> E.g., the client might be deterministically generating renewal time
> from window (the client I wrote does this). This works nicely if the
> renewal window does not shift around. However, it becomes heavily
> biased toward beginning of the window if the window shifts around.
>
>
> Why? The draft specifically says that clients should be choosing a time
> within the window randomly, not deterministically. What's the motivation
> (and method) for doing a deterministic derivation?
>
>  On Wed, Jul 19, 2023 at 11:16 PM Ilari Liusvaara <
> [e-mail]> wrote:
>
> The single most annoying part of the process is the hash of the issuer
> key. For that, you need the issuer certificate, while everything else
> can be pulled from the subject certificate.
>
>
>  On Thu, Jul 20, 2023 at 3:31 AM Deb Cooley <[e-mail]> wrote:
>
> Issuer key hash:  Is this not in the Authority Key ID extension?  Or is
> this extension not used?
>
> If these things are not the same, my recommendation would be to use
> Authority Key ID value as a way to ID the issuing CA.
>
>
>  On Thu, Jul 20, 2023 at 7:10 AM Ilari Liusvaara <[e-mail]>
> wrote:
>
> AFAICT, no.
>
> RFC5280 merely recommends a construction for AKI, that nevertheless
> happens to match value used by issuer key hash in OCSP.
>
> However:
>
> 1) One can not rely on this, because some CAs do it differently.
>
> 2) The value used in ARI is computed using SHA-256, and does not match
>    the recommended AKI construction.
>
>
> To be clear, the issuer hashes in ARI are *not* computed using SHA-256,
> they're computed using any hash algorithm of the client's choice, just like
> OCSP. This is what I meant when I said that OCSP's "CertID" structure has
> "algorithm agility": it has an algorithm field which must be set to the
> algorithm used to hash the Issuer Name and Issuer Key. Let's Encrypt's ARI
> implementation happens to reject any requests which use an algorithm other
> than SHA-256, but that's not part of the draft.
>
> Producing the IssuerNameHash is easy from just the end-entity certificate,
> since the Issuer Name is of course embedded in it.
>
> Producing the IssuerKeyHash is *almost* easy from just the end-entity
> certificate, but in fact impossible to guarantee correct. For example, if a
> CA follow's RFC 5280 Section 4.2.1.2 to construct their Subordinate CA
> Certificates' Subject Key Identifier (specifically "The keyIdentifier is
> composed of the 160-bit SHA-1 hash of the value of the BIT STRING
> subjectPublicKey (excluding the tag, length, and number of unused bits)"),
> then the end-entity cert's IssuerKeyID is exactly the needed IssuerKeyHash
> with a hash algorithm of SHA-1. Similarly, all of Let's
> Encrypt's Subordinate CA Certs use the exact same method (
> https://github.com/letsencrypt/boulder/blob/908421bb98c11c8ffce640029b6357446c528cfb/cmd/ceremony/cert.go#L199-L209)
> except with SHA-256 instead of SHA-1. So it is *technically* possible for
> clients to simply extract the AuthorityKeyId, transfer it to the CertID,
> and submit it to Let's Encrypt's ARI endpoint.
>
> However, there's no way to guarantee that. The AuthorityKeyID field gives
> no indication of how it was produced, and there's no way to guarantee that
> a CA will continue to use the same method over time. So to guarantee
> correctness, a client can't rely on the AKID and has to use the Issuer cert
> to re-derive the Issuer Key Hash.
>
> This is very unfortunate, and is the primary reason that I'm seriously
> considering changing the request format. It would be truly nice for the
> request to be constructable using *only* the end-entity cert.
>
> Maybe it would be best to state "Hey, the CA generated its own Issuer Key
> IDs, it can be expected to recognize them too", and make the request simply
> IssuerKeyID + Serial, in some simple concatenate+base64url format.
>
> On Thu, Jul 20, 2023 at 4:14 AM Rob Stradling <rob=
> [e-mail]> wrote:
>
> For reasons I outlined in
> https://mailarchive.ietf.org/arch/msg/acme/aoiW7X3lPYoQ6X8hhRGEvG3HDmo/,
> I have a strong preference for sticking with CertID and an equally strong
> preference against a 'return to the "url in the Order object" '.
>
>
> Returning to that message, the main impression I get is that you want ARI
> to be implementable outside of an ACME server, so you can implement it in
> OCSP responder infrastructure. This makes sense, but raises two questions
> in my mind:
> 1) How do you intend to achieve this goal now that ARI includes POST
> protocols which by definition must be aware of ACME user accounts?
> 2) This desire doesn't seem tied to the CertID structure itself, just to
> the idea of independently-constructable ARI request URLs. Would you be okay
> with a different structure, as long as it is still externally constructable?
>
> Thanks,
> Aaron
> _______________________________________________
> Acme mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/acme
>