Subject: WGLC results

From: Stephen Kent <[email-masked]>
Date: Mon, 9 Feb 2009 14:59:57 -0500

Folks,

The WGLC on 5 documents closed on 2/6, so it's time to assess status.

	1. 3281 Update: Alfred suggested a few changes. I think Sean 
will need to address these in a new version, which can then be sent 
to the IESG.

	2. New ASN.1: A number of comments here. Most comments 
suggested that the new ASN.1 not be adopted in lieu of the 1988 
version, and that it would be nice to have a tutorial to help folks 
understand how to map between the two. So, I think this ca proceed, 
with the provision that the ASN.1 here is being specified as a peer, 
alternative to the 1988 syntax in the extant specs. Jim & Paul, are 
you comfortable with this way forward? Carl, you offered to help 
write the tutorial. We'll make it a PKIX work item when you create 
the first version.

	3. Authority Clearance Constraints: no comments during this 
last call period, so we'll consider this approved.

	4. PRQP: no comments, so I think we're ready to move this to 
Experimental status.

	5. Trust Anchor Management Requirements: I didn't see any 
messages on the requirements document, so I will assume that this doc 
is suitable for use as the basis for requirements for the rest of the 
trust anchor document work.

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 10 Feb 2009 08:26:48 +0100

Steve,

On the TA requirements document I'm not sure in what way the WGLC impacts
its status as we are keeping this document in draft form. I would like to
have noted that there is one issue with this document that I have raised
repeatedly that I don't think is settled to my satisfaction.

I would like the scope of the requirements to be clarified. I have no
problems with these requirements, I just don't think they are generally
applicable and the document should be more clear about when they are.

On the CA Clearance Constraints I made a last pass and found some nit and a
comment that I think merits a discussion. I think the result of these
comments will be pure editorial, but I think they could benefit from some
discussion. If they are too late I can provide them as IETF last call
comments instead.

I'll post them in a separate mail.

/Stefan

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 10 Feb 2009 08:16:15 -0800

At 8:26 AM +0100 2/10/09, Stefan Santesson wrote:
>I would like to

It seemed like you were the only one raising the issue, and that you did it not wearing your co-chair hat. Do you feel that your lone, repeated voice should cause the document to change? If so, why?

--Paul Hoffman, Director
--VPN Consortium

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 10 Feb 2009 18:32:04 +0100

Paul,

I want to have it noted as part of summarizing the workgroup consensus.
That is, even if I did not send a message during WGLC, note that my problem
with the document is unresolved.

I do not expect the document to change.

/Stefan

On 2/10/09 5:16 PM, "Paul Hoffman" <[email-masked]> wrote:

> It seemed like you were the only one raising the issue, and that you did it
> not wearing your co-chair hat. Do you feel that your lone, repeated voice
> should cause the document to change? If so, why?
> 
> --Paul Hoffman, Director
> --VPN Consortium

---

From: "Carl Wallace" <[email-masked]>
Date: Mon, 16 Feb 2009 11:30:19 -0500

> suggested that the new ASN.1 not be adopted in lieu of the 
> 1988 version, and that it would be nice to have a tutorial to 
> help folks understand how to map between the two. So, I think 
> this ca proceed, with the provision that the ASN.1 here is 
> being specified as a peer, alternative to the 1988 syntax in 
> the extant specs. Jim & Paul, are you comfortable with this 
> way forward? Carl, you offered to help write the tutorial. 
> We'll make it a PKIX work item when you create the first version.

OK.  We'll submit the tutorial as a PKIX I-D, hopefully before the -00
deadline.

I have a (late) comment on the ASN.1 draft.  In the new module for RFC
5055, the structure for ReplyStatus is now extensible.  In RFC 5055 it
was not extensible.  I don't think this draft should introduce a change
like this and suggest the extension marker be removed.

>From RFC 5055
ReplyStatus ::= ENUMERATED {
  success                    (0),
  malformedPKC               (1),
  malformedAC                (2),
  unavailableValidationTime  (3),
  referenceCertHashFail      (4),
  certPathConstructFail      (5),
  certPathNotValid           (6),
  certPathNotValidNow        (7),
  wantBackUnsatisfied        (8) }

>From new ASN.1 I-D
ReplyStatus ::= ENUMERATED {
    success                    (0),
    malformedPKC               (1),
    malformedAC                (2),
    unavailableValidationTime  (3),
    referenceCertHashFail      (4),
    certPathConstructFail      (5),
    certPathNotValid           (6),
    certPathNotValidNow        (7),
    wantBackUnsatisfied        (8),
    ...
}