Which of those two proposals are "privately extensible"?
The first one (with SemanticsInformation), once implemented, should work
for any identifiers (LEI etc.) with almost no code change. Let's discuss
those ETSI proposals separately :)
Thanks,
M.D.
On 7/9/2018 5:18 PM, Ryan Sleevi wrote:
They aren't well-specified, because they're privately extensible.
On Mon, Jul 9, 2018 at 10:13 AM Tim Hollebeek
<[email protected] <mailto:[email protected]>> wrote:
Right. My original objection was that the semantics weren’t
specified, but as you and others (privately) have pointed out to
me, they’re actually specified quite well. We just need to point
to the relevant ETSI standards documents.
-Tim
*From:*Moudrick M. Dadashov [mailto:[email protected] <mailto:[email protected]>]
*Sent:* Sunday, July 8, 2018 9:18 AM
*To:* Ryan Sleevi <[email protected] <mailto:[email protected]>>;
CA/Browser Forum Public Discussion List <[email protected]
<mailto:[email protected]>>; Tim Hollebeek
<[email protected] <mailto:[email protected]>>
*Subject:* Re: [cabfpub] LEI information in web certificates
IMHO ETSI case needs some clarification - in fact we have two
different issues here:
1. qualified and non-qualified certificate profiles (use of
"qcStatement-2" identified by the OID id-qcspkixQCSyntax-v2
with the SemanticsInformation syntax, see
http://www.etsi.org/deliver/etsi_en/319400_319499/31941201/01.01.01_60/en_31941201v010101p.pdf).
2. ETSI proposal related to certificates issued to payment
service operators (see
https://cabforum.org/pipermail/validation/2018-June/000948.html)
In short, the first one says: if combined with the OID
id-qcspkixQCSyntax-v2 the syntax of serial-number is:
TTTCC-identifier
where TTT is a type of registry (from the list below);
CC - an ISO 3166 country code;
identifier means whatever we use today as a serial-number.
The predefined types of registries (TTT) are:
VAT - national VAT registry;
NTR - national trade registry;
PAS - national passport registry;
IDC - national ID card registry;
PNO - national civic registry;
TIN - Tax Identification registry
(https://ec.europa.eu/taxation_customs/tin/tinByCountry.html).
but we can add more TTTs e.g. SSN, IRS etc., so the composite
serial-number in a certificate would look like this: IRSUS-123456789
Also, TTT allows you to identify the subjects from country
specific registries (explicitly identified in certificate, see
details in RFC 3739).
As for the second ETSI proposal, I suspect a little
misunderstanding - in the scenario where third party payment (TPP)
service providers play their role (see attached) they need
*client* authentication certificates.
Thanks,
M.D.
On 7/7/2018 12:36 AM, Ryan Sleevi via Public wrote:
On Fri, Jul 6, 2018 at 4:29 PM Tim Hollebeek via Public
<[email protected] <mailto:[email protected]>> wrote:
As many of you are aware, the GLEIF foundation recently
invited CA/Browser Forum members to its identity
management workshop. Some people have contacted us about
the possibility of putting LEI identifiers into web
certificates. This is in some ways similar to the recent
proposal from ETSI to put additional identity information
into certificates, though it has the advantage that we are
free to determine ourselves how best to encode it.
CAs are already allowed to include this information in
certificates, assuming it has been appropriately
validated. There is a Global Legal Entity Identifier
Index that is authoritative for LEIs. However it would be
valuable if there were a standardized CABF OID and
extension so that every CA that chooses to include this
information includes it in an interoperable way. This
also allocates the OID in a namespace we control, allowing
us to state in the BRs the purpose and semantics of the
extension, and require that it only be used for authentic
and validated LEIs.
It seems to me that it would be worthwhile to standardize
this, instead of every CA coming up with their own way of
doing it. What do other people think?
Could you explain how this information would be used by
Relying Parties?
The GLEIF model effectively relies on third-party RAs, with
all of the attendant issues, and without a clear framework for
addressing many of the issues that has been held in the CA
ecosystem. I'm not sure the value proposition here, or that
the information is something RPs should necessarily use. As to
whether or not it's appropriate, I think that's going to be
very much contingent upon what the intended semantics being
introduced are - that is, what relationship, if any, is being
expressed between the LEI ID and the domain - and that opens a
host of complexity that could easily detract from the far more
pressing and meaningful work on improving the domain and
information validation.
I'm not sure why a CABF OID would be more useful than a GLEIF
OID (which seems far more appropriate), and with a defined
syntax relevant for GLEIF. I can think of no good reason to
use the CABF arc, so I'm hoping you could explain more that
thinking.
_______________________________________________
Public mailing list
[email protected] <mailto:[email protected]>
https://cabforum.org/mailman/listinfo/public
_______________________________________________
Public mailing list
[email protected]
https://cabforum.org/mailman/listinfo/public
