> On Apr 19, 2017, at 9:44 PM, Logan Widick <[email protected]> wrote: > > > > On Apr 3, 2017 16:07, "Sean Leonard" <[email protected] > <mailto:dev%[email protected]>> wrote: > On 4/3/2017 5:54 AM, Logan Widick wrote: >> I think that having separate URIs to reduce bloat is a good idea. I >> understand that the client needs to send the CSR as a field in the new-order >> request payload for security. However, in the server response, could the CSR >> be a URI that would allow the client to retrieve the CSR that the client >> submitted in DER format? So, could new-order requests look like: >> >> { >> csr: "base64url(derEncodedCSR)" >> //rest of fields in new-order here >> } >> >> And the server's order response look like: >> { >> csrLink: "[link to DER encoded CSR]" >> certificate: "[link to DER encoded certificate]" >> chains: [array of links to chains as suggested by Niklas] >> //rest of fields in order response here (except for "csr") >> } > > The wrinkle with this proposal is that CSRs are likely non-public data. They > could contain personally identifiable information in the metadata, or other > random stuff. It is undesirable to have a link that has to be maintained for > the lifetime of the order history, which could be harvested by search engines > or otherwise made public. Typically CAs harvest the public key and discard > the rest (after verifying the authenticity of the CSR). Therefore, I am not > in favor of URIs for CSR data. > > Since CAs would harvest data from CSRs and then discard the rest after > authenticity checks, and the identifiers would appear elsewhere (in the > authorizations), could the "csr" field apply to the new-order request and be > absent from the order object?
They “could” be. But, I think the point of keeping the CSR around is partially for reference purposes. I am aware of web servers that keep the CSR around for users (customers) to stash. > > > The case for URIs for issued end-entity certificates is half-half. > Certificates are public documents, but it's an extra round-trip and you have > to save the same amount of state on the client side (i.e., the certificate > URI). > > The case for URI(s) for CA certificates in the validation chain is strongest, > since they are unlikely to change and are reused across many customers. > Basically "de-duplication". On the other hand, there are business/usability > advantages to packaging up "everything you need to run your web server" in > one neat package. > > When certificates are embedded in order objects, won't the order objects get > quite large? They will get larger, but it’s not clear that the size is really going to be an issue. The client has to download the certificates anyway eventually. It is (arguably) more bookkeeping to store them separately, e.g., via separate URIs. >> >> For consistency, I think the chain links (when retrieved) should be >> concatenated DER. > > I am in favor of DER. :) (But less sure about whether links are desirable in > the first place.) > > I could have sworn that when certificate retrieval is done over the wire, CMS > (PKCS #7) is an IETF standardized type for blobs of certificates. Oh yeah, > here it is: > RFC 5280 Section 4.2.2.1 (it's repeated elsewhere): > HTTP server implementations accessed via the URI SHOULD specify the > media type application/pkix-cert [RFC2585 > <https://tools.ietf.org/html/rfc2585>] in the content-type header > field of the response for a single DER encoded certificate and SHOULD > specify the media type application/pkcs7-mime [RFC2797 > <https://tools.ietf.org/html/rfc2797>] in the > content-type header field of the response for "certs-only" CMS > messages. For FTP, the name of a file that contains a single DER > encoded certificate SHOULD have a suffix of ".cer" [RFC2585 > <https://tools.ietf.org/html/rfc2585>] and the > name of a file that contains a "certs-only" CMS message SHOULD have a > suffix of ".p7c" [RFC2797 <https://tools.ietf.org/html/rfc2797>]. > Consuming clients may use the media type > or file extension as a hint to the content, but should not depend > solely on the presence of the correct media type or file extension in > the server response. > > > Just sayin'... ;-) > > It is worth pointing out that PKCS #7 / CMS "certs-only", amounts to > concatenated DER certificates plus a little bit of goo at the beginning and > end (which can be ignored/skipped). Here is a dump of a .p7s file I have > lying around using asn1js: > > SEQUENCE(2 elem) > OBJECT IDENTIFIER1.2.840.113549.1.7.2 > [0](1 elem) > SEQUENCE(5 elem) > INTEGER1 > SET(0 elem) > SEQUENCE(1 elem) > OBJECT IDENTIFIER1.2.840.113549.1.7.1 > [0](3 elem) > SEQUENCE(3 elem) > SEQUENCE(3 elem) > SEQUENCE(3 elem) > SET(0 elem) > > In this case, the SEQ -> [0] -> SEQ -> [0] has three certificates, which > start with SEQUENCE. Rip and go. > > Finally, here is how you convert from p7s to textual certificates: > openssl pkcs7 -inform DER -in yourfile.p7s -print_certs > > The advantage of the command-line/OpenSSL recipe above, is that you are > guaranteed that the output will only be -----BEGIN CERTIFICATE----- things. > Non-certificates shall not pass. > > That already standardized type would be better. Great. My point here is to keep with what already exists. Regards, Sean
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
