Feature #3058: AdditionalDescription in SignatureInfo - ndn-cxx - NDN project issue tracking system

Feature #3058

closed

AdditionalDescription in SignatureInfo

Added by Yingdi Yu almost 9 years ago. Updated over 8 years ago.

Status:

Closed

Priority:

Normal

Assignee:

Yingdi Yu

Category:

Security

Target version:

v0.4

Start date:

07/17/2015

Due date:

% Done:

100%

Estimated time:

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

Related issues 1 (0 open — 1 closed)

Related to ndn-cxx - Task #2122: Replace DER encoded certificate using NDN's own TLV encoding

Closed

11/03/2014

Actions

Issue # Delay: days Cancel

History
Notes
Property changes

Actions

Copy link

Updated by Yingdi Yu almost 9 years ago

Description updated (diff)

Actions

Copy link

Updated by Yingdi Yu almost 9 years ago

Description updated (diff)

Actions

Copy link

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.

Actions

Copy link

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.

Actions

Copy link

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).

Actions

Copy link

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

Actions

Copy link

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.

Actions

Copy link