Subject: Re: draft-ietf-pkix-other-certs-01

From: Alfred Hönes <[email-masked]>
Date: Tue, 21 Oct 2008 23:02:22 +0200 (MESZ)

Stephen Farrell responded to my previous comments:

> Hi Alfred,
> 
> Thanks for those. Couple of responses below.
> 
> BTW - if you meant to, (you didn't), cc the pkix list, its
> fine by me to continue this on the list, or not, as you
> prefer.

The details deemed to me being too minor for the list,
but you may be right, at least item (3) emerging after
starting my comments, might have deserved being copied
to the list.  As such I'll cc the pkix list now.   :-)

> Alfred Hönes wrote:
>> ...
>> 
>> (1)  Nits
>> 
> ...
> Thanks
>> 
>> (2)  Section 3, ASN.1
>> 
>> The name form 'id-pe' comes out of the blue in Section 3.
>> 
>> Perhaps, the two ASN.1 lines should be amended by (I present
>> a 'luxurious' version):
>> 
>>    where [pkix-oids] :
>>    id-pe   OBJECT IDENTIFIER ::= { id-pkix 1 }
>>                                  -- PKIX certificate extensions
>>    id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
>>                dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
> 
> I don't think that's required - that's all in the ASN.1 module and
> anyone that could understand the above would not be puzzled by the
> current text.

I found it there, but I recalled to have appreciated the style
followed in most recent PKIX and SMIME documents, giving the
reader immediately complete information in the prose.

As indicated originally, a more terse version would also be
possible, collapsing the two definitions above into one.

>> ... and a URL ref. added to Section 8 :
>> 
>>    [pkix-oids]  The PKIX Object Identifier Registry, URL:
>>                 <http://www.imc.org/ietf-pkix/pkix-oid.asn>
> 
> I think its ok with just the mention in the ASN.1 module
> appendix.

This nice resource IMHO is not very well-known; thus, the above
comment offered a chance for me to try to push a citation
to it in an IETF document (and ultimately into an RFC).  :-)

Maybe, draft-ietf-pkix-new-asn1 and draft-ietf-smime-new-asn1
may be more appropriate places to put this citation in now.

>> (3) Discuss items
>> 
>> (3a) Section 3, last paragraph  (EE only)
>> 
>> I support the restriction on end-entity certificates,
>> and the rationale given.
> 
> Fair enough. I guess I do too. I'll leave in the comment for
> now though in case someone thinks the opposite.
> 
>> 
>> (3b) Section 7, last 2 paragraphs  (NC issue)
>> 
>> IMO, that conflict should be left to implementation and policy,
>> with a fallback / default of 'strict' behavior;
>> perhaps, a 'callback' to the user upon detection of such
>> NC violations would make sense, offering the opportunity
>> to override 'normal' NC processing; unfortunately, this
>> strategy is not feasable for client certificate verification
>> at a server.
> 
> I'm not sure I'm following you there. (Though I also find
> the issue tricky.) Any suggestion as to text changes though?
> I'm quite open to whatever might work.
> 
> Thanks again,
> Stephen.

Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+