You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The design pattern is short-sighted and error prone:
extending this pattern to other types of PKI would suggest additional key types are specified through boolean flags -- e.g. isVidSigner
specifying additional flags gets very problematic in cases where exactly one of the flags must be true.
consumers of the API are lulled into a false sense of security w.r.t. default cases -- even in the current design, the client deduces that the certificate comes from the DA PKI by checking isNoc == false. This scheme is destined to break backward compatibility if we introduce any additional certificate chain.
Proposed solution
Introduce enumeration CertificateType. On day 0, that enumeration would have three values:
Problem
Version 1.4 of the DCL introduced extensions to certificate.proto :
The design pattern is short-sighted and error prone:
isVidSigner
isNoc == false
. This scheme is destined to break backward compatibility if we introduce any additional certificate chain.Proposed solution
CertificateType
. On day 0, that enumeration would have three values:isNoc
tocertificateType
:This remains wire compatible with the previous
isNoc
because both bool and enums are encoded as varints.The text was updated successfully, but these errors were encountered: