> 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.
The Authority Key Identifier only identifies the authority's key. Please see my earlier message [1] for some thoughts and questions regarding whether or not that's sufficient to identify the issuer. My view is that it's insufficient, and that an issuer can only be uniquely identified by its Key and Name. If you accept my view then... I suppose we could define a structure that contains all of the following elements: * the full AKI * the full Issuer DN * the certificate serial number To keep ARI requests small, we'd probably want to send hashes of those elements rather than the elements themselves. And it would make sense to build in hash algorithm agility. And...we've essentially just reinvented CertID, except we've swapped the hash of the issuer's public key for a hash of the AKI extension. Is needing / not needing a copy of the issuer certificate really such a big deal that we need to reinvent the (CertID) wheel? [1] https://mailarchive.ietf.org/arch/msg/acme/QHNxo0L89XS6Y9VNF1oD6X907UY/ ________________________________ From: Q Misell <q=40as207960....@dmarc.ietf.org> Sent: 26 July 2023 17:52 To: Rob Stradling <r...@sectigo.com> Cc: Aaron Gable <aa...@letsencrypt.org>; Ilari Liusvaara <ilariliusva...@welho.com>; acme@ietf.org <acme@ietf.org> 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. > 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=40sectigo....@dmarc.ietf.org<mailto:40sectigo....@dmarc.ietf.org>> 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 <acme-boun...@ietf.org<mailto:acme-boun...@ietf.org>> on behalf of Aaron Gable <aaron=40letsencrypt....@dmarc.ietf.org<mailto:40letsencrypt....@dmarc.ietf.org>> Sent: 20 July 2023 16:38 To: Ilari Liusvaara <ilariliusva...@welho.com<mailto:ilariliusva...@welho.com>> Cc: acme@ietf.org<mailto:acme@ietf.org> <acme@ietf.org<mailto:acme@ietf.org>> 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 <ilariliusva...@welho.com<mailto:ilariliusva...@welho.com>> 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 <ilariliusva...@welho.com<mailto:ilariliusva...@welho.com>> 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 <debcool...@gmail.com<mailto:debcool...@gmail.com>> 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 <ilariliusva...@welho.com<mailto:ilariliusva...@welho.com>> 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=40sectigo....@dmarc.ietf.org<mailto:40sectigo....@dmarc.ietf.org>> 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 Acme@ietf.org<mailto:Acme@ietf.org> https://www.ietf.org/mailman/listinfo/acme
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
