Subject: [KEYPROV] PSKC Algorithm Profile Document: Next Steps

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 10 May 2010 12:40:41 -0700

We just had a short conference call about  
http://tools.ietf.org/id/draft-hoyer-keyprov-pskc-algorithm-profiles-01.txt
to determine the next steps with the document.

The action items are:

Hannes to check the OCRA & TOTP algorithm profile URN parameter about 
attaching parameters to the URN to reflect the different ciphersuites. 
Example: urn:ietf:params:xml:ns:keyprov:pskc#OCRA-1:HOTP-SHA512-8:C-QN08

Hannes to talk to Peter about his comment regarding the # symbol in
urn:ietf:params:xml:ns:keyprov:pskc#pin
Peter says it is a reserved symbol that cannot be used. We have to 
figure out what else to use.  

Ming will take a look at the incomplete sections, such as introduction, 
security considerations, IANA considerations, and references.

Ming will send a mail to Andrea to review the SecurID algorithm profiles.
Ming will send a mail to Philip to review the ActivIdentity algorithm 
profiles.

We said it would be useful to ship an update of the document rather soon 
before Hannes talks to Sean asking for AD sponsoring the document. 
Additionally, we concluded that it would be good to solicit feedback 
from other vendors to document their algorithm profiles as well.

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 10 May 2010 19:54:45 -0600

> figure out what else to use.

Hi Hannes,

The "#" character is not exactly disallowed in URN syntax, but it is
actively discouraged in RFC 2141:

   RFC 1630 [2] reserves the characters "/", "?", and "#" for particular
   purposes. The URN-WG has not yet debated the applicability and
   precise semantics of those purposes as applied to URNs. Therefore,
   these characters are RESERVED for future developments.  Namespace
   developers SHOULD NOT use these characters in unencoded form, but
   rather use the appropriate %-encoding for each character.

A URN of urn:ietf:params:xml:ns:keyprov:pskc:pin seems fine.

I'm not sure what to do about appending the ciphersuites, but we can
chat about the alternatives off-list.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 11 May 2010 08:44:03 -0400

Yes, URNs do not define a resolution protocol, so there is no
distinction between parameters and stem values. The fragment syntax
does not really work either. The reason the fragment identifier is
used in the W3C specs is because they are referring to sections in the
document where the definition lies. The IETF does not want us to do
that because the W3C approach costs them a huge amount in bandwidth.

So just concatenating the parameter values works as well as anything.

On Mon, May 10, 2010 at 9:54 PM, Peter Saint-Andre <[email-masked]> wrote:
> _______________________________________________
> KEYPROV mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyprov
>
>

-- 
Website: http://hallambaker.com/

---

From: "Philip Hoyer" <[email-masked]>
Date: Tue, 11 May 2010 17:21:28 +0200

Should we not somehow prefix the algorithm and suite?

urn:ietf:params:xml:ns:keyprov:pskc:algorithm-pin

urn:ietf:params:xml:ns:keyprov:pskc:algorithm-ocra:suite-HOTP-SHA512-8:C-QN08

although the use of ':' within the OCRA suite definition will most likely confuse things.

Philip

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 11 May 2010 10:16:06 -0600

> although the use of ':' within the OCRA suite definition will most likely confuse things.

The ':' character when used in suite definitions could be escaped to %3A
if needed, see Section 2.3.1 of RFC 2141.