Re: [cabfpub] CA/Browser Forum ASN.1 module

[Ryan Sleevi via Public]

On Mon, Feb 27, 2017 at 12:35 PM, Peter Bowen  wrote:

> First, the modules in the current X.520 SelectedAttributes module all use
> UnboundedDirectoryString, while we expect upper bounds on some strings.


Fair enough, although RFC 5280 defines these upper bounds, and 5280 is
normative. I think the subtlety of 5280 vs X.520 may be lost for some
members, so I think it's reasonable here, although RFC 5912 may be suitable
for incorporation.


> Second, the BRs and EVGs have redefined the content of the attributes
> vis-a-vis X.520, so I think it makes sense to have our own version.


I think this is a much more compelling argument, since we've certainly seen
some confusion from members with respect to the normative constraints of
what this content must cover. Despite the Baseline Requirements defining
rules for the validation/verification of this information, the question of
what this contains (e.g. "country") is surprisingly one that's tripped up
more than a few member CAs.

Thanks for pointing out both of these issues.


> > I found a couple of errors in the tor appendix.  I think I got the
> intent right, but can someone please confirm?
> >
> > Can you clarify the errors you see? A quick visual scan only shows the
> differences being the introduction of the EXTENSION .. IDENTIFIED BY
> syntax, is that correct?
>
> cabf-caSigningNonce OBJECT IDENTIFIER ::= { cabf 41 }
> cabf-applicantSigningNonce OBJECT IDENTIFIER ::= { cabf 42 }
>
> Both of these use a “cabf” definition, but this is not defined anywhere.
> I was guessing it is
> cabf ID ::= { joint‐iso‐itu‐t(2) international‐organizations(23)
> ca‐browser‐forum(140) }
>
> However it could mean something under 2.23.140 (eg. 2.23.140.3 or so).
>

Ah, good point! I believe the 'intent' was 140.1 (consistent with the
.onion extension). Jeremy, given that DigiCert is issuing these
certificates, can you clarify what you've done in production?

Note, it was a 'bug' that we put the .onion extension on the .1 arc, since
.1 is for policies at https://cabforum.org/object-registry/
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

[cabfpub] Draft Agenda for F2F meeting Research Triangle Park, NC - March 21-23

[Virginia Fournier via Public]

Hi Kirk,

I will be participating remotely from CA, with a 3 hour time difference.  I 
plan to call in for a couple of sessions - Governance WG and any discussion of 
IP.  However, I would not be able to participate in any session that starts 
earlier than 9 am PT, because I have kids to get to school, etc. in the 
morning.  

I suggest that we move the “Review of IPR Procedures” to later in the day.  Is 
this a critical session?  What’s on the agenda for discussion at this session?  
Ditto for the PAG session.

If I’m needed for the Governance WG session, I will be able to participate 9 am 
PT and later.

Chris Nalevanko might be in the same position, as he’s in Seattle.


Best regards,

Virginia Fournier
Senior Standards Counsel
 Apple Inc.
☏ 669-227-9595
✉︎ v...@apple.com






On Feb 26, 2017, at 3:00 PM, public-requ...@cabforum.org wrote:

Send Public mailing list submissions to
public@cabforum.org

To subscribe or unsubscribe via the World Wide Web, visit
https://cabforum.org/mailman/listinfo/public
or, via email, send a message with subject or body 'help' to
public-requ...@cabforum.org

You can reach the person managing the list at
public-ow...@cabforum.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Public digest..."


Today's Topics:

  1. Re: Draft Agenda for F2F meeting Research Triangle Park, NC -
 March 21-23 (Kirk Hall)
  2. F2F topic - Future Thoughts (Kirk Hall)


--

Message: 1
Date: Sun, 26 Feb 2017 22:41:02 +
From: Kirk Hall 
To: CA/Browser Forum Public Discussion List ,
Ryan Sleevi 
Subject: Re: [cabfpub] Draft Agenda for F2F meeting Research Triangle
Park, NC - March 21-23
Message-ID:
<2879c514af1b4e72b36a10f4a1ce2...@pmspex04.corporate.datacard.com>
Content-Type: text/plain; charset="utf-8"

Yes, I should have clarified ? the prior versions of these topics were left as 
placeholders, to see if anyone wanted to continue the discussion on the topics. 
 I guess I could have been more generic to avoid confusion.

Ryan, I?ll try to work in all your suggestions.  I will comment on handling of 
the ?Future Thoughts? topic in a separate email.

I will delete the ?Day 2? carry-over topics from the Redmond meeting.  I 
propose to add the following topics for now.  If anyone wants additional topics 
on the Agenda for our next F2F, please let me know.

PAG Update
CT Days Results / CT issues
Network and Certificate System Security Requirements: Challenges, 
Interpretations [Does anyone want this?]
CAA [questions or issues may remain]
Pending Ballots

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Peter Bowen via 
Public
Sent: Sunday, February 26, 2017 1:31 PM
To: Ryan Sleevi 
Cc: Peter Bowen ; CA/Browser Forum Public Discussion List 

Subject: Re: [cabfpub] Draft Agenda for F2F meeting Research Triangle Park, NC 
- March 21-23


On Feb 26, 2017, at 12:48 PM, Ryan Sleevi 
> wrote:



On Sun, Feb 26, 2017 at 12:32 PM, Peter Bowen via Public 
> wrote:
Kirk,

It looks like Day 2 is mostly copied from the Redmond F2F agenda.  I don?t have 
an intention of repeating the topics I lead previously unless there are new 
things to cover.

Thanks,
Peter

Indeed, I was just about to suggest that for several of the other (non-Peter) 
topics, unless there's something new to cover - and ideally, discussed on the 
list prior - we shouldn't schedule those items either.

I also note that Day 1 limits the discussion of "Future Thoughts" to 45 
minutes, although I would suggest and suspect that this is a line of discussion 
that might easily occupy an hour and a half, if not more, as members work 
through understanding the various goals of the suggestions, and then try to map 
out possible paths towards those goals by articulating concerns and constraints 
that they may have.

Based on prior meetings I think we should also expand the trust store (browser) 
portion of the agenda.


If I might, borrowing from an "unconference" like approach, might I suggest 
that Day 1 gather the "Future Thoughts" as scheduled, and have a (brief) 
discussion and presentation of those future thoughts (also as scheduled), but 
we make use of time of Day 2 to actually explore and articulate how to get 
there. This would allow time for members to socialize and understand the items 
raised on Day 1, and then come back on Day 2 with a better sense of concerns 
and directions. I suspect this will allow us a much more productive discussion 
and figuring out next steps.

Yes, I think that this makes sense.

Maybe the post-SHA2 stuff can move to a possible topic for future thoughts.  I 
don?t know that we need 45 minutes allocated to 

Re: [cabfpub] CA/Browser Forum ASN.1 module

[Peter Bowen via Public]

> On Feb 27, 2017, at 11:34 AM, Ryan Sleevi  wrote:
> 
> 
> 
> On Mon, Feb 27, 2017 at 9:25 AM, Peter Bowen via Public  
> wrote:
> There have been some questions about expected ASN.1 grammar for BR & EV 
> certificates.  I’ve created a module that attempts to collect it all.
> 
> Why the duplication of the X.500 attribute definitions, renamed with the 
> prefix 'cabf' ? Do the existing set of module definitions not suffice via 
> import?

First, the modules in the current X.520 SelectedAttributes module all use 
UnboundedDirectoryString, while we expect upper bounds on some strings.  
Second, the BRs and EVGs have redefined the content of the attributes vis-a-vis 
X.520, so I think it makes sense to have our own version.  For example:

X.520, section 6.5.4: The Business Category attribute type specifies 
information concerning the occupation of some common objects, e.g., people. For 
example, this attribute provides the facility to interrogate the Directory 
about people sharing the same occupation 

EVG, section 9.2.4: This field MUST contain one of the following strings: 
"Private Organization", "Government Entity", "Business Entity", or 
"Non-Commercial Entity" depending upon whether the Subject qualifies under the 
terms of Section 8.5.2, 8.5.3, 8.5.4 or 8.5.5 of these Guidelines, 
respectively. 

To avoid confusion, I suggest we define our own attributes to ensure that CAs 
don’t incorrectly assume X.520 is the controlling definition.

> With respect to the EV OIDs, you used the abbreviation joi, which is 
> presumably jurisdictionOfIncorporation. However, Ballot 119 was adopted to 
> remove the "ofIncorporation" suffix. At the risk of subtle pedantry, I 
> suspect this might be better as
> 
> id-ev-jursidiction ID ::= {ldap-enterprise microsoft(311) ev(60) 2 1}
> id-ev-jurisdiction-localityName ID ::= {id-ev-jurisdiction 1}
> id-ev-jurisdiction-stateOrProvinceName ID ::= {id-ev-jurisdiction 2}
> id-ev-jurisdiction-countryName ID ::= {id-ev-jurisdiction 3}
> 
> I suspect Jody might be able to work with Microsoft's OID maintenance team to 
> figure out how Microsoft would prefer 60.2.1 be documented, similar to other 
> documents (e.g. 
> https://support.microsoft.com/en-us/help/287547/object-ids-associated-with-microsoft-cryptography
>  or https://msdn.microsoft.com/en-us/library/ms677614(v=vs.85).aspx )

Happy to make whatever changes are needed here.

> I found a couple of errors in the tor appendix.  I think I got the intent 
> right, but can someone please confirm?
> 
> Can you clarify the errors you see? A quick visual scan only shows the 
> differences being the introduction of the EXTENSION .. IDENTIFIED BY syntax, 
> is that correct?

cabf-caSigningNonce OBJECT IDENTIFIER ::= { cabf 41 }
cabf-applicantSigningNonce OBJECT IDENTIFIER ::= { cabf 42 }

Both of these use a “cabf” definition, but this is not defined anywhere.  I was 
guessing it is 
cabf ID ::= { joint‐iso‐itu‐t(2) international‐organizations(23) 
ca‐browser‐forum(140) }

However it could mean something under 2.23.140 (eg. 2.23.140.3 or so).

Thanks,
Peter


___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] [外部郵件] Re: Draft Agenda for F2F meeting Research Triangle Park, NC - March 21-23

[Dimitris Zacharopoulos via Public]

On 27/2/2017 3:22 μμ, realsky(CHT) via Public wrote:
>As for suggestion to Microsft , it was post by Dimitris, thanks for
> him. Because that mail was in my office computer, it is National
> holiday in Tawian, If Dimitris read the mail, please tell us the status.

Here is the current Issue status

Dimitris.




___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] CA/Browser Forum ASN.1 module

[Ryan Sleevi via Public]

On Mon, Feb 27, 2017 at 9:25 AM, Peter Bowen via Public  wrote:

> There have been some questions about expected ASN.1 grammar for BR & EV
> certificates.  I’ve created a module that attempts to collect it all.
>

Why the duplication of the X.500 attribute definitions, renamed with the
prefix 'cabf' ? Do the existing set of module definitions not suffice via
import?

With respect to the EV OIDs, you used the abbreviation joi, which is
presumably jurisdictionOfIncorporation. However, Ballot 119 was adopted to
remove the "ofIncorporation" suffix. At the risk of subtle pedantry, I
suspect this might be better as

id-ev-jursidiction ID ::= {ldap-enterprise microsoft(311) ev(60) 2 1}
id-ev-jurisdiction-localityName ID ::= {id-ev-jurisdiction 1}
id-ev-jurisdiction-stateOrProvinceName ID ::= {id-ev-jurisdiction 2}
id-ev-jurisdiction-countryName ID ::= {id-ev-jurisdiction 3}

I suspect Jody might be able to work with Microsoft's OID maintenance team
to figure out how Microsoft would prefer 60.2.1 be documented, similar to
other documents (e.g.
https://support.microsoft.com/en-us/help/287547/object-ids-associated-with-microsoft-cryptography
or https://msdn.microsoft.com/en-us/library/ms677614(v=vs.85).aspx )

I found a couple of errors in the tor appendix.  I think I got the intent
> right, but can someone please confirm?
>

Can you clarify the errors you see? A quick visual scan only shows the
differences being the introduction of the EXTENSION .. IDENTIFIED BY
syntax, is that correct?
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Ballot 187 - Make CAA Checking Mandatory

[Doug Beattie via Public]

> 
> On 22/02/17 22:32, Doug Beattie wrote:
> > I think we need to talk about negative caching TTL.  I recommend we add:
> >
> > -In the event there were no CAA records found, the CA may cache
> > the result for 24-hours or the value of the negative caching TTL.
> 
> Hi Doug,
> 
> I thought that Ryan addressed this by explaining the mechanism the DNS
> already provides for caching a negative response. What makes you think that
> mechanism is inappropriate?

OK

> > You reference CT logs, but I think we need to be more clear that they
> > need to be Active logs (anyone of the active logs on this page
> > https://sites.google.com/site/certificatetransparency/known-logs).
> 
> My rationale in not doing this was that I wanted to avoid referencing a list 
> of
> logs provided by any one particular vendor or CAB Forum member.
>
> > Not
> > doing so could allow someone to generate a pre-cert and post it to
> > their development CT log then wait a month/year before issuing the
> > real cert at which point the CAA check is long over the time limit.
> 
> This is possible, I suppose; what would a CA have to gain from such strange
> behaviour? The log is required to be "public"; I expect that to mean that the
> CT community is aware of its existence and that its endpoints respond
> appropriately to calls.
>

I just wanted to be sure that the undefined term "two public logs" was 
sufficiently clear.  If you feel it is, then fine.

> > I think we need to update the EVGL, section 11.7.1
> >
> > -For each Fully-Qualified Domain Name listed in a Certificate,
> > other than a Domain Name with .onion in the right-most label of the
> > Domain Name, the CA SHALL confirm that, as of the date the Certificate
> > was issued, the Applicant (or the Applicant’s Parent Company,
> > Subsidiary Company, or Affiliate, collectively referred to as
> > “Applicant” for the purposes of this section)  either is the Domain
> > Name Registrant or has control over the FQDN using a procedure
> > specified in Section 3.2.2.4 of the Baseline Requirements _and has
> > checked CAA in accordance with Section 3.2.2.8 of the Baseline
> > Requirements_.  For a Certificate issued to a Domain Name with .onion
> > in the right-most label of the Domain Name, the CA SHALL confirm that,
> > as of the date the Certificate was issued, the Applicant’s control
> > over the .onion Domain Name in accordance with Appendix F.
> 
> Why do you think this update is necessary? The BRs apply to the issuance of
> EV certificates just as much as any other sort, and CAA is mandatory in the
> BRs.

The relationship between the 2 documents is not always clear to me.  If the BRs 
apply then why do we have statements like this in EGVL, seems redundant with 
your assumption?
  9.5  Subscriber Public Key
  - The requirements in Section 6.1.1.3 of the Baseline requirements apply 
equally to EV Certificates.

I can't find any reference in the EVGL that says you cannot issue certificates 
with IP addresses in them.  Is this because we specifically excluded BR section 
3.2.2.5 somehow?  If so, is the new proposed section 3.2.2.8 also excluded from 
EV via the same mechanism, assumption or reference?

As long as you feel comfortable that CAA is properly documented as a 
requirement for EV by adding it to this section then I'm OK with that.

> > Several people have looked at RFC 6844 and have come away with
> > different interpretations of what the processing means, so I HIGHLY
> > recommend we include the CAA processing that MUST be performed so
> > there is no ambiguity and so it’s clear for auditors.
> 
> As noted, I have no wish to "fork" the CAA standard into the BRs. There are 
> six
> months before it is required for all CAs to start checking CAA.
> In that time, I hope that any necessary clarifications to the RFC can be 
> issued.
> If we get closer to the time and a follow-up ballot is deemed necessary
> because the situation is still unclear, we can pass one.
> 
> Gerv
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Ballot 188 - Clarify use of term "CA" in Baseline Requirements

[Ryan Sleevi via Public]

On Mon, Feb 27, 2017 at 10:52 AM, Dimitris Zacharopoulos 
wrote:

>
>>
> I think this is a potentially problematic definition, in that it relates
> to the scope of the operations of the audit, as well as matters below that
> I highlight. I'm hoping the proposers and drafters can clarify (or link to
> previous discussions) as to the reason in which "or its Affiliate" was
> introduced into these definitions, or to highlight where it was already a
> natural and existing part of these definitions.
>
>
> Peter already provided some clarity for this. The "Affiliate" language was
> not introduced by this ballot. It was already mentioned in several sections
> of the BRs (6.1.1.1 "CA Key Pair Generation", 6.1.2 "Private Key Delivery
> to Subscriber", 6.2.6 "Private Key Transfer into or from a Cryptographic
> Module", 7.1.2.2 "Subordinate CA Certificate" and  7.1.6.3 "Subordinate CA
> Certificates").
>

Unfortunately, I think the concern still remains that this is a subtle
introduction that goes from being scoped to specific sections (as you've
noted) to now being a foundational concept, which unfortunately 'weakens'
the BRs, I believe.

I totally understand and appreciate the intent to align here, especially
for the cases Peter noted, but I want to especially make sure to highlight
the issue that "or the Affiliate" can be problematic from a set of scope of
audits.

Basically, what's being asked for on this ballot is a trade-off from being
logically bugged (and I agree, this is an issue we should fix) to something
that is procedurally weaker, and I'm trying to figure out what the plan is
to align. From both you and Peter's response, it sounds like you don't
believe further changes are needed, and this is concerning.


> Peter's answer should cover this. Your follow-up questions challenge the
> fact that the current BRs treat Root Operator's "Affiliates" in a different
> way than the non-Affiliates but this is a policy matter and should be
> discussed separately. In any case, I don't think it changes the fact that
> all Subordinate CAs (whether internally or externally operated) need to be
> audited. In the case of Internally Operated Subordinate CAs, the audit
> might be covered in the Root Operator audit, and this information should be
> included in the audit scope.
>

That's the intent - but my question is, where is it specified? I may have
missed that, and that was the point of raising these concerns: if I'm
misreading, and it's already addressed, fantastic. But I don't believe it
is, hence the concern :)


> After several discussions within the WG, it was agreed that the most
> accurate technical language is that "Private Keys sign Certificates".
> Certificates, don't sign Certificates.
>

I understand the "why". I'm more specifically asking three questions:
1) Is my interpretation correct?
2) Is this desired?
3) Is there a plan to fix it?

>From the rest of this section, I can interpret your response as "1) Yes 2)
No, not necessarily 3) Not really, but we could come up with one". I'm not
sure if that really provides the level of assurance when considering
whether to vote on this ballot, even though I agree and understand the why,
and am relieved it isn't intended.


> So, according to your example, if the ResponderID was the hash of the
> Subordinate CA Certificate's public key, it would not be prohibited even
> though that key would be included in two or more Subordinate CA
> Certificates. Perhaps the multiple CA Certificates with the same key-pair
> scenario is not entirely addressed. We could update the BRs to specifically
> include language for the ResponderID information, if you think people would
> be puzzled about what information should be included in that field.
>

Whether we address this by specifying language fro the ResponderID (which
seems overly specific) or by addressing the general concern, I'd like to
see a concrete proposal to address this, ideally before voting concludes.


> In Section 4.9.10 (On-line revocation checking requirements)
>>
>>
> Was this intentional?
>
>
> This specific change was addressed during the discussion phase (
> https://www.mail-archive.com/public@cabforum.org/msg02652.html).
>

Did you link to the right thread? I cannot find a clear answer, but perhaps
I'm just missing it. As it stands, I think this alone is potentially
grounds that we may need to vote against it, because it's a clear reduction
in assurance.


> A typo indeed. It is clear in the red-lined version.
>

For future reference, we should try to figure out what version is being
voted on, when the e-mailed ballot and Red Line disagree :) This is a minor
issue, but I can easily see more significant issues creeping in, least of
all, because I have not looked at all at the Red Lined version, because
that's not the balloted text :)


> In Section 8.7 (Self-Audits)
>>
>>
>> Replace the last paragraph with:
>>
>> During the period in which a Technically Constrained Externally Operated
>> 

Re: [cabfpub] Ballot 187 - Make CAA Checking Mandatory

[Gervase Markham via Public]

On 22/02/17 22:32, Doug Beattie wrote:
> I think we need to talk about negative caching TTL.  I recommend we add:
> 
> -In the event there were no CAA records found, the CA may cache
> the result for 24-hours or the value of the negative caching TTL.

Hi Doug,

I thought that Ryan addressed this by explaining the mechanism the DNS
already provides for caching a negative response. What makes you think
that mechanism is inappropriate?

> You reference CT logs, but I think we need to be more clear that they
> need to be Active logs (anyone of the active logs on this page
> https://sites.google.com/site/certificatetransparency/known-logs).

My rationale in not doing this was that I wanted to avoid referencing a
list of logs provided by any one particular vendor or CAB Forum member.

> Not
> doing so could allow someone to generate a pre-cert and post it to their
> development CT log then wait a month/year before issuing the real cert
> at which point the CAA check is long over the time limit.

This is possible, I suppose; what would a CA have to gain from such
strange behaviour? The log is required to be "public"; I expect that to
mean that the CT community is aware of its existence and that its
endpoints respond appropriately to calls.

> I think we need to update the EVGL, section 11.7.1
> 
> -For each Fully-Qualified Domain Name listed in a Certificate,
> other than a Domain Name with .onion in the right-most label of the
> Domain Name, the CA SHALL confirm that, as of the date the Certificate
> was issued, the Applicant (or the Applicant’s Parent Company, Subsidiary
> Company, or Affiliate, collectively referred to as “Applicant” for the
> purposes of this section)  either is the Domain Name Registrant or has
> control over the FQDN using a procedure specified in Section 3.2.2.4 of
> the Baseline Requirements _and has checked CAA in accordance with
> Section 3.2.2.8 of the Baseline Requirements_.  For a Certificate issued
> to a Domain Name with .onion in the right-most label of the Domain Name,
> the CA SHALL confirm that, as of the date the Certificate was issued,
> the Applicant’s control over the .onion Domain Name in accordance with
> Appendix F.

Why do you think this update is necessary? The BRs apply to the issuance
of EV certificates just as much as any other sort, and CAA is mandatory
in the BRs.

> Several people have looked at RFC 6844 and have come away with different
> interpretations of what the processing means, so I HIGHLY recommend we
> include the CAA processing that MUST be performed so there is no
> ambiguity and so it’s clear for auditors.

As noted, I have no wish to "fork" the CAA standard into the BRs. There
are six months before it is required for all CAs to start checking CAA.
In that time, I hope that any necessary clarifications to the RFC can be
issued. If we get closer to the time and a follow-up ballot is deemed
necessary because the situation is still unclear, we can pass one.

Gerv
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

[cabfpub] CA/Browser Forum ASN.1 module

[Peter Bowen via Public]

There have been some questions about expected ASN.1 grammar for BR & EV 
certificates.  I’ve created a module that attempts to collect it all.

I found a couple of errors in the tor appendix.  I think I got the intent 
right, but can someone please confirm?

Li-Chun: does this resolve your concerns about lack of documentation?

Thanks,
Peter

CABFSelectedAttributeTypes {joint‐iso‐itu‐t(2) international‐organizations(23) 
ca‐browser‐forum(140) module(4) cabfSelectedAttributeTypes(1) 1}
DEFINITIONS ::=
BEGIN

-- EXPORTS All
-- The types and values defined in this module are exported for use in X.509
-- certificates that comply with CA/Browser Forum guidelines.  Some definitions
-- are taken from Rec. ITU-T X.520 | ISO/IEC 9594-6, but the Forum does not
-- assume the existence of a Directory, Directory Information Base (DIB), or
-- Directory Information Tree.  CABFName does not have tree semantics except
-- when being processed for name constraints.

IMPORTS

  -- from Rec. ITU-T X.501 | ISO/IEC 9594-2

  informationFramework, selectedAttributeTypes, ID, ldap-enterprise
FROM UsefulDefinitions {joint-iso-itu-t ds(5) module(1) 
usefulDefinitions(0) 7}

  Attribute{}, AttributeTypeAndValue
FROM InformationFramework informationFramework

  -- from the X.500 series

  ub-common-name, ub-surname, ub-organization-name, ub-street-address, 
ub-locality-name,
  ub-state-name, ub-postal-code, ub-organizational-unit-name, 
ub-business-category,
  ub-serial-number
FROM UpperBounds {joint-iso-itu-t ds(5) module(1) upperBounds(10) 7}

  -- from Rec. ITU-T X.520 | ISO/IEC 9594-6

  DirectoryString{}, UnboundedDirectoryString, caseIgnoreMatch, 
caseIgnoreSubstringsMatch,
  CountryName, id-at-commonName, id-at-surname, id-at-givenName, 
id-at-givenName,
  id-at-organizationName, id-at-streetAddress, id-at-localityName, 
id-at-stateOrProvinceName,
  id-at-postalCode, id-at-countryName, id-at-organizationalUnitName, name, 
id-at-serialNumber,
  id-at-businessCategory, octetStringMatch
FROM SelectedAttributeTypes selectedAttributeTypes;

-- to be used TBSCertificate.subject and TBSCertificate.issuer
-- when encoded using BER/CER/DER, can be decoded as RDNSequence
CABFName ::= SEQUENCE OF SET SIZE (1..MAX) OF AttributeTypeAndValue

cabfCommonName ATTRIBUTE ::= {
  SUBTYPE OF   name
  WITH SYNTAX  DirectoryString{ub-common-name}
  LDAP-SYNTAX  directoryString.
  LDAP-NAME{"cn", "commonName"}
  ID   id-at-commonName }

cabfSurname ATTRIBUTE ::= {
  SUBTYPE OF   name
  WITH SYNTAX  DirectoryString{ub-surname}
  LDAP-SYNTAX  directoryString.
  LDAP-NAME{"sn"}
  ID   id-at-surname }

cabfGivenName ATTRIBUTE ::= {
  SUBTYPE OF   name
  WITH SYNTAX  UnboundeDirectoryString
  LDAP-SYNTAX  directoryString.
  LDAP-NAME{"givenName"}
  ID   id-at-givenName }

cabfOrganizationName ATTRIBUTE ::= {
  SUBTYPE OF   name
  WITH SYNTAX  DirectoryString{ub-organization-name}
  LDAP-SYNTAX  directoryString.
  LDAP-NAME{"o"}
  ID   id-at-organizationName }

cabfStreetAddress ATTRIBUTE ::= {
  WITH SYNTAX  DirectoryString{ub-street-address}
  EQUALITY MATCHING RULE   caseIgnoreMatch
  SUBSTRINGS MATCHING RULE caseIgnoreSubstringsMatch
  LDAP-SYNTAX  directoryString.
  LDAP-NAME{"street"}
  ID   id-at-streetAddress }

cabfLocalityName ATTRIBUTE ::= {
  SUBTYPE OF   name
  WITH SYNTAX  DirectoryString{ub-locality-name}
  LDAP-SYNTAX  directoryString.
  LDAP-NAME{"l"}
  ID   id-at-localityName }

cabfStateOrProvinceName ATTRIBUTE ::= {
  SUBTYPE OF   name
  WITH SYNTAX  DirectoryString{ub-state-name}
  LDAP-SYNTAX  directoryString.
  LDAP-NAME{"st"}
  ID   id-at-stateOrProvinceName }

cabfPostalCode ATTRIBUTE ::= {
  WITH SYNTAX  DirectoryString{ub-postal-code}
  EQUALITY MATCHING RULE   caseIgnoreMatch
  SUBSTRINGS MATCHING RULE caseIgnoreSubstringsMatch
  LDAP-SYNTAX  directoryString.
  LDAP-NAME{"postalCode"}
  ID   id-at-postalCode }

cabfCountryName ATTRIBUTE ::= {
  SUBTYPE OF   name
  WITH SYNTAX  CountryName
  SINGLE VALUE TRUE
  LDAP-SYNTAX  countryString.
  LDAP-NAME{"c"}
  ID   id-at-countryName }

cabfOrganizationalUnitName ATTRIBUTE ::= {
  SUBTYPE OF   name
  WITH SYNTAX  DirectoryString{ub-organizational-unit-name}
  LDAP-SYNTAX  directoryString.
  LDAP-NAME{"ou"}
  ID   id-at-organizationalUnitName }

cabfBusinessCategory 

Re: [cabfpub] [外部郵件] Re: Draft Agenda for F2F meeting Research Triangle Park, NC - March 21-23

[realsky(CHT) via Public]

Since I needed an invitation letter to join F2F meeting, so I remeber Dean told 
me the meeting agenda is  confirmed one week or two weeks before the F2F 
meeting. The agenda was copied from Redmond meeting with little modification. I 
agree with  Ryan' and Peter's suggestion. It is time for Kirk to collet 
suggestion to arrange the new meeting agenda and update the Wiki.  


   As for Redmond's meeting, my topic about changing to browser UI for Subject 
DN of EV SSL Certificate has not yet be resolved. 

  It seems there is no further progress after I and Dimitris file a bug 
https://bugzilla.mozilla.org/show_bug.cgi?id=1308755
https://bugzilla.mozilla.org/show_bug.cgi?id=500333

   As for suggestion to Microsft , it was post by Dimitris, thanks for him. 
Because that mail was in my office computer, it is National holiday in Tawian, 
If Dimitris read the mail, please tell us the status.

 Li-Chun Chen
 Chunghwa Telecom 



-Original message-
From:Ryan Sleevi via Public
To:CA/Browser Forum Public Discussion List
Cc:Ryan Sleevi
Date: Mon, 27 Feb 2017 04:48:43
Subject: [外部郵件] Re: [cabfpub] Draft Agenda for F2F meeting Research Triangle 
Park, NC - March 21-23


On Sun, Feb 26, 2017 at 12:32 PM, Peter Bowen via Public  
wrote:
Kirk,

It looks like Day 2 is mostly copied from the Redmond F2F agenda.  I don’t have 
an intention of repeating the topics I lead previously unless there are new 
things to cover.

Thanks,
Peter

Indeed, I was just about to suggest that for several of the other (non-Peter) 
topics, unless there's something new to cover - and ideally, discussed on the 
list prior - we shouldn't schedule those items either.

I also note that Day 1 limits the discussion of "Future Thoughts" to 45 
minutes, although I would suggest and suspect that this is a line of discussion 
that might easily occupy an hour and a half, if not more, as members work 
through understanding the various goals of the suggestions, and then try to map 
out possible paths towards those goals by articulating concerns and constraints 
that they may have.

If I might, borrowing from an "unconference" like approach, might I suggest 
that Day 1 gather the "Future Thoughts" as scheduled, and have a (brief) 
discussion and presentation of those future thoughts (also as scheduled), but 
we make use of time of Day 2 to actually explore and articulate how to get 
there. This would allow time for members to socialize and understand the items 
raised on Day 1, and then come back on Day 2 with a better sense of concerns 
and directions. I suspect this will allow us a much more productive discussion 
and figuring out next steps.

Alternatively, we could consider gathering those discussion items now, prior to 
the meeting. Day 1 can include a summary of the items and themes and allow time 
for basic clarification, and then we can dedicate several discussion slots on 
Day 2 to explore those items identified as either controversial or as shared 
interest, so that we can more rapidly make progress. This might make it more 
productive then, say, if I were to request several agenda slots for what Google 
considers as high importance and future direction.

Another agenda item I might suggest, and I'm happy to be the 'discussion 
leader' because of it, is the question about the role and relationship of the 
Forum. Judging by the reactions to Ballot 185, and from various questions that 
have come in on the questions@ list which have sparked debate, perhaps it's 
worth revisiting how different members see the role and scope of the Forum, so 
that we can better understand each other's objectives and needs.

There also appears to be one or two agenda items previously discussed, but 
missing. One was a retrospective discussion about the SHA-1 deprecation, with 
input from various Browsers, to help capture and crystalize the challenges and 
to examine some of the lessons learned from the SHA-1 exception process. 
Another was more targeted towards the technical members of the Forum, which is 
related to workflow management (GitHub, production of PDFs, etc), with the goal 
of making it less onerous on Ben to manage that. I realize that the Forum has 
historically conducted a 'single track' meeting schedule, there may be 
opportunity during the WG day to run that exploration in parallel, if there's 
space available. My instinct is that there may be sufficient non-overlap in 
members as the Governance discussions, but as the agenda for Day 2 shapes out, 
there may be an opportunity there instead.

 
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public




本信件可能包含中華電信股份有限公司機密資訊,非指定之收件者,請勿蒐集、處理或利用本信件內容,並請銷毀此信件. 
如為指定收件者,應確實保護郵件中本公司之營業機密及個人資料,不得任意傳佈或揭露,並應自行確認本郵件之附檔與超連結之安全性,以共同善盡資訊安全與個資保護責任. 
Please be advised that this email message (including any attachments) contains