ndncert

After changing the new email assignment function to this, the crashes stopped:

std::vector <ndn::PartialName>
AssignmentEmailv2::assignName(const std::multimap<std::string, std::string>& params)
{
  std::vector<ndn::PartialName> returnList;
  const std::string& email = params.begin()->second;
  Name result;
  const ndn::name::Component c(email);
  result.append(c);
  returnList.push_back(std::move(result));
  return returnList;
}

So, now the new implementation will allow for names with '=' and '/' but the old one doesn't

Thanks for the bug report. I'm guessing the email-to-name conversion doesn't properly escape characters that are considered reserved in NDN name URIs. I'd say that's the bigger issue here (admittedly, email addresses with / or = are fairly rare).

Davide Pesavento wrote in #note-3:

Thanks for the bug report. I'm guessing the email-to-name conversion doesn't properly escape characters that are considered reserved in NDN name URIs. I'd say that's the bigger issue here (admittedly, email addresses with / or = are fairly rare).

Yeah, for sure. I have a feeling this issue is pretty deep (probably in the ndn-cxx Name object construction, not ndncert). From my testing, ndn::name::Component escapes all characters, which may help with the '=' character, but we'll have to think more about the '/'.

After a closer look, I'm confused.

The code quoted in the description doesn't make sense (it's trying to construct a Component and immediately parse it back as a Name), and more importantly it's different from what I see in AssignmentEmail. Moreover, it seems that the existing AssignmentEmail can handle = and / in emails just fine, as demonstrated in this test case. So if there is a bug somewhere, it isn't in this code.

Davide Pesavento wrote in #note-5:

After a closer look, I'm confused.

The code quoted in the description doesn't make sense (it's trying to construct a Component and immediately parse it back as a Name), and more importantly it's different from what I see in AssignmentEmail. Moreover, it seems that the existing AssignmentEmail can handle = and / in emails just fine, as demonstrated in this test case. So if there is a bug somewhere, it isn't in this code.

If I could remove the code from the original description, I would, because it doesn't run and is sort of unrelated. I also agree that the bug must be somewhere else.

https://redmine.named-data.net/issues/5351#note-1 is the working code from here https://gerrit.named-data.net/c/ndncert/+/7662 and it's because I'm trying to keep the email inside one name component, so I force it to be. Using the ndn::Name() constructor, '/' will break it into multiple and '=' will throw an error

Davide Pesavento wrote in #note-7:

Adam Thieme wrote in #note-6:

Using the ndn::Name() constructor, '/' will break it into multiple and '=' will throw an error

That's the expected behavior for the Name constructor that takes a string. As the documentation says, it constructs the Name from an NDN URI, so the string must be a valid URI.

If you want an arbitrary string in a single component, you have to construct a Component from the string and append the Component to a (possibly empty) Name, as you already found out.

There doesn't seem to be a bug in the current AssignmentEmail code, so I'll go ahead and close this issue. Please let me know if I've missed something.

This (sending INVALID_PARAMETER on emails with '/' or '=') is still happening:

Slashes and '=' are allowed in the local/first part of an email address, according to RFC 3696
https://www.rfc-editor.org/rfc/rfc3696#section-3

   Without quotes, local-parts may consist of any combination of
   alphabetic characters, digits, or any of the special characters

      ! # $ % & ' * + - / = ?  ^ _ ` . { | } ~

Requesting an email with a slash results in INVALID_PARAMETER error from CA:

Step 2: Please provide information for name assignment
Please input: email
first/last@sub.domain.tld
Got it. This is what you've provided:
email : first/last@sub.domain.tld
The probed CA response cannot be used because: Error info replied from the CA with Error code: INVALID_PARAMETER and Error Info: Cannot generate available names from parameters provided.

This example email from the RFC also fails in the same way:

customer/department=shipping@example.com

Would it be better to create a new issue with just this (without mentioning the assignName function at all)?

Sorry, I cannot reproduce that error with the latest ndncert.

***************************************
Step 1: CA SELECTION
> Index: 0
>> CA prefix:/ndn
>> Introduction: 
Please type in the CA's index that you want to apply or type in NONE if your expected CA is not in the list:
0

***************************************
Step 2: Please provide information for name assignment
Please input: email
first/last@sub.domain.tld
Got it. This is what you've provided:
email : first/last@sub.domain.tld
You are applying for name: /ndn/tld/domain/sub/first%2Flast

***************************************
Step 3: Please type in your expected validity period of your certificate. Type the number of hours (168 for week, 730 for month, 8760 for year). The CA may reject your application if your expected period is too long. The maximum validity period allowed by this CA is 360 hours.
1
The validity period of your certificate will be: 1 hours

***************************************

Davide Pesavento wrote in #note-9:

Sorry, I cannot reproduce that error with the latest ndncert.

***************************************
Step 1: CA SELECTION
> Index: 0
>> CA prefix:/ndn
>> Introduction: 
Please type in the CA's index that you want to apply or type in NONE if your expected CA is not in the list:
0

***************************************
Step 2: Please provide information for name assignment
Please input: email
first/last@sub.domain.tld
Got it. This is what you've provided:
email : first/last@sub.domain.tld
You are applying for name: /ndn/tld/domain/sub/first%2Flast

***************************************
Step 3: Please type in your expected validity period of your certificate. Type the number of hours (168 for week, 730 for month, 8760 for year). The CA may reject your application if your expected period is too long. The maximum validity period allowed by this CA is 360 hours.
1
The validity period of your certificate will be: 1 hours

***************************************

Thanks for testing this. Is this on the testbed or local? If it's local, what configuration did you use?

Testbed.

Davide Pesavento wrote in #note-11:

Testbed.

Thanks, I'll look into it.

Adam Thieme wrote in #note-12:

Davide Pesavento wrote in #note-11:

Testbed.

Thanks, I'll look into it.

I found that this is a configuration issue;
this works

  "name-assignment":{
    "email":"/example"
  }

but this has the "INVALID_PARAMETER" issue with certain characters

  "name-assignment":{
    "email":""
  }

I'll send a patch to the wiki to add info on the email name assignment config.

https://github.com/named-data/ndncert/wiki/NDNCERT-CA-Configuration

Adam Thieme wrote in #note-13:

but this has the "INVALID_PARAMETER" issue with certain characters

  "name-assignment":{
    "email":""
  }

I don't think the above config will work with any email. If the value is empty, the name assignment function won't even try to generate any assignments, and eventually the CA will return an error.

"email": "/" should work as a minimal config (please test). I suppose we could make "email": "" be treated the same as "email": "/" for better UX, assuming it doesn't break anything else, but this is orthogonal to the original issue.