Feature #3058
closed
AdditionalDescription in SignatureInfo
Description
As we defined in new certificate format #2861, there will be an non-critical extension AdditionalDescription. As defined in the certificate spec:
AdditionalDescription is a non-critical extension that provides additional
information about the certificate. The information is expressed as a set of
key-value pairs. Both key and value are UTF-8 strings, e.g.,
("Organization", "UCLA"). The issuer of a certificate can specify arbitrary
key-value pair to provide additional description about the certificate.
AdditionalDescription ::= ADDITIONAL-DESCRIPTION-TYPE TLV-LENGTH
DescriptionEntry+
DescriptionEntry ::= DESCRIPTION-ENTRY-TYPE TLV-LENGTH
DescriptionKey
DescriptionValue
DescriptionKey ::= DESCRIPTION-KEY-TYPE TLV-LENGTH
BYTE+
DescriptionValue ::= DESCRIPTION-VALUE-TYPE TLV-LENGTH
BYTE+
| TLV-TYPE | Assigned code (decimal) | Assigned code (hexadecimal) |
|---|---|---|
| AdditionalDescription | 258 | 0x0102 |
| DescriptionEntry | 512 | 0x0200 |
| DescriptionKey | 513 | 0x0201 |
| DescriptionValue | 514 | 0x0202 |
Updated by Junxiao Shi almost 9 years ago
- Tracker changed from Task to Feature
- Subject changed from Add AdditionalDescription into SignatureInfo to AdditionalDescription in SignatureInfo
- Description updated (diff)
I'm having doubt on why this is defined as key-value pairs instead of TLV, and I found the answer:
This design is inconsistent with other TLVs because so far we always TLV type for the notion of map key(DescriptionKey).
The value of key is arbitrary, if you use TLV-TYPE, you require people to predefine all the keys...
Are there many keys? Probably just over a dozen at most from x509 certificate. The main concern is that this is the first time we introduce the map (key value pair) concept in this style to tlv.
it is not "a dozen" from x509, there are a lot, and it is not necessary to do that.
Another thing to consider is whether all the description keys in x509 are useful in NDN. In addition, TLV prevents variations like "Organization", "organization", "Organizations", "organizations".
This seems reasonable.
Updated by Junxiao Shi almost 9 years ago
As I understand, this issue shall develop the programmable API for this element.
Some questions:
- What to do if a key or value is not representable in UTF-8 (eg.
std::string("\xFD"))? It would result in invalid DescriptionKey and DescriptionValue elements because they are defined to be UTF-8. - Are the keys case-insensitive? Should the API support normalizing the keys (as mentioned on the last line of the conversation quoted in note-3)?
- Is the order among key-value pairs significant?
This will affect the semantics of
operator==. - Is the same key repeatable?
- If a key is repeatable, is the order among multiple values of the same key significant?
- Should the API support validating the syntax of a value?
eg. Syntax of email address must conform to RFC822. Suppose a key "Email" is to be associated with an email address. Should the API allow attaching a validation callback, so that an invalid email address cannot be associated with the key "Email"? - Is an iterator for all key-value pairs useful to applications, or are getters/setters sufficient?
There's no right or wrong answer to those questions. But I want to see the rationale of each answer, and the design should be consistent with those answers.
Updated by Yingdi Yu almost 9 years ago
Junxiao Shi wrote:
As I understand, this issue shall develop the programmable API for this element.
Some questions:
- What to do if a key or value is not representable in UTF-8 (eg.
std::string("\xFD"))? It would result in invalid DescriptionKey and DescriptionValue elements because they are defined to be UTF-8.
Actually, I do not think we should care about UTF-8 case for now, because we haven't get into the multi-language scenario yet. For now, we just assume that all keys and values are ascii characters (single byte case of UTF-8) and treat them as string. When we "really" need to support multi-language case, we can go back to solve the problem.
For current implementation, I will use std::string as internal expression for key, and buffer for value.
- Are the keys case-insensitive? Should the API support normalizing the keys (as mentioned on the last line of the conversation quoted in note-3)?
I prefer to keep them case sensitive, and leave the case normalization to applications (if they really care).
- Is the order among key-value pairs significant? This will affect the semantics of
operator==.
I think order matters in encoding as well, so let's encode them in the lexicographical order.
- Is the same key repeatable?
- If a key is repeatable, is the order among multiple values of the same key significant?
key is unique. Application should encode multiple values of the same key into a single DescriptionValue.
- Should the API support validating the syntax of a value?
eg. Syntax of email address must conform to RFC822. Suppose a key "Email" is to be associated with an email address. Should the API allow attaching a validation callback, so that an invalid email address cannot be associated with the key "Email"?
No. it is up to application, API treat value as opaque data. syntax checking should be done by application.
- Is an iterator for all key-value pairs useful to applications, or are getters/setters sufficient?
The API in my mind is that application will still provide iterator, and also provide get/set-by-key method (for now, key is std::string).
Updated by Yingdi Yu almost 9 years ago
- Status changed from New to Code review
- Assignee set to Yingdi Yu
- % Done changed from 0 to 80
Updated by Alex Afanasyev almost 9 years ago
Yingdi Yu wrote:
Junxiao Shi wrote:
As I understand, this issue shall develop the programmable API for this element.
Some questions:
- What to do if a key or value is not representable in UTF-8 (eg.
std::string("\xFD"))? It would result in invalid DescriptionKey and DescriptionValue elements because they are defined to be UTF-8.Actually, I do not think we should care about UTF-8 case for now, because we haven't get into the multi-language scenario yet. For now, we just assume that all keys and values are ascii characters (single byte case of UTF-8) and treat them as string. When we "really" need to support multi-language case, we can go back to solve the problem.
For current implementation, I will use std::string as internal expression for key, and buffer for value.
My comment should not affect thr implementation, but we have alreadey met the problem of internationalization exactly with additional information put in certificates. We have many participants outside US who are using at least some non-ascii characters. With std::string as internal storage, UTF strings should not have any problems with being stored/managed.
Updated by Junxiao Shi almost 9 years ago
- Related to Task #2122: Replace DER encoded certificate using NDN's own TLV encoding added
Updated by Yingdi Yu over 8 years ago
- Status changed from Code review to Closed
- % Done changed from 80 to 100