SanKumar2015 / EST-coaps

EST over CoAPs IETF draft
1 stars 1 forks source link

Clarify that content format 281 is a container of certificate(s) (Esko WGLC) #111

Closed EskoDijk closed 5 years ago

EskoDijk commented 5 years ago

Section 5.2.1 mentions "a certificate with content format ID 281 (0x0119)" -> this should be clarified, to mention it is a PKCS7 container that contains exactly one certificate. Otherwise it can be confused with the X.509v3 DER certificate format of issue #102 which is the encoded certificate (without a container wrapping around it).

(Perhaps check other occurrences of 281 also if this is described consistently.)

EskoDijk commented 5 years ago

Section 5.2.1 also mentions "The PKCS#8 key and X.509 certificate representations are ASN.1 encoded in binary DER format.". This strongly suggests a DER encoded X.509 certificate format, which is not the case here - it is DER encoded PKCS7 with a X.509 certificate inside. Good to clarify that the certificate here is the PKCS7 container.

petervanderstok commented 5 years ago

Changed to:

The PKCS#8 key and PKCS#7 X.509 certificate representations are ASN.1 encoded in binary DER format.

Peter Esko Dijk schreef op 2019-01-30 11:16:

Section 5.2.1 also mentions "The PKCS#8 key and X.509 certificate representations are ASN.1 encoded in binary DER format.". This strongly suggests a DER encoded X.509 certificate format, which is not the case here - it is DER encoded PKCS7 with a X.509 certificate inside. Good to clarify that the certificate here is the PKCS7 container.

-- You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub [1], or mute the thread [2].

Links:

[1] https://github.com/SanKumar2015/EST-coaps/issues/111#issuecomment-458889031 [2] https://github.com/notifications/unsubscribe-auth/AMWTQTPPx5VqebAEkYJ9M14NoHG5BShrks5vIXEAgaJpZM4aZ3ew

petervanderstok commented 5 years ago

changed to:

could include a private key in PKCS#8 with content format ID 284 (0x011C) and a single certificate in PKCS#7 with content format ID 281 (0x0119)

Peter Esko Dijk schreef op 2019-01-30 11:11:

Section 5.2.1 mentions "a certificate with content format ID 281 (0x0119)" -> this should be clarified, to mention it is a PKCS7 container that contains exactly one certificate. Otherwise it can be confused with the X.509v3 DER certificate format of issue #102 [1] which is the encoded certificate (without a container wrapping around it).

(Perhaps check other occurrences of 281 also if this is described consistently.)

-- You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub [2], or mute the thread [3].

Links:

[1] https://github.com/SanKumar2015/EST-coaps/issues/102 [2] https://github.com/SanKumar2015/EST-coaps/issues/111 [3] https://github.com/notifications/unsubscribe-auth/AMWTQQTRsQo9RQIgi7pyk8jFPe1trBczks5vIW-3gaJpZM4aZ3ew

csosto-pk commented 5 years ago

How about PKCS8 (284) with application/pkix-cert. (TBD287)? How about 280 with application/pkix-cert. (TBD287) or 281? Need to add one more sentence

The certificate could alternatively be include with content format ID TBD287 when it is formatted as application/pkix-cert.

petervanderstok commented 5 years ago

not clear to me what you want to add

csosto-pk commented 5 years ago

Rephrased to

For example, a collection containing two representations in response to a server-side key generation request, could include a private key in PKCS#8 [RFC5958] with Content_Format ID 284 (0x011C) and a single certificate in a PKCS#7 container with Content_Format ID 281 (0x0119). Such a collection would look like [284,h'0123456789abcdef', 281,h'fedcba9876543210'] in diagnostic CBOR notation. The serialization of such CBOR content would be ... When the returned certificate is a single X.509 certificate (not a PKCS#7 container) the Content_Format ID is TBD287 (0x011F). In cases where the private key is encrypted with CMS (as explained in Section 5.7) the Content_Format ID is 280 (0x0118). The key and certificate representations are ASN.1 encoded in binary format. An example is shown in Appendix A.4.