Forgot to add the mailing list like I was going to.
From: Jim Schaad <[email protected]> Sent: Friday, August 16, 2019 2:55 PM To: 'Sean Leonard' <[email protected]>; [email protected] Subject: RE: draft-ietf-cose-x509 typos and technical points From: Sean Leonard <[email protected] <mailto:[email protected]> > Sent: Saturday, August 10, 2019 12:28 PM To: [email protected] <mailto:[email protected]> Subject: draft-ietf-cose-x509 typos and technical points Hello: I found the following typos in draft-ietf-cose-x509: * If multiple certificates are conveyed, a CBOR array of bstrs is used. Each certificate being in it's own slot. Should be: * If multiple certificates are conveyed, a CBOR array of bstrs is used, with each certificate being in its own bstr. [JLS] FIxed The x5u header attribute description discusses “URL” but the IETF parlance is “URI”. Please sub “URI” instead of URL as appropriate. [JLS] I am still a bit old fashion on this. In part because the use of IRI is so fraught. Done. application/pem-certificate-chain is not an appropriate media type to use for PKIX certificates. If it is in PKIX textual format (RFC 7468), text/plain needs to be acceptable. You are asking a parser to parse through plain text. [JLS] I was never really sold on doing this, the question is how often would it ever be done in real life today. For now I am just going to delete this unless people say that this is frequently used. I would like to see identification by IssuerAndSerialNumber. The reason is because many certificate databases index certificates by Issuer + Serial Number, so this lookup will be fast. The serial number is just a bstr. The issuer is just the DER blob of the issuer field (therefore, a bstr). It could be a tstr as well with the textual representation of the issuer field, but I do not know if we want to go there and introduce LDAP string parsing. [JLS] I am very loathe to include issuer/serial number as an option. While I understand that many databases are indexed by this pair of values, I think that just as many of them are also indexed by one or more instances of a hash function. My problem with using this is that it is known not to be a unique identifier of a certificate for any number of reasons. The same problem exists if one uses the SKI extension to identify a certificate, there may be multiple certificates with the same value. (Indeed I routinely make this value a fixed constant for a number of certificates just to make people angry.) When this was realized for S/MIME, it was a high priority to add the hash of the certificate to the signed attributes so that this would be fixed. I am less worried at the moment about dealing with cross certificates as I don’t believe that this will be an IoT problem, so I did not do an attribute with a chain of hashes corresponding to the certification chain. Jim Thanks, Sean
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
