Re: RFC 3280bis and URI schemes without hostname

Hi Dave,

David A. Cooper wrote:
> 
> Early this year, there was a email thread about a similar topic under
> the subject line "URN in subjectAltName" (see
> http://www.imc.org/ietf-pkix/mail-archive/msg02513.html).  I thought the
> rough consensus in that discussion was against changing the rules for
> the uniformResourceIdentifier choice in subjectAltName and that if there
> is a need to include such names in a certificate then a new name form
> should be defined (in a document other than 3280bis).
> 
> As for the specific proposal, I have two concerns with the proposed text
> for the name constraints extension:
> 
>   For URIs, the constraint applies to the host part of the name so
>   a name constraint URI can only match a subjetAltName URI where the
>   scheme-specific-part includes a fully qualified domain name or IP
>   address as the host. If a certificate contains a URI with no host
>   part then that certificate cannot match the permittedSubtrees of
>   a name constraint. If a certificate contains a URI with no host
>   part then that certificate always matches the excludedSubtrees of
>   any URI name constraint.
> 
> 1) The first sentence states that a match between a constraint and a
> subject name may occur when the subject name includes an IP address, but
> the second paragraph only explains how to specify DNS name constraints. 
> If a name constraint uses DNS names to specify a constraint, can that be
> compared against a subject name that has an IP address?

Reminder - please send your slides before the PKIX meeting

CMC Draft URL (it is 06 instead of 05)

Hi guys,

I was trying to download the I-D but all I get is a "File not Found" from
the published URLs:

        http://ietf.org/internet-drafts/draft-ietf-pkix-cmc-trans-05.txt
        http://ietf.org/internet-drafts/draft-ietf-pkix-cmc-trans-05.txt

... found it... ! If anybody is interested in downloading it, it seems the
current version is '06' not '05'.

	http://ietf.org/internet-drafts/draft-ietf-pkix-cmc-trans-06.txt

Later,
Max

--

-- 

Best Regards,

	Massimiliano Pala

--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]            pala <at> cs.dartmouth.edu
                                                  project.manager <at> openca.org

Dartmouth Computer Science Dept               Home Phone: +1 (603) 397-3883
PKI/Trust - Office 063                        Work Phone: +1 (603) 646-9179
--o------------------------------------------------------------------------

work item approval request

Proposed direction for ITU response on removing bounds

As promised in the meeting.

Something like;

The PKIX working group thanks <blah> for notifying us of changes to
remove bounds from ASN.1 data types in the directory.

Our participants see significant value in these bounds and do not see
use cases that would be enabled in the Internet PKI by removing these
bounds.  So, at this time, there is a strong desire not to align the
Internet PKI profile with this change.

As always we encourage those who would like to present use cases that
would be enabled in the Internet PKI by aligning with this change to
present these use cases to the PKIX working group.

Re: Last Call: draft-ietf-pkix-rfc3280bis (Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile) to Proposed Standard

Sam Hartman identified an issue with one name type (URI) that may 
appear in the Subject/Issuer alternative names, when applying the 
Name Constrains extension to such names.  The issue arises when the 
URI does not contain an authority component (a host name in a DNS 
name or e-mail address), because the 3280bis description of how to 
apply name constraints to URIs assumes the presence of such a 
component.

The WG is working on text to address this issue in response to the 
last call comment .

Steve

Re: work item approval request

As a member of the design team, I support the way forward, and I'm 
willing to help write the document that is needed to implement the 
proposed solution.

Russ

At 05:02 PM 12/3/2007, Stephen Kent wrote:
>Folks,
>
>The ECC design team has proposed a solution to the (long standing) 
>problem of what info re use of ECC algs is to be represented in a 
>cert, and how to represent the info.  Via this message I am asking 
>that WG members submit comments on adopting this as PKIX WG item.
>
>See the PKIX WG slides posted for this IETF meeting for the 
>background. The PKIX WG minutes relevant to this topic are reproduced below.
>
>Subject public key info resolution for ECC - Tim Polk (NIST)
>  The design team has been addressing the question of how to 
> represent algorithm info for ECCs, not just curve info but also 
> ways to restrict use of the key, e.g., for Elliptic Curve 
> Diffie-Hellman vs. ECMQV. The proposal (second pass) is to be able 
> to express only a very basic constraint, i.e., whether a key is to 
> be restricted to ONLY Elliptic Curve Diffie-Hellman or ONLY ECMQV. 
> Thus, the existing ecPublicKey OID will be interpreted as allowing 
> the pubic key to be used with either of these algorithms, and two 
> new OIDs will be assigned to represent these other two cases. This 
> is consistent with the RSA-context solution adopted in RFC 4055. It 
> is also compliant with a subset of the X9.62 standards. Also, a 
> suggested change to RFC 4055, to say that KDF restrictions MUST NOT 
> (vs. SHOULD NOT) appear in certificates, i.e., these restrictions 
> are the provenance of applications. The outcome is that the design 
> team will submit a new I-D that will update 3279 and obsolete 4055, 
> but will not adversely affect extant implementations, based on the 
> data gathered by the team. Steve Kent will formally ask the WG to 
> confirm that there is no objection to adopting this as a PKIX work 
> item. (Slides)

PRQP Demo

Hi all,

because of issues with the schedule (thanks Stefan for letting me use your
time :D) I had not time to show a demo of the PRQP. Anyhow if you are
interested, just go to the following URL:

	http://rqa.openca.org/prqp

I attach three demo certificates that can be used to query the Resource
Query Authority (RQA):

* Dartmouth-Root.cer and OpenCA-Demo.cer have been actually configured on
   the RQA and responses will carry the specified pointers. The OpenCA-Demo.cer
   CA configuration is the more rich and will provide (fake) pointers to
   services like webcertDav, cmsGateway or trustAnchors.

* EuroPKI-Root.cer has no configuration on the RQA and the provided response
   will carry a "CA Not Present" in the PKIStatus field

Please regard the fact that the web interface to the server is just for
Demo purposes, and it might not be very stable :D

There is also a 'Contribute' section where you can post info about your CAs.
This would help us to setup a demo service which carries information about
many CAs - thus making it more interesting.

Later,
Max

--

-- 

Best Regards,

	Massimiliano Pala

--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]            pala <at> cs.dartmouth.edu
                                                  project.manager <at> openca.org

Dartmouth Computer Science Dept               Home Phone: +1 (603) 397-3883
PKI/Trust - Office 063                        Work Phone: +1 (603) 646-9179
--o------------------------------------------------------------------------

RE: Draft response to the liaison from ITU-T SG 17 to IETF on the resolution of DR320

RE: Draft response to the liaison from ITU-T SG 17 to IETF on the resolution of DR320

You are right that this ending was not based on the consensus of the room, but I still think it is reasonable to
welcome proposals to be posted to the WG.
I think that the consensus in the room was that the solution mentioned in the liaison request is totally
unreasonable and that we can't see any other solution to the problem worth pursuing.

I practically stole the ending from Sam's proposal on response to the other liaison request.
It sort of takes the position that if they want something done, they have to propose a mechanism rather than
asking us to find one.

But I can remove it also.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> -----Original Message-----
> From: Stephen Farrell [mailto:stephen.farrell <at> cs.tcd.ie]
> Sent: den 3 december 2007 19:38
> To: Stefan Santesson
> Cc: ietf-pkix <at> imc.org
> Subject: Re: Draft response to the liaison from ITU-T SG 17 to IETF on
> the resolution of DR320
>
>
>
> Stefan Santesson wrote:
> > The
> > PKIX WG does however welcome and encourage those who would like to
> > propose useful mechanisms to present them to the PKIX work group.
>
> I didn't get a sense in the room today that we would actually
> welcome a proposal for how to maintain a list of CA names. In fact,
> I got the opposite impression, i.e. that the people in the room
> would find such a proposal unwelcome. (All modulo WG participants
> who weren't in the room of course.)
>
> Other than that, I think your text is fine.
>
> S.