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.
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. I think that CA
operators/implementers would have the most authority to weigh in on what
works best.
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.
Sean
Sincerely,
Logan Widick
On Apr 3, 2017 06:29, "Niklas Keller" <[email protected]
<mailto:[email protected]>> wrote:
One potential issue I can see with embedding certificates with the
currently proposed format directly into orders are alternative
chains. Chains usually do not change between orders, so they could
be kept with separate URIs for cachability and less bloat in the
order response.
e.g.
"certificate": base64url(derEncodedCertificate),
"chains": [
"https://.../chain";,
"https://.../alternate-chain";
]
Regards, Niklas
_______________________________________________
Acme mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/acme
<https://www.ietf.org/mailman/listinfo/acme>
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
