[cabfpub] Section 9.2.3 modification

Jeremy Rowley jeremy.rowley at digicert.com
Thu May 23 05:06:35 UTC 2013


The original idea was that a CA would need to take action if it didn’t understand why information was being included in the DC field, similar to Brad Hill’s proposal on limiting extensions to only those the CA understands.  A practical example would be similar to that process where a CA just had to maintain documentation about why the information was included in a certificate.

 

However, Ryan Sleevi pointed out several problems with the language so I’ve since modified the motion.  I’m unsure on what he is suggesting in his last email (whether he wants to mirror 9.2.7, drop 9.2.3 and rely on the requirements of 9.2.7, or something else), but I’ll be updating the proposal once I hear back from him.

 

Jeremy

 

From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of kirk_hall at trendmicro.com
Sent: Wednesday, May 22, 2013 7:13 PM
To: jeremy.rowley at digicert.com; public at cabforum.org
Subject: Re: [cabfpub] Section 9.2.3 modification

 

Jeremy – as a practical matter, I don’t understand what this sentence means: “The CA SHALL implement and follow a process that prevents a Domain Component field from including  information if the CA is unaware of the logical association between the Domain Component field information and the Certificate’s Subject.” 

 

Can you give some practical examples of how and when a CA is supposed to take action?

 

From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley
Sent: Wednesday, May 22, 2013 4:32 PM
To: public at cabforum.org
Subject: [cabfpub] Section 9.2.3 modification

 

Hi everyone, 

 

As mentioned there is an incompatibility between the Baseline Requirements and other industry groups on what information should be included in a Domain Component Field. I modified the motion slightly based on Ryan Sleevi’s comments during last week’s phone call.  Please let me know if you are willing to endorse or have suggestions.

 

---Motion Begins----

Replace Section 9.2.3 

 

Certificate Field:  subject:domainComponent (OID 0.9.2342.19200300.100.1.25)

Required/Optional:  Optional.  

Contents:  If present, this field MUST contain all components of the subject’s Registered Domain Name in ordered sequence, with the most significant component, closest to the root of the namespace, written last.  

 

With the following:

 

9.2.3 Subject Domain Component Field 

Certificate Field: subject:domainComponent (OID 0.9.2342.19200300.100.1.25)

Required/Optional: Optional. 

Contents: If present, this field MUST contain components of a Domain Name verified under Section 11.1.1 in ordered sequence, with the most significant component, closest to the root of the namespace, written last. The CA SHALL implement and follow a process that prevents a Domain Component field from including  information if the CA is unaware of the logical association between the Domain Component field information and the Certificate’s Subject.

 

-----Motion Ends-----

 

Thanks,

Jeremy

 



 
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20130522/22709ecd/attachment-0003.html>


More information about the Public mailing list