Hi,
I've done my AD review of draft-ietf-cose-cbor-encoded-cert-15
I have a few comments and questions, but I think the most important item is
whether we asked the TLS WG what they think about making the C509 TLS
Certificate Types RECOMMENDED Y to implement. It seems quite a lift to
require all TLS servers would implement C509 at this point in time? The
field is documented to mean:
If the "Recommended" column is set to "N", it does not necessarily
mean that it is flawed; rather, it indicates that the item either
has not been through the IETF consensus process, has limited
applicability, or is intended only for specific use cases.
Which I would argue matches better with RECOMMENDED N
See the rest of my AD review below,
Paul
The Abstract is large and the Introduction repeats many things. Can we
deduplicate this and make the Abstract smaller and more consise?
Please add a sentence: This document updates RFC 6698 in the Abstract.
validityNotAfter: ~time / null,
Why can this be null? I thought X.509 certs always have an end date?
(reading further, this is explained in 3.1.5)
the octets 0xfe and 0xfd are used instead of 0x02 and 0x03
in the CBOR encoding to represent even and odd y-coordinate,
respectively.
I would prefer to rewrite this without using the "respectively" construct
to help non-native english speakers.
This does not parse:
using of the reserved CBOR tag
I assume "of" just needs to be removed?
An implementation MAY only support c509CertificateRequestType = 0.
This is an odd way of saying, I think, that c509CertificateRequestType = 0
is mandatory to implement.
There seems to be a spelling error in: TBSCertificatdsveRequest
Should this be: TBSCertificateRequest ?
For example, if the EST server includes a subjectAltName with
a partially filled extensionValue, such as iPAddress with an
empty byte string, this means that the client SHOULD fill in
the corresponding GeneralName value
This makes it appeat the EST server can put in "10.0.2" and the client can
only
pick that range, or "example.com" and the client can pick only subdomains
from
"example.com", but it is unlikely that you meant this? Perhaps rephrasing
this
to avoid this interpretation?
"Brotli [RFC7932]" is not clarified until after "Brotli" has been mentioned
a few times already.
Please move the "[RFC7932]" clarification to the first instance of the use
of "Brotli".
This sentence is unreadable, please rewrite:
Any issue to decode or parse a C509 certificate should be handled
by the certificate using system as would the issue of parsing
the corresponding X.509 certificate.
Perhaps:
Any problems with decoding or parsing a C509 certificate should be
handled
exactly as how such errors would be handled for the corresponding
X.509 certificate.
Section 9.5, should the text "Name and Identifiers are informal
descriptions" maybe be included
as a note above the table?
Why is Postal Code defined, but not Postal Address? Is that because Street
Address is used?
Section 9.10. C509 Extended Key Usages Registry
A good list of EKUs is:
https://docs.digicert.com/zf/trust-lifecycle-manager/define-policies-to-ensure-compliance/certificate-attributes-and-extensions/extended-key-usage.html
I happen to know (as an IPsec/IKE expert) that some implementations (like
Microsoft) requires
EKUs for IPsec which are not defined here.
I guess these can be added later.
Section 9.17. TLS Certificate Types Registry
This sets the new type to RECOMMENDED. Since this is (currently) very much
an IoT related document, I am not
sure if it qualifies as something to be set to RECOMMENDED Y, meaning all
servers/clients MUST/SHOULD implement
this. Has there been a conversation with the TLS WG or the Designated
Experts for this Registry?
_______________________________________________
COSE mailing list -- [email protected]
To unsubscribe send an email to [email protected]
