[cabfpub] ambiguity implementing permanentIdentifier

Rick Andrews Rick_Andrews at symantec.com
Tue May 24 13:27:40 UTC 2016


Erwann, as far as I know, REG is the registration number, indirectly representing the ORG. But why not directly include ORG?

 

-Rick

 

From: Erwann Abalea [mailto:Erwann.Abalea at docusign.com] 
Sent: Tuesday, May 24, 2016 6:14 AM
To: Rick Andrews <Rick_Andrews at symantec.com>
Cc: Jeremy Rowley <jeremy.rowley at digicert.com>; Rich Smith <richard.smith at comodo.com>; public at cabforum.org
Subject: Re: [cabfpub] ambiguity implementing permanentIdentifier

 

Isn’t REG representative of ORG, within a CC+LOC/STATE scope? 

 

Cordialement,

Erwann Abalea

 

Le 24 mai 2016 à 15:05, Rick Andrews <Rick_Andrews at symantec.com <mailto:Rick_Andrews at symantec.com> > a écrit :

 

Jeremy,

 

Why do a) i) and b) i) not end in –ORG? It seems like we want to put REG or DATE in the identifier, but I think we should always have ORG.

 

-Rick

 

From: public-bounces at cabforum.org <mailto:public-bounces at cabforum.org>  [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley
Sent: Friday, May 06, 2016 1:37 PM
To: Rich Smith <richard.smith at comodo.com <mailto:richard.smith at comodo.com> >; public at cabforum.org <mailto:public at cabforum.org> 
Subject: Re: [cabfpub] FW: ambiguity implementing permanentIdentifier

 

This section needs several revisions, which we’ve discussed on the code signing mailing list. It’s probably about time to ballot some of these.  Here’s a proposed change we previously discussed in the working group:

 

The Certificate MUST include a SubjectAltName:permanentIdentifier (identifier). This field MUST contain a Unicode string created from the contents of the Certificate's subject fields using the first of the following to apply: 

a) If the Certificate contains the subjectjurisdictionOfIncorporationLocalityName field then

i) if the Certificate contains a Registration Number then the identifier is created and formatted as "CC-LOC-REG"

ii) if the Certificate contains a Registration Date then identifier is created and formatted as "CC-LOC-DATE-ORG"

iii) otherwise the identifier is created and formatted as "CC-LOC-ORG"

 

b) If the Certificate contains the subjectjurisdictionOfIncorporationStateorProvinceName field then

i) if the Certificate contains a Registration Number then identifier is created and formatted as "CC-STATE-REG"

ii) if the Certificate contains a Registration Date then identifier is created and formatted as "CC-STATE-DATE-ORG"

iii) otherwise the identifier is  created and formatted as "CC-STATE-ORG"

 

Where:

a) CC is the ISO 3166-2 country code corresponding Subject’s Jurisdiction of Incorporation or Registration (CC), as specified in the subject:jurisdictionOfIncorporationCountryName field;

b) LOC is Subject’s Jurisdiction of Incorporation in uppercase characters as specified in the subjectjurisdictionOfIncorporationLocalityName, expressed in an unabbreviated format;

c) STATE is the Subject's Jurisdiction of Incorporation in uppercase characters as specified in the subject:jurisdictionofIncorporationStateorProvinceName field, expressed in an unabbreviated format;

d) REG is the Subject's Registration Number as included in the Subject:serialNumber field;

e) DATE is the Subject's date of Incorporation or Registration in YYYY-MM-DD format (DATE) as included in the Subject:serialNumber field; and

f) ORG is the Subject’s Organization Name as included in the organizationName field (ORG), 

g) All included “-“ characters are Unicode 002D and any included spaces in REG, STATE, or ORG are Unicode 0020. 

 

The “assigner name form” MUST be absent from the SAN field used for the permanentIdentifier. However, it is expected that Application Software will treat the permanentIdentifier as globally unique.

 

Jeremy

 

 

From:  <mailto:public-bounces at cabforum.org> public-bounces at cabforum.org [ <mailto:public-bounces at cabforum.org> mailto:public-bounces at cabforum.org] On Behalf Of Rich Smith
Sent: Friday, May 6, 2016 1:49 PM
To:  <mailto:public at cabforum.org> public at cabforum.org
Subject: Re: [cabfpub] FW: ambiguity implementing permanentIdentifier

 

This portion is pretty much identical to the EV Guidelines and I've always interpreted it to mean that for a business registered at the locality level, regardless of whether or not regulated by the state/province, the correct encoding is:
JC = xx, JST = yy, JL = zz

On 5/6/2016 2:41 PM, Dean Coclin wrote:

Forwarding to the public list for greater reach and commentary…

 

From:  <mailto:codesigning-bounces at cabforum.org> codesigning-bounces at cabforum.org [ <mailto:codesigning-bounces at cabforum.org> mailto:codesigning-bounces at cabforum.org] On Behalf Of Koichi Sugimoto
Sent: Friday, May 06, 2016 5:59 AM
To:  <mailto:codesigning at cabforum.org> codesigning at cabforum.org
Subject: [cabfc_s] ambiguity implementing permanentIdentifier

 

Hello,

 

While I analyzing SubjectAltName:permanentIdentifier specified in section 9.7 of EV-Code-Signing-v.1.3.pdf,
I found an ambiguity of generating “STATE”.

9.7 (B) 2) says:

If applicable, the state, province, or locality of the Subject’s Jurisdiction of Incorporation in

uppercase characters as specified in the subjectjurisdictionOfIncorporationLocalityName or

subject:jurisdictionofIncorporationStateorProvinceName field, expressed in an unabbreviated

format (STATE);

 

Let JST be subjectjurisdictionOfIncorporationLocalityName and JL be subject:jurisdictionofIncorporationStateorProvinceName.

In such case, following all patterns are acceptable?

 

a)    STATE=ST

b)    STATE=JL-ST

c)    STATE=JL

 

I also have a problem of implementing JST and JL.

Section 9.2.5 of EV-V1_5_9.pdf specifies how to implement JST, JL and JC (JC means subject:jurisdictionCountryName).

The specification says:

For example, the Jurisdiction of Incorporation for an Incorporating Agency or

Jurisdiction of Registration for a Registration Agency that operates at the country level MUST include the country

information but MUST NOT include the state or province or locality information. Similarly, the jurisdiction for

the applicable Incorporating Agency or Registration Agency at the state or province level MUST include both

country and state or province information, but MUST NOT include locality information. And, the jurisdiction for

the applicable Incorporating Agency or Registration Agency at the locality level MUST include the country and

state or province information, where the state or province regulates the registration of the entities at the locality

level, as well as the locality information.

 

I understand this definition as:

 

If COUNTRY LEVEL

JC = xx

ELSE IF ST/P LEVEL

JC = xx, JST = yy

ELSE (=IF LOCALITY LEVEL) {

IF "state or province regulates the registration of the entities at the locality level"

JC = xx, JST = yy, JL = zz

ELSE (=IF "state or province does not regulate the registration of the entities at the locality level")

JC = xx, JL = zz

}

 

I am very interested in the yellow colored parts.

 

If both are acceptable, it’s OK.

But, if “c) STATE=JL” is not acceptable, then, how should we cope with the case of “JC=xx, JL=zz”?

And also if “JC=xx, JL=zz” is not acceptable, how should we cope with the case of “c) STATE=JL”?

 

 

Regards,

Koichi Sugimoto.

 






_______________________________________________
Public mailing list
 <mailto:Public at cabforum.org> Public at cabforum.org
 <https://cabforum.org/mailman/listinfo/public> https://cabforum.org/mailman/listinfo/public

 

_______________________________________________
Public mailing list
Public at cabforum.org <mailto:Public at cabforum.org> 
https://cabforum.org/mailman/listinfo/public

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160524/73c3133d/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5725 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160524/73c3133d/attachment-0001.p7s>


More information about the Public mailing list