Peter has sent me some constrained voucher requests to process.

1) he used secp256k1 rather than secp256r1 (aka prime256r1).
   {I'm terrible at remembering which is which)

   secp256r1 is, I think, the one more commonly implemented in hardware, and
   which is used extensively in the webpki as the replacement for RSA.

   secp256k1 is used in Bitcoin.

   Our document says that both are MUST.
   I wonder if we shouldn't pick one ECDSA curve, and if we want a backup
   algorithm (we so), that we pick EDDSA/25519.

2) The kid contains what I think is the hash of public key, as clearly
   indicated in section 8.3, where the example says:

      h'A101382E',        # { "alg": EC256K1 }
       {
         "kid" : h'7890....1234'  # hash256(public key)
       },

(no wonder Peter used EC256K1!)

The problem that I have is that I don't have the public key for his Registrar.
It wasn't included in an x5bag, nor as a TLS Client Side Certificate, so I
can't validate anything.  I'd have to have registered the Registrar a priori.

Pre-registration is a supported mechanism.  For this case, where everything
is that way, I return a 406.    I wonder if 401 or 403 might be better in
this case.... or do we perhaps need new returns.

I prefer to always be able to support TOFU MASA, even if that policy is
turned off, so I think that Registrars need to always provide their signing
key in x5bag.
If doing x5bag, it seems wasteful to then include kid.

https://github.com/anima-wg/constrained-voucher/issues/128


3) In our SID assignment diagram, in 8.1.2,  We have some sorting that
   relates to voucher and then voucher-request.
   The dump in -12 is just screwed up, and I appologize for that.
   I'm not sure what happened that resulted in the duplication.
   The sorting is by SID value.   Should we invert and present this more as a 
table?
   I'm trying to make sure that it's driven by pyang.


4) I have removed the comment in section 8 relating to http://comi.space.

--
Michael Richardson <[email protected]>, Sandelman Software Works
 -= IPv6 IoT consulting =-



Attachment: signature.asc
Description: PGP signature

_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima

Reply via email to