> > 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 <[email protected]> on behalf of Aaron Gable <[email protected]> Sent: 20 July 2023 16:38 To: Ilari Liusvaara <[email protected]> Cc: [email protected] <[email protected]> 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 <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> 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 [email protected] https://www.ietf.org/mailman/listinfo/acme
