-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Deterministic Encoding of an Extension #197
Comments
Based on joint discussions, we are leaning towards Metod 2, but we will reach out and ask the COSE list for comments! |
Have mailed the COSE list with the following content: Regarding the ongoing work with draft-ietf-cose-cbor-encoded-cert, we hope to get your opinions on some alternatives regarding non-determinism and compactness. *Previously we have allowed the registration of certificate extensions in our c509 extension table(^1), without requiring a full accomplishing specification of the cbor encoding of the extension value. Instead allowing the value to be a cbor byte string wrapping of the der-encoded value. This is a clear source of non-determinism, as the expectation is that later additions to the draft will further specify a cbor encoding of the value. The result would be that the receiver of a certificate cannot know beforehand if an extension value is cbor fully encoded or just a der endoced value with byte string wrapping. *We think it would be a useful restriction to only keep extensions with defined cbor encodings of the value, and add this as a requirement for new entries into the table of supported extensions. Does this seem like reasonable restrictions and limitations? Comments and opinions here or directly to our github issue tracker(^2) are most welcome. In addition, there has been an ongoing discussion on adding options for using PENs instead of OID. Since the the cbor encoding of the PENs would need a tag, the savings compared with unwrapped OIDs are only two bytes per PEN. At the same time, support for PEN adds complexity both in the specification and in implementations. To not increase the non-determinism, any OID which can be PEN encoded must be PEN encoded, requiring strict checking. This makes us question whether the savings are worth the drawbacks, and we are interested in hearing any supporting voices from either side of the issue.
|
Having not received any comments, we make the same change for extension as for attributes #198. Pending input from John, we are in favor of requiring CBOR encoded extensions for native C509 certificates. |
Summarizing my current understanding: Where there is support for (extensionID:int, extensionValue:any) of an extension, as specified in Section 3.3 it MUST be used. Otherwise the extension is encoded as (extensionID:~oid, extensionValue:bstr) where extensionValue is the DER-encoded extension value. Native C509 certificates MUST only use CBOR encoded extensions, and this aspect of the encoding becomes deterministic. Indeterminism of non-native C509 certificates is a consequence of the extensibility of the C509 Extensions Registry. When decoding a non-native C509 certificates, the decoder needs to support an (extensionID:~oid, extensionValue:bstr)-encoding of an extension for which there is an (extensionID:int, extensionValue:any)-encoding , for example because the certificate was issued before the extension was registered. |
To encode an extension of an X.509 certificate deterministically, I suggestion to follow one of the following methods to produce a distinct encoded C.509 certificate (of type 3).
Method 1
int
assignment,bstr
choice, then the extension is encoded as (extensionID:int, extensionValue:bstr) where extensionValue is the DER-encoded extension value. (This applies to all extensions exceptsubjectKeyIdentifier
andauthorityKeyIdentifier
).subjectKeyIdentifier
andauthorityKeyIdentifier
).Method 2
The same as Method 1, except there are no case i.b.
Method 1 needs less storage capability, but Method 2 is simpler to implement.
The text was updated successfully, but these errors were encountered: