> -----Original Message----- > From: DESPERRIER Jean-Marc <[email protected]> > Sent: Tuesday, January 22, 2019 3:09 AM > To: Jim Schaad <[email protected]>; 'cose' <[email protected]> > Subject: RE: Early Assignment of values > > Hi, > > I didn't clarify it in the first message but the use in ISO-18013-5 in the > context > of mobile driving license, ie making the information of a driving license > accessible and secure on a hardware that is assumed to be a mobile phone or > something equivalent. > The current version of the spec has been rewritten to use cbor, and I just > sent an expert comment to try to replace the use of CMS that's remaining > with COSE. > It's just an expert comment for now, but I know there's good support to > adopt it, in discussion previously CMS stayed there just because we didn't > knew of a ready option to replace it. > We will keep using the hierarchical model of X509 for trust however. > > So in this context the demands for the cose x509 draft are quite light, we'll > just need the x5chain header to be able to reference a x509 certificate for > the signature. > As we have a offline use case and the signature will need to be self- > supporting, we won't have a use for the x5u and x5t headers. > As it is, I see no problem with the spec in cose x509 draft, everything can be > readily used, and the best would be if it can be accepted and published > quickly to be able to reference a stable document.
That is always good to hear. > > There would actually be more remarks about the cose spec itself. Currently > with the CMS format, we had defined a possibility to use RSA signature. > I think this is mostly for legacy reasons, but it would probably make adoption > easier if there was still a way to use RSA. I see the COSE Algorithms for Web > Authentication (WebAuthn) draft had started to define identifiers for it, but > it's expired now. That is a milestone for the working group. I assume that at some point either an updated document will be published by the current authors or a new set of authors might be assigned to it. > > The other remark is the fact that only the secp***r1 curves can be used for > ECDSA signature, which is a big constraint for algorithm agility. > I would support having an optional signed header to specify an alternative EC > curve to use in replacement of the defaut secp one. > Or if this doesn't work, have additional signature scheme for using a > different > curve family. It should be possible for somebody to write a new document which would create the curve assignments for other curves to be created. It would need to make it clear what the algorithms it can be used with are but, other than the potential buy off on the curves from CFRG, this would be a trivial task. Jim > > Br, > Jean-Marc > > > -----Message d'origine----- > De : Jim Schaad <[email protected]> > Envoyé : lundi 21 janvier 2019 06:20 > À : DESPERRIER Jean-Marc <[email protected]>; 'cose' > <[email protected]> > Objet : Early Assignment of values > > The document itself needs to be relatively stable before the values > themselves can be assigned as provisional items. Providing a review of the > document is a good step towards that aim. What are the items that you have > a need for and are they being met by the document? Is the document clear > about what is being proposed? > > Jim _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
