search

lamps-wg / cmp-updates

RFC4210bis and RFC6712bis
Other
2 stars 5 forks source link

Introduction of KemBMParameter #26

Closed HBrock closed 8 months ago

HBrock commented 1 year ago

Meeting 11.5.23 It was decided to introduce an new AlgID for KEM based message protection ` id-KemBasedMac OBJECT IDENTIFIER ::= {1 2 840 113533 7 66 TBD4}

KemBMParameter ::= SEQUENCE { kdf AlgorithmIdentifier{KEY-DERIVATION, {...}}, len INTEGER (1..MAX), mac AlgorithmIdentifier{MAC-ALGORITHM, {...}} }`

HBrock commented 1 year ago

There is id-PasswordBasedMac OBJECT IDENTIFIER ::= { 1 2 840 113533 7 66 13 } and id-DHBasedMac OBJECT IDENTIFIER ::= {1 2 840 113533 7 66 30}, see: http://oid-info.com/get/1.2.840.113533.7.66

@johngray-dev @ounsworth As both OIDs are registered in the Entrust OID tree, is it possible that Entrust will could also register id-KemBasedMac OBJECT IDENTIFIER ::= {1 2 840 113533 7 66 TBD4}?

HBrock commented 1 year ago

done

HBrock commented 1 year ago

There is id-PasswordBasedMac OBJECT IDENTIFIER ::= { 1 2 840 113533 7 66 13 } and id-DHBasedMac OBJECT IDENTIFIER ::= {1 2 840 113533 7 66 30}, see: http://oid-info.com/get/1.2.840.113533.7.66

@johngray-dev @ounsworth As both OIDs are registered in the Entrust OID tree, is it possible that Entrust will could also register id-KemBasedMac OBJECT IDENTIFIER ::= {1 2 840 113533 7 66 TBD4}?

ounsworth commented 1 year ago 
1.2.840.113533.7.66.16  kemBasedMac

I guess the others, like id-passwordBasedMac are Entrust OIDs; they were never registered under the IANA PKIX arc, so I guess it makes sense for this one also (ie this is not a prototyping OID, but actually the final OID). Good.

johngray-dev commented 1 year ago

Looks good. I am not sure if we have to officially register it anywhere, but it has been registered in the same place internally. I guess if IETF accepts it, that makes it official. Perhaps I will go over to the IANA people at 117 and ask them about it just to be clear.... :)

HBrock commented 1 year ago

Meeting 15.6.23 We keep this issue until we have feedback from Russ on our proposal using the Entrust OID.

ounsworth commented 1 year ago

2023-06-16:

John: The problem with placeholder OIDs is that some implementions never move to the "production" OID. If Entrust wants to assign permanent ones, I have no objection. Russ

I think we can go ahead and use the OID mentioned above:

1.2.840.113533.7.66.16  kemBasedMac
johngray-dev commented 1 year ago

Yes, Agreed. I is in an Arc that we own, and we have reserved space of it. So sure, we can make it permanent.